[dns-operations] Signaling client protocol to authority

[Jim Reid]

On 16 Jan 2011, at 13:09, Patrick W. Gilmore wrote:

> Are there any ideas or efforts for a recursive NS to signal the  
> authoritative NS whether the client used v4 or v6 to request the  
> record?

Some DNS people consider this concept an Evil and/or Stupid DNS Trick  
and a very bad idea.

> We already have a suggestion to signal the client IP address,

I thought/hoped the authors of that withdrew the I-D?

> signaling the protocol the client used seems even easier.  So it  
> shouldn't be too difficult. Right?


Just because something isn't "too difficult" doesn't make it worth  
implementing. Or useful. Or even a good idea. IMO there are  
essentially three reasons why it's a bad (and pointless) idea to tell  
authoritative servers if the end client used IPv6 for its query or not.

First, what is the authoritative server expected to do with that  
information and how would this be implemented and deployed in the  
installed base? What about backwards compatibility? You seem to be  
hinting you'd like authoritative servers to hand out different answers  
depending on whether this hypothetical flag is set or not. That'll  
surely end in tears.

Second, just because an end client uses IPv6 to make a query it  
doesn't follow that the application which initiated the lookup is only  
interested in IPv6 data or prefers IPv6-specific answers. This also  
holds for IPv4 data and queries over IPv4. See Section 1.2 of RFC4472.

Third, there can be more than just a single recursive resolver in the  
path between the edge client and the authoritative server. [Think  
forwarding servers, load balancers, DNS relays or proxies in CPE, etc,  
etc.] Given past and current examples of erratic EDNS0 support in some  
of this deployed crippleware, it's unlikely these things can be made  
to honour the settings of this v6 bit. In fact they may well interfere  
with it. So the info that ends up at the authoritative server isn't  
necessarily what the edge client sent. It's likely legacy firmware  
will throw away queries (or responses) with this bit set because it  
does not recognise them as valid DNS packets. These issues will of  
course get worse the longer the resolving chain is because of the  
extra opportunities to introduce something broken into the lookup path.