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

[Florian Obser <[e-mail]>]

Apologise for the late response, I'm slowly working through a huge pile
of emails.

On 2023-06-24 22:17 UTC, Paul Hoffman <[e-mail]> wrote:
> On Jun 14, 2023, at 10:08 AM, Florian Obser <[e-mail]> wrote:
>> 
>> On 2023-06-12 19:48 UTC, Paul Hoffman <[e-mail]> wrote:
>>> 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?
>>> 
>> 
>> 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.
>
> Maybe I'm being dense, but I'm not sure how this differs at all from
> today on port 53. If someone lists 9.9.9.9 as authoritative for
> fournines.com, and a recursive resolver queries it, doesn't it have
> *exactly* the same problem as you are saying this document creates for
> port 853?
>

Yes, but that's not what I'm suggesting.
Let me try again.

Say I have

example.com     NS ns1.example.com
ns1.example.com  A 192.0.2.53

ns1.example.com is answering authoritatively for example.com on udp/53
and tcp/53 since November 1987.
All recursive resolvers are happy.

Come May 2016, RFC 7858 tells me I can run a recursive resolver on port
853 using TLS. I decide to run an open DoT resolver and since I'm out of
IPv4 I run this on 192.0.2.53 port 853.
Still, all recursive resolvers are happy. They never talk to port 853
and they get authoritative answers on udp/53 and tcp/53. example.com is
still resolvable.

Stub resolvers are also happy, they use my open DoT resolver and ask for
anything with RD flag set, so they get an answer.

Now this draft comes along. I do nothing on ns1.example.com. The
draft says unilateral and it says it's OPTIONAL for authoritative
servers.

A recursive resolver implementing this draft will probe on 853 without
RD set. ns1.example.com will respond with refused. The recursive
resolver will answer SERVFAIL.

At least that's how I'm reading 4.6.9. R is successful, (it's not a
timeout or connection closed), so we do this:

   If R is successful:

   *  R is further processed by the resolver

Well, the resolver got REFUSED and there are no more NS to try. It can
only answer SERVFAIL. Therefore example.com is no longer resolvable.

This draft breaks a valid configuration that has been working since
2016. That's why I'm saying that a recursive resolver while probing MUST
be prepared to encounter open resolvers on 853 and not assume that
that's a successful probe.


-- 
In my defence, I have been left unsupervised.