Anyway, all DNS servers speak TCP. They have to because DNS doesn't
have any kind of fragmentation support. You initially make a DNS
request using UDP. If the TC (truncated) bit is set then you know you
have to re-request it using TCP. How long a stream is that? Well, for
a typical DNS request its probably not very long. However, if the
server accepts an AXFR query (zone transfer) from you, then you are in
for a load of data. I have no idea if real DNS servers check to make
sure a zone transfer request comes from the IP address of their
secondary.
As neal points out however, maintaining "data parity" ("ack parity" in
reverse) might be tough. In particular, if the server sends a burst of
two packets, and the second one is lost, then you (the receiver) have no
trivial way to detect this. I have a couple good ideas on how to try,
but they all seem harder than the forward direction. Still, I think its
doable. I'll leave the necessary hacks as an exercise to the reader ;-)
- Stefan
-----Original Message-----
From: Neal Cardwell [mailto:cardwell@cs.washington.edu]
Sent: Tuesday, December 22, 1998 5:02 PM
To: syn@cs.washington.edu
Subject: Re: dns questions
> While listening to the questions provided for Stefan's talk, I caught
the
> bit about only being able to force the target host to send small
packets.
> What about DNS? What percentage of the machines out there can have
DNS
> resolutions requested from them?
I believe every dns domain is required to have two servers that will
serve
up name->address mappings for that domain (for availability). I'd guess
there are about as many dns servers as web servers (O(1M)?).
> How crackpot of an idea is using DNS responses to test loss rates?
Assuming most dns servers are configured to allow TCP connections (i
have
no idea; Amit?), it doesn't sound too outrageously crazy 2 me;
presumably
it's a lot like using HTTP or echo services to get big packets sent at
yourself.
But with any of these 3 services, it does seem difficult to guarantee
the
"ack parity" that sting depends on. The problem, i think, is that with
these request-response apps layered on top of TCP, all of the sudden you
have to worry about several kinds of packets that the server spits at
you:
acks for your requests, the responses from the server, and the
*retransmitted* responses from the server. Depending on the server's OS,
the server application, and the timing of your requests, each packet you
send may result in 1 or 2 packets back from the server. And if a
response
packet gets lost, the server will usually try to retransmit it. Blech.
No
parity there. Still, i'm not saying this problem can't be overcome. I've
learned it's a bad idea to bet against Stefan's ability to find TCP
hacks
to solve any given problem... ;-)
neal