Subject: Re: DNS query over anycast

From: Dan Lanciani <[email-masked]>
Date: Mon, 4 Jun 2001 02:55:01 -0400 (EDT)

Robert Elz <[email-masked]> wrote:

|    Date:        Sun, 03 Jun 2001 20:18:55 -0700
|    From:        Randy Bush <[email-masked]>
|    Message-ID:  <[email-masked]>
|
|  | while one can not measure all dns transactions, a significant number of
|  | them use just such a 'misconfiguration'.  please excuse our stupidity in
|  | wishing to continue to offer our customers better service.
|
|For v4 there is probably no other way.   For v6 we're still early enough
|in the grand scheme of things that we could easily change the DNS
|spec (actually just the DNS clarifications - 2181) and require that
|v6 based resolvers ignore the source address of a reply, and match the
|reply to the query using the query ID and question alone.
|
|Using the IP address doesn't gain much really - it certainly doesn't
|offer any protection against bogus replies - in reality it is little
|more than one extra field to check.
|
|The requirement in 2181 is there not because the DNS protocol requires
|it, but because the vast majority of resolvers deployed happened to
|be implemented to expect it - that is, servers must send their answers
|that way, or they will be ignored.
|
|For v6, there are essentially no deployed resolvers yet (almost all v6
|name resolution that is currently done is done using the v4 DNS), so
|changing the v6 resolvers to simply omit that check on the replies
|they receive (via v6), and process anything would not be a very difficult
|change to make.

One minor clarification.  Existing sockets-based resolvers don't check the
source address in some futile attempt to avoid bogus replies.  In fact,
they don't generally check the source address explicitly at all.  The
check is happening in the kernel as a side effect of the resolver's using
a connect()ed socket.  The resolver is using a connect()ed socket so that
it can get a quick indication that the server is not running via a UDP port
unreachable.  This is important both in the case of a single server on the
loopback address (in order to avoid having to time out during boot when
the name server is not yet running) and in the multi-server case to quickly
move on to another server in a list if the current one is not running (though
the latter might better be accomplished by sending out requests in parallel).

The original sockets API offers no other way to accomplish this interaction
with UDP port unreachables.  Fancy new APIs may allow the same thing to be
accomplished by other means, but in any case you are talking about slightly
more (structurally) than simply removing a check on the reply.

				Dan Lanciani
				[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------