Adaptive DNS Discovery (add) Working Group + DNS PRIVate Exchange (dprive)

IETF 115

This was a joint meeting between the dprive and add working groups,
starting with dprive and continuing with add.

DNS PRIVate Exchange (dprive)

Chairs

• Brian Haberman brian@innovationslab.net
• Tim Wicinski tjw.ietf@gmail.com

Area Director

• Éric Vyncke evyncke@cisco.com

Recording

• Recording: dprive/add recording (dprive is the first part of
  the recording).

Agenda

Administrivia

• Agenda Updates, etc, 10 min
• NOTE WELL https://www.ietf.org/about/note-well.html

Current Working Group Business

Status of Unilateral-Probing

draft-ietf-dprive-unilateral-probing

Brian Haberman (chair)

• The WG chairs are looking for more implementations, and to receive
  feedback from implementers.

• Chair: there are two ways forward

  • Park the document while waiting for more implementations and
    then update it; or
  • Do the WGLC first, and then wait for implementations.

Comments:

• Benjamin Schwartz: Google resolver will probably implement
  something along these lines, but not exactly what's in the spec.

• Victor Dukhovni: sees some issues with implementations, e.g.,
  with short connections, but looking to hear more.

Document status (Paul Hoffman)

Since last:

• Puneet Sood restarted discussion with a list of suggestions. Authors
  responded with changed draft. No more comments.

• Looking for what implementors don't find in the document,
  especially resolver implementors. PowerDNS Recursor has implemented
  this, but the authors are hoping for more implementations.

Next steps:

• Within a month the authors will deal with open issues.
• The authors would love to see more discussion of the draft.
• They will turn in a new draft in mid-December 2022 and again hope
  for more discussion.
• The plan is to ask for WGLC in early January 2023.

Comments:

• Victor Dukhovni: please keep the authors of authoritative DNS
  servers in the loop. They are also implementers, and may have
  important views on, e.g., scaling.

New Working Group Business

There was none.

---

Adaptive DNS Discovery (add)

Date: Tuesday November 8, 2022
Time: 13:00-14:30 UTC

Chairs

• David Lawrence tale@dd.org
• Glenn Deen glenn.deen@nbcuni.com

Area Director

• Éric Vyncke evyncke@cisco.com

Recording

• Recording: dprive/add recording (add is the second part of the
  recording).

Notes

Lars-Johan Liman liman@netnod.se

https://notes.ietf.org/notes-ietf-115-add

Agenda

1 Administration

• IETF NOTE WELL
• Scribe selection
  Lars-Johan Liman volunteered as scribe for this session.
• Agenda bash
  Added discussion of draft-wing-opsawg-authenticating-network at the
  end.
• Welcome from chairs

• Information from the AD

  The three documents

  draft-ietf-add-ddr-10
  draft-ietf-add-dnr
  draft-ietf-add-svcb-dns-07

  are approved by the IESG for publication, but are waiting for work
  in the dnsop wg, which is also approved, but which is in turn
  waiting for other work. The IESG is trying to find a creative way of
  getting these published.

2.1 Split-Horizon DNS Configuration

draft-ietf-add-split-horizon-authority-03
Tiru Reddy Konda

Tiru went through the updates since last time. See slides at
establishing-local-dns-authority....

Note specifically new text that reinforces that special-use domain names
(SUDNs) MUST NOT be validated in the process described in this draft, as
SUDNs have been deemed out of scope for this document.

Editors think the document is ready for WGLC.

No questions nor any discussion.

2.2 DNS Resolver Information

draft-reddy-add-resolver-info-05
Tiru Reddy Konda

Tiru went through the updates since last time. See slides at
dns-resolver-information.

• Format changed from JSON to key=value leveraging DNS-SD, see [RFC
  6763].

The draft provides a straightforward solution to address the following
item in the WG charter:

...
Define a mechanism that allows communication of DNS resolver
information to clients for use in selection decisions. This could be
part of the mechanism used for discovery, above.

All received comments are addressed.

The authors belive this document is ready for WG adoption.

No questions nor any discussion.

A poll was conducted to assess the support for adopting the document in
the WG resulting in a slight preference for adoption. This will be
brought to the list.

2.3 DNS Server Redirection

draft-jt-add-dns-server-redirection
Tommy Jensen (and John Todd)

Tommy presented the new draft. See slides at
use-this-one-encrypted-dns-redirection.

Questions and discussion:

• Benjamin Schwartz: General support. Pointed out reference to DDR
  section 5. Discussion about how this related to other mechanisms for
  geo-based servers.
• Ted Hardie: Why is "reconfiguration" driven from the server
  side, rather than from the client side?
  Answ: was talked about, but this adds flexibility for the server
  operator. It's an "artificial burden" on whoever does the
  reconfiguration to do that at the endpoint, when the DNS can just
  handle it for you.
  Ted: I disagree completely. More flexible if the client does it.
  Look forward to discussion.
• Ralph Weber: What happens if the query comes back to the same
  server?
  Answ: If it redirects to the same name, no action should be
  necessary.
• Tommy Pauly: general support. Likes reuse of SVCB query. Suggest
  redoing SVCB query to the new server to ensure optimal routing.
  Answ: Hmm. Yeah. Let's think about that.
• Vittorio Bertola: not supportive. Warned for integrity and
  security problems with redirecting user queries to places they are
  not aware of.
  Answ. form John Todd: I belive it's the opposite. Compared to
  anycast it will be easier for the user to understand what's going
  on.
• Viktor Dukhovni: Are redirects mandatory and are multiple
  redirects a good idea?
  Answ: No, not mandatory. Multiple redirects are not encouraged.
  Can put better guidance in the doc.
• Eric Orth: HTTP have similar use cases for DoH. How do you see
  them interact?
  Answ: Don't want to use both.
  Eric: Some servers may prefer to solve in HTTP.
  John Todd: A more universal solution would be preferred. There are
  going to be more than one solution.
  Eric: "Universal" is ill-defined.
• Benjamin Schwartz: Just like Apple (above), Chrome has a
  bootstrapping method, and this proposes another one, so there is
  need for this functionality. Security problem: if discovery query is
  sent to a non-aware server, it will be passed to the general
  Internet, and anyone can fiddle with it and redirect to bad actor.
  The general problem is "transient to persistent" state.
  Chair and AD intervened to move this good discussion to the list.
• Erik Nygren: Similar discussion regarding change of trust is
  happening in the alt server side. Please look to that work for good
  input to the design.

3 AOB / Discussion

Asserting Wireless Network Connections Using DNS Revolvers' Identities

draft-wing-opsawg-authenticating-network/
Tiru Reddy Konda

Tiru presented this draft "for information". See slides at
asserting-wireless-network-connections-using-dns-resolvers-identities.

Tiru solicits more comments on the draft, and is looking for a suitable
working group for the document.

Discussion:

• David Schinazi: complex non-trivial solution solving a very
  small part of the problem space. The evil twin problem definitely
  exists, but not in all cases. Suggests taking a more holistic
  approach and solve it at a different level.
• Benjamin Schwartz: would like to try this. The cost is low. But
  the only authentication layer that makes sense is IP TLS. Risk of
  conflating network and name. The problem is not add, but might fit
  in the dance working group.

Chair: we've talked with the AD and we don't think this fits in add, but
we'll find a home for it.

4 Planning & Wrap up

Thanks, and remember to sign in to the "blue sheet".

END.