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? > 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? >>> >>> 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. 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? 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 _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy