Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing

[Paul Hoffman <[e-mail]>]

On Jun 12, 2023, at 1:46 AM, Florian Obser <[e-mail]> wrote:
> 
> On 2023-06-10 22:48 UTC, Paul Hoffman <[e-mail]> wrote:
>> On Jun 10, 2023, at 1:38 PM, Philip Homburg <[e-mail]> 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