On 23 September 2015 at 21:40, Dave Lawrence <t...@dd.org> wrote: > Ted Lemon writes: >> It would be helpful if the authors could explain why the REFUSED >> response is being used here. > > Not to be glib, but because that's what Wilmer originally specified. > That's thus what got implemented by the existing implementations (and > there are more than you'd likely imagine, too). > Correct, that's in pretty old versions of the draft so it was likely me or one of the other authors at the time.
Background to that: The transitivity part of this option has always been a sensitive topic, and IMHO it received more attention than it deserved, adding lots of unneeded complexity. The only transitivity I really found useful is anonymisation, which is just a (0|::)/0, not hard to deal with. I think the main motivation to support it was multi-tier DNS setups, but the multi-tierness of such setups should be an invisible implementation detail so should people want to make their internal setup that complicated, that's up to them. But I could easily be wrong here. Over time I've seen other possibly useful use cases for transitivity, but I'm still not sure whether they're worth the additional compexity. Anyway, motivation for returning REFUSED was, we deemed this more appropriate than silently discarding the user's edns-client-subnet option and replacing it for example with an ECS option containing the address they were querying from: An attempt at suppressing ECS silently getting ignored. That seemed worse. I do welcome better alternatives. IMHO transitivity was enough of a corner case that behaviour on rejecting it was not a terribly interesting detail. All in all, I'm very glad to see this draft hit WGLC. -- Wilmer van der Gaast, London Traffic/Edge SRE. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
