On 2023-06-12 19:48 UTC, Paul Hoffman <paul.hoff...@icann.org> wrote: > On Jun 12, 2023, at 1:46 AM, Florian Obser <florian+i...@narrans.de> wrote: >> >> On 2023-06-10 22:48 UTC, Paul Hoffman <paul.hoff...@icann.org> wrote: >>> On Jun 10, 2023, at 1:38 PM, Philip Homburg >>> <pch-ietf-dpr...@u-1.phicoh.com> wrote: >>>> >>>>> In such a case, resolvers following >>>>> this protocol will look for authoritative answers to ports 53 and >>>>> 853 on that system, and the system would need to be able to >>>>> differentiate queries for recursive answers from queries for >>>>> authoritative answers. >> >> I think this needs some MUST requirements because it's an interop >> problem. > > Please say more. Would this be MUST requirements on resolvers, auth servers, > or both? What requirements would you suggest? >
It's on the recursive resolvers. People have been happily providing open resolvers using DoT on port 853. Now a new standard comes out that is OPTIONAL for auths and OPTIONAL for recursive resolvers that still changes what auths and recursive resolvers are allowed to do. "Recursive resolvers when implementing this protocol MUST ignore answers from recursive resolvers on port 853." Clearly this needs word smithing. >> An issue with the draft is that it never specifies explicitly >> what a successful or unsuccessful probe is. My reading is that it >> decides successful / unsuccessful on the transport layer. E.g. when it >> can talk TLS to *something* on port 853 that's a success. Nevermind what >> that something is. > > Yes. The document says (in Section 4.6.4) "When an encrypted transport > connection actually completes (e.g., the TLS handshake completes)...". > > How would you change that? I don't think "and it responded to a DNS > query" will help much, because your concern seems to be a system that > is responding to both recursive and authoritative queries on 853. How > can this be clarified for your issue? No, that's not my issue, that's clearly broken. My issue is a system that answers authoritatively for some queries on Do53 (and REFUSED otherwise). And answers to all recursive queries on 853, like the ns1.eu.org example. The algorithm will just think that ns1.eu.org is lame. But it's not, it is currently a perfectly valid setup. It answers correctly on 53. The problem is that this draft changes what it is required to do on 853. > >>>> >>>> For lack of a better term, I use the word 'lame' here: >>>> >>>> If, during probing, a recursive resolver decides that the authoritative >>>> server on port 853 is 'lame', then the recursive resolver should fall back >>>> to port 53. >>> >>> The feeling that I got from the other messages is that the server on >>> 853 is not lame: it is being authoritative for some names and >>> recursive for all others. If so, it's not lame at all. >> >> ns1.eu.org is authoritative for eu.org: >> $ dig +norec +noall +comments @ns1.eu.org eu.org NS >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54105 >> ;; flags: qr aa; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 >> >> The DoT recursive resolver refuses to talk to as when we turn of RD: >> $ dig +tls +norec +noall +comments @ns1.eu.org eu.org NS >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9454 >> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> It is happy to give us a recursive answer though, heck, it's even DNSSEC >> validated: >> $ dig +tls +noall +comments @ns1.eu.org eu.org NS >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48894 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 >> >> >> From the PoV of the draft (as it currently stands) the DoT probe is >> successful, because something responded to us. > > There is a looooong and indecisive (so far!) discussion in DNSOP about what > is "lame". I would agree with you that this qualifies as lame: it is supposed > to give an authoritative response but instead gives a non-authoritative one. > It's worse, it answers refused. So what we currently have in the draft will lead to the recursive resolver answering refused. Because it is a successful response. > I think what you are talking about here is Section 4.6.9, the end of which > currently says: > But if R is unsuccessful (e.g. timeout or connection closed): > > * If Q is not in Do53-queries[X] or in any of *-queries[X]: > > - Return SERVFAIL to the requesting client > > Would the following cover your issue? I think so. I would love to hear from recursive resolver implementers though. But I need to go through the full section 4 again. Also for the dnsdir review. > But if R is unsuccessful (e.g. a non-authoritative answer, or is a timeout > or connection closed): > > * If Q is in Do53-queries[X] or in any of *-queries[X]: > > - set E-session[X] to null > > - set E-status[X] to fail > > - set E-completed[X] to T2 > > > * Otherwise: > > - Return SERVFAIL to the requesting client > > --Paul Hoffman > Florian -- In my defence, I have been left unsupervised. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
