Skip to main content

Minutes IETF115: add: Tue 13:00
minutes-115-add-202211081300-00

Meeting Minutes Adaptive DNS Discovery (add) WG
Title Minutes IETF115: add: Tue 13:00
State Active
Other versions markdown
Last updated 2022-11-11

minutes-115-add-202211081300-00

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

Area Director

Recording

Agenda

Administrivia

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

Area Director

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.