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

Florian Obser <> Thu, 08 June 2023 06:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 631F7C151B06 for <>; Wed, 7 Jun 2023 23:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cwsbUR81CCBk for <>; Wed, 7 Jun 2023 23:42:15 -0700 (PDT)
Received: from ( [IPv6:2001:19f0:6c01:821:5400:1ff:fe33:a36d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by (Postfix) with ESMTPS id 87EA8C151064 for <>; Wed, 7 Jun 2023 23:42:13 -0700 (PDT)
Received: from pinkunicorn ( [2001:1c00:270d:e800:ddfa:1155:30ee:5532]) by (OpenSMTPD) with ESMTPSA id 8fd7220a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 8 Jun 2023 08:42:08 +0200 (CEST)
From: Florian Obser <>
To: Paul Hoffman <>
Cc: Philip Homburg <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 08 Jun 2023 08:42:07 +0200
In-Reply-To: <> (Paul Hoffman's message of "Wed, 7 Jun 2023 23:12:21 +0000")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (darwin)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Jun 2023 06:42:19 -0000

On 2023-06-07 23:12 UTC, Paul Hoffman <> wrote:
> On Jun 7, 2023, at 1:05 AM, Philip Homburg <> wrote:
>>> We still have time to add those known operational considerations.
>>> In fact, we should be listing those even if this is an experimental
>>> RFC.
>> The experiment could just be to gain operational experience. We can be upfront
>> that we don't know what will happen, and encourage people to be careful.
> That's true with every new protocol from the IETF. It would be good to understand what is different about this protocol for such an experiment.
>>> If so, they are not following the draft:
>>> An authoritative server implementing DoT or DoQ MUST authoritatively
>>> serve the same zones over all supported transports.  If both DoT
>>> and DoQ are offered, a nameserver's reply to a particular query
>>> MUST be the same on both transports (with the possible exception
>>> of how the TC bit is set).
>>> Which authoritative servers are serving different content on 853,
>>> and what are the differences? We should certainly discuss that in
>>> the draft.
>> Of course they are not following this draft. After all this is just a draft.
>> They are following RFC 7858 (DoT) and are running a recursive resolver on
>> this port.
> Serving from port 853 in RFC 7858 (DoT) only applies to the client-facing side of recursive resolvers. It doesn't apply to authoritative servers at all.
>> I don't know if they also have a recursor on port 53, that is very
>> well possible. The problem is that they have an authoritative on 53 but not
>> on 853.
>> The problem is that this draft is essentially updating RFC 7858 without
>> explicitly doing so. 
> It is not updating RFC 7858 at all. RFC 7858 explicitly applies to the
> stub resolver and the client-facing side of recursive resolvers. This
> draft applies to the server-facing side of recursive resolvers and
> authoritative server. There is zero overlap.
>>From your response above, I take it that you don't have any examples
> of authoritative servers already serving on port 853. Please let me
> know if that's wrong; if so, please give at least one example.

Up-thread Stéphane reported as an example. Open resolver on
853 and authority for on 53:

| Also, currently, regarding the possible warning to system
| administrators about the need for 53 and 853 to be in sync, we
| currently find in the wild servers that implement different services on
| the two ports. See for instance (authoritative for
| or (authoritative for Both
| have authoritative on 53 and an open resolver on 853. Should we
| explicitely ban this practice?

>>> How to reach them: no idea. How to deal with that: it's prohibited
>>> with MUST-level language.
>> The obvious 'solution' is to move this draft to a new port, because 853 is
>> already in use for other traffic.
> That was discussed in the WG, and rejected.
>> Just adding a MUST that is in conflict with current practice makes for a poor
>> standard. If the problem is small, then experimental is fine and we can
>> start telling people that they have to stop doing this. 
> Again, you haven't shown any current practice of authoritative servers serving on port 853. If you can show that, it would very helpful.
>>> Are you talking about authoritative servers or the client-facing
>>> side of recursive resolvers? If the latter, that's very clearly
>>> out of scope for this document (or any document other than the DoT
>>> spec). But if it authoritative servers doing something else on 853,
>>> we should certainly cover it.
>> Yes, I'm talking about recursive. And that's why I said, the operational
>> aspects are not sufficiently discussed. Marking recursive out of scope does
>> not help when other recursive resolvers connect to such servers.
> This is unclear. If a recursive resolver has an NS record with addresses, when would those addresses ever be the client-facing side of a different resolver?
>>> If you have suggestions for what more could be said, we'd be happy
>>> to add them. Note that the DNS traffic will not automatically switch
>>> to TLS or QUIC: probe traffic will increase. The DNS traffic will
>>> only switch if the authoritative server operators turn on the
>>> service. The increase in probe traffic is covered throughout the
>>> document, but if you think that adding more in a particular place
>>> would help reduce negative impacts, please say where and we can
>>> add it.
>> No, I'm saying it should be experimental because we don't know and should
>> experiment. 
> Please be specific about what we don't know so that we can be specific in the draft.
>>> I don't understand this. All security protocols are optional. The
>>> existence of this draft, when it becomes an RFC, does not force
>>> any client to use it, just as no resolver is forced to set the DO
>>> bit on queries and then interpret the DNSSEC material in the
>>> responses.
>> Usually, if you say you implement a security standard, it should actually be
>> secure if you follow the standard. It is a bad security standard, if the
>> standard says that you can stop being secure if you are overloaded. That
>> only leads to problems later on.
>> What if TLS would say that you can stop encrypting data if you get overloaded.
>> People would get very upset.
> Ah, OK. You are asking for the non-opportunistic version of this
> protocol, with authenticated probing and never falling back to using
> Do53. The WG was not able to get any traction on that idea, despite
> many attempts.
>>> Yep, that's what we are discussing. What criteria would you use to
>>> determine the success of the experiment?
>> The success of the experiement is that operational issues are documented,
>> including operational practices and the feedback of the experiment is
>> used in a new draft that is intended to become a standard.
> Can you be more specific about "operational issues"? Every new protocol has operational issues. Which are you concerned about here, and can they be measured?
>> From
>> "If the IETF may publish something based on this on the standards
>> track once we know how well this one works, it's Experimental. This
>> is the typical case of not being able to decide which protocol is
>> "better" before we have experience of dealing with them from a
>> stable specification. Case in point: "PGM Reliable Transport
>> Protocol Specification" (RFC 3208)"
> Earlier in that same document, it says what is an expriemental protocol, and this draft doesn't match that description at all.
>> So I think it best to no longer delay this draft, publish it as experimental
>> and gain experience in how this actually works.
> Without more detail about what you want to observe or measure in this
> experiment that wouldn't be observed or measured for any normal
> standard, it's hard to agree with that assessment.
> --Paul Hoffman
> _______________________________________________
> dns-privacy mailing list

In my defence, I have been left unsupervised.