Ray Bellis wrote: > On 12/06/2015 17:49, Paul Vixie wrote: > >> 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 think i disagree. see below. > ... > > 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. ... ok. > 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. to that terminological hair splitting, my answer is: the combination of the two proxy_dns agents (the near end that is a DNS listener, and the far end that is a DNS re-initiator) plus the HTTP(S) transport between them, is exactly the same as what you said: "do absolutely nothing except rcv pkts on one side and fwd them untouched to the server (using the same protocol)". > >>> 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. since 6891 is talking about the forwarding of transactions not of sessions, multiplexing is a distinction without a difference. >> 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. there's good reason why it's not easy. getting consensus that breaking old behaviour won't hurt any working configurations is hard. that said, we reached such consensus on removing IQUERY and on removing IP6.INT, so it can be done. i judge that it could not be done for violating the connection close assumptions of RFC 1035-conformant TCP initiators and responders, though. >> 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. yeah you're right. middleboxes, as we know, are evil. -- Paul Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
