Ray Bellis wrote: > On 12/06/2015 15:46, Paul Vixie wrote: > >> however, that's not the world we live in. consider for example >> proxy_dns (available as open source on >> https://github.com/BII-Lab/DNSoverHTTP) which is perfectly capable of >> carrying individual dns transactions over several parallel http(s) >> sessions, and to whom any new EDNS signalling will be opaque at least >> initially. this naive dns client only understands framing, not >> content, and it works. i think this naivety is likely present in some >> dns-aware load balancers as well. and i think that none of these are >> "broken" or in any way "noncompliant". > > I think there's scope for a long argument on this last point. > > RFC 2671 (§4.1) says "OPT RRs shall never be ... forwarded".
as the author of that text, i claim that i was referring to DNS Forwarding, in the sense described by <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/>. > RFC 6891 is even more explicit in §6 about middleboxes. in RFC 6891 (6.8.2) i see this text: Middleboxes that simply forward requests to a recursive resolver MUST NOT modify and MUST NOT delete the OPT record contents in either direction. in which case, proxy_dns is precisely compliant with the currently described EDNS0 specification. > It's perhaps a shame that EDNS doesn't support the separation of > "hop-by-hop" options vs "end-to-end" options that IPv6 has. indeed, this is why extended label types were removed from the EDNS0 definition. > To my mind proxy_dns is absolutely non-conformant, ... can you explain why or how, in light of the observations i shared above? >> a rule of protocol evolution is, existing speakers should not become >> broken due to a spec change. > > > If only that were existing _conformant_ speakers ;-) i see your smiley so i'm not going to provide a serious rejoinder. proxy_dns is conformant to the literal text of RFC 6891, to the author's intent of RFC 2671, and with all pure non-EDNS implementations of RFC 1035. if any part of 2671 or 6891 would make any speaker of 1035 (and any deprecations such as 3425 or 4159) wrong, then that part of 2671 or 6891 would itself be wrong and must be stricken. if we want to make a non-backward-compatible change to 1035, we have to write a deprecation RFC and get that approved. >> so, connection semantics will have to be negotiated at the framing >> level not the content level. >> >> so, you might explore the use of a zero length request, which >> currently means nothing. > > The issue with that (and potentially anything else we might come up > with) is that there's no guarantee *whatever we write* that some naive > non-conformant implementation will find a way to forward the magic sequence. understood. we had this problem with the Z bits in RFC 1035, too, since they were simply copied by a lot of naive responders (such as BIND 4). as you know, my top preference is still that you define a new port number having different connection-close rules. tcp/53 is so widely blocked that i don't think you'll get worse service on tcp/666 or whatever. as you know, my actual solution to this is proxy_dns, which leverages both the wider reachability of tcp/443 and the better connection management of https. however, i think you can find meat on this bone if you keep gnawing. for example what if you require a specific response to a zero length message, like <9>EDNS_HERE or some other marker, which is considerably unlikely to occur in nature, and if not seen, signals by its absence a cacheable condition known as "this server did not agree to the new connection-close rules". every signal we have at present is either end-to-end (talking about authoritative data) or hop-by-hop (talking about the current transaction's endpoints). we don't have anything having to do with framing, nor do we have a place to put a new signal that won't be interpreted as either end-to-end or hop-by-hop by some perfectly conformant endpoint or middlebox that got here first. -- Paul Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
