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

[Stephane Bortzmeyer <[e-mail]>]

On Mon, Mar 20, 2023 at 10:35:07AM +0100,
 Joey Salazar <[e-mail]> wrote 
 a message of 115 lines which said:

> On this note, we the authors want to invite folks to participate in
> this week's Hackathon: I'll be there on Sunday and Benno and Yorgos
> from NLnet Labs will be there since Saturday working on unilateral
> probing in Unbound.

Following the work done at the DNS table, during the hackathon:

* PowerDNS Recursor implements unilateral probing (but not *this*
unilateral probing, it differs from the draft, see the questions
later) and it works for existing zones, whether they have all their
authoritative name servers DoT-enabled, only some, or not at all. No
problem was observed.

* Unbound implementation is not ready, but I let Yorgos elaborate on
this point.

Some questions were raised about the draft, giving the experience with
PowerDNS Recursor:

* If the ADoT server replies but the reply indicates an error,
  such as SERVFAIL or REFUSED, should the resolver retries without
  DoT? PowerDNS recursor does it, but it seems it would make more
  sense to accept the reply, and just to remind system
  administrators that port 853 and 53 should deliver consistent
  answers. The draft seems clear on the first point (as long as
  there is a properly formatted DNS request, regard the server as
  DoT-enabled) but not on the second (no clear reminder for
  authoritative name servers).
    
* What should be the criteria to select an authoritative name
  server to query? Should we prefer a fast insecure server or a slow
  encrypted one? The draft does not mention it, because it is local
  policy. (PowerDNS recursor has apparently no way to change its
  default policy, which is to use the fastest one, DoT or
  not.) The draft does not mandate such a knob in the authoritative
  server, again, IETF typically does not tell endpoints how they have
  to be configured.
  
* Should we do lazy probing, like PowerDNS Recursor does, or
  use the more eager "happy eyeballs" algorithm of the current draft?
  
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 ns1.eu.org (authoritative for eu.org)
or ns1-dyn.bortzmeyer.fr (authoritative for dyn.bortzmeyer.fr). Both
have authoritative on 53 and an open resolver on 853. Should we
explicitely ban this practice?

You may find some details of this work during the hackathon on my article:

https://www.bortzmeyer.org/hackathon-ietf-116.html