Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DNS Connection Question



On 20 Oct 2004 Derek Martin wrote:

> Why not?  You're 9/10 of the way there already?  Why not fully
> validate the response?
> 
> > Since I'm validating user input, timing has some 
> > importance and I have the idea -- admittedly not tested, but logical -- 
> > that just opening and closing a connection is likely to be a lot faster 
> > than doing the full query.
> 
> I don't think that's actually true.  A TCP connection is a 3-way
> handshake -- at least 3 packets are required.  The client sends a
> packet with the SYN flag, to which the server replies with its own
> packet containing the SYN flag.  The client can then send a packet
> with the ACK flag, which may contain data (i.e. the DNS request) or
> not.

OK, this all makes perfect sense.  But I was assuming -- again 
definitely not an assumption I tested, it was a casual thought at the 
time and not an analysis -- that exchanging packets is typically 
relatively fast while waiting for the nameserver to do a lookup is 
typically relatively slow.  So is making a TCP connection really 
"9/10", or not?  It depends on the relative speed of the lookup in the 
nameserver vs. the packet transit times.

At this point since I have to use UDP anyway, I might as well just do 
the lookup, and retreat from that approach only if the whole thing 
seems too slow for what I need.

Another possible option would be to send a Server Status query, which 
is mentioned in RFC 1035 but not documented as to possible responses.

--
Tom







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org