[dns-operations] Signaling client protocol to authority

[Patrick W. Gilmore]

On Jan 16, 2011, at 2:10 PM, Jim Reid wrote:
> 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.

Jim: I asked a serious question, I was hoping for serious answers, not 3rd grade name calling.

Your 3 responses below boil down to 1) "I don't know how to do it" (which I guess is fine since I don't either, but is far from a useful answer), 2) shows a deep misunderstanding of the question at hand, and 3) Jim thinks we should never extend or update the DNS because it will never work.  Or, more succinctly, no answers at all.

The question was serious, and I guess I got a serious answer back.  Namely: No, no one has thought about this.  So thanx for at least that much.  Although, in all honesty, I worry that if I asked about, say, client IP address signaling, you would simply explain why it was bad without mentioning that there was (maybe still is?) an I-D on it.  And it saddens me that I have even the tiniest doubt about this.


Changes _are_ going to happen.  You can work with them, or you can stand in an ivory tower and call them names.  Put another way, when someone reaches out in good faith and with good will, perhaps you could do the same.  The alternative is being left behind.

Remember, it is quite possible, even probable, that Stupid DNS Tricks current direct more traffic on the 'Net than "pure" DNS.  And the percentage is growing.  In fact, it could be argued that without Stupid DNS Tricks the Internet could not have gotten to where it is today.  Ignoring the change did not seem to have the desired effect.  Perhaps it is time to re-think your position?

-- 
TTFN,
patrick



>> 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.
>