On Jun 12, 2023, at 1:46 AM, Florian Obser <[email protected]> wrote:
>
> On 2023-06-10 22:48 UTC, Paul Hoffman <[email protected]> wrote:
>> On Jun 10, 2023, at 1:38 PM, Philip Homburg <[email protected]>
>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
