On 12/06/2015 17:49, Paul Vixie wrote: > > > Ray Bellis wrote: >> >> 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/>.
Yes, that's reasonable. >> 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. I don't believe the word "forward" in RFC 6891 is intended the same as that in RFC 2671. I did specifically raise this whole middlebox issue while RFC 6891 was being written (which is possibly why a lot of §6 is actually there) since whilst researching SSAC 035 and RFC 5625 I found quite a lot of "forwarders" (or "ALGs" or "proxies" of whatever we want to call them) that interfered with EDNS. The intent I had hoped 6891 would express is that if you do _absolutely nothing_ except receive packets on one side and "forward" them untouched to the server (using the *same* protocol), and likewise with the responses, then you are not a "hop" in the EDNS sense and may (indeed MUST) pass EDNS untouched. That's mostly also what §3 of RFC 5625 is trying to say. However if you do anything the slightest bit more complicated than that then you should be considered a hop, and NOT pass on the OPT RR. [ That's not to say that such a proxy that knows about OPT RRs couldn't decide to pass on a specific value option in its own OPT RR if it understands the semantics of that option. ] >> 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. Right >> To my mind proxy_dns is absolutely non-conformant, ... > > can you explain why or how, in light of the observations i shared above? See above - it (potentially) multiplexes multiple clients onto a single upstream connection. IMHO it's not "dumb enough" to satisfy §3 of RFC 5625 and by extension §6 of RFC 6891. > 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. I am not aware of any explicit incompatibility between EDNS and RFC 1035, but that is an interesting point. As you say, there's nothing in pure non-EDNS RFC 1035 semantics that breaks when you multiplex multiple clients down a single TCP session. [Given typical current TCP/DNS behaviour of sending responses strictly in request order it would perhaps be very inefficient, though] Are there perhaps hidden, implicit incompatibilities? I guess that depends on what the consensus view of conformance is. > if we want to make a non-backward-compatible change to 1035, we have to > write a deprecation RFC and get that approved. Indeed - and not an easy task. > 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. I'm not sure I've seen you state it quite this unambiguously before, but yes, understood. > 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". A naive enough proxy could still relay on the zero length request upstream and send back the magic response, making the client believe that the proxy it's talking to supports the signaling when it fact it's only the upstream that does. > 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. Hence the argument about "conformance" :) kind regards, Ray _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
