Date: Sun, 03 Jun 2001 20:18:55 -0700
From: Randy Bush <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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.
Aside from allowing replies to anycast queries to be sent from a unicast
address (as could replies to multicast addresses, even broadcast) this would
also vastly simplify the average DNS server, which would no longer need to
care which particular address received the query, but could just send the
reply using any convenient source address. For v6 nodes that are expected
to have more addresses than your average v4 node, this is probably a win
(even given the better v6 API that allows the dest addr of the query to
be determined without having to bind a socket to every possible address,
something that is a real challenge for v4 DNS servers in environments where
addresses come and go frequently - like a server on the "dialing" end of a
PPP connection, or anyone using v6 temporary addresses).
For v4 there's probably not a lot to be done now - and so simply sending the
reply from an anycast address is probably the only way that can work, there
are simply too many deployed resolvers for it to be changed. Fortunately,
most of the bugs that can be caused by sending from an anycast (UDP)
address don't matter to the DNS (the only way to be sending to a multicast
address from an anycast would be if the query originated from a multicast
address - so that one we can ignore - and DNS servers typically get so many
meaningless ICMP reports anyway, and have absolutely no state to associate
them with anything at all, that getting a few erroneous ones isn't going to
bother them at all). The problems that can happen when the node that
(without knowing it) sent to an anycast address, and then gets a truncated
reply, and tries again with TCP will just have to be suffered.
kre
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
