# Adaptive DNS Discovery (add) Working Group + DNS PRIVate Exchange (dprive)   {#adaptive-dns-discovery-add-working-group--dns-private-exchange-dprive}

## IETF 115   {#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)   {#dns-private-exchange-dprive}

### Chairs   {#chairs}

*   Brian Haberman [brian@innovationslab.net](brian@innovationslab.net)
*   Tim Wicinski [tjw.ietf@gmail.com](tjw.ietf@gmail.com)

### Area Director   {#area-director}

*   Éric Vyncke [evyncke@cisco.com](evyncke@cisco.com)

### Recording   {#recording}

*   Recording: [dprive/add recording][1] (dprive is the first part of
    the recording).

## Agenda   {#agenda}

### Administrivia   {#administrivia}

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

### Current Working Group Business   {#current-working-group-business}

#### Status of Unilateral-Probing   {#status-of-unilateral-probing}

[draft-ietf-dprive-unilateral-probing][2]

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   {#new-working-group-business}

There was none.

* * *

# Adaptive DNS Discovery (add)   {#adaptive-dns-discovery-add}

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

### Chairs   {#chairs-1}

*   David Lawrence [tale@dd.org](tale@dd.org)
*   Glenn Deen [glenn.deen@nbcuni.com](glenn.deen@nbcuni.com)

### Area Director   {#area-director-1}

*   Éric Vyncke [evyncke@cisco.com](evyncke@cisco.com)

### Recording   {#recording-1}

*   Recording: [dprive/add recording][1] (add is the second part of the
    recording).

### Notes   {#notes}

Lars-Johan Liman [liman@netnod.se](liman@netnod.se)

[https://notes.ietf.org/notes-ietf-115-add][3]

## Agenda   {#agenda-1}

### 1 Administration   {#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][4]  
    [draft-ietf-add-dnr][5]  
    [draft-ietf-add-svcb-dns-07][6]
    
    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   {#21-split-horizon-dns-configuration}

[draft-ietf-add-split-horizon-authority-03][7]  
Tiru Reddy Konda

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

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   {#22-dns-resolver-information}

[draft-reddy-add-resolver-info-05][9]  
Tiru Reddy Konda

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

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

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   {#23-dns-server-redirection}

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

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

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   {#3-aob--discussion}

#### Asserting Wireless Network Connections Using DNS Revolvers' Identities   {#asserting-wireless-network-connections-using-dns-revolvers-identities}

[draft-wing-opsawg-authenticating-network/][14]  
Tiru Reddy Konda

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

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   {#4-planning--wrap-up}

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

END.



[1]: https://play.conf.meetecho.com/Playout/?session=IETF115-ADD-20221108-1300
[2]: https://datatracker.ietf.org/meeting/115/materials/slides-115-add-status-of-draft-ietf-dprive-unilateral-probing
[3]: https://notes.ietf.org/notes-ietf-115-add
[4]: https://datatracker.ietf.org/doc/draft-ietf-add-ddr/
[5]: https://datatracker.ietf.org/doc/draft-ietf-add-dnr/
[6]: https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/
[7]: https://datatracker.ietf.org/doc/html/draft-ietf-add-split-horizon-authority-03
[8]: https://datatracker.ietf.org/meeting/115/materials/slides-115-add-establishing-local-dns-authority-in-split-horizon-environments
[9]: https://datatracker.ietf.org/doc/html/draft-reddy-add-resolver-info-05
[10]: https://datatracker.ietf.org/meeting/115/materials/slides-115-add-dns-resolver-information
[11]: https://www.rfc-editor.org/rfc/rfc6763.html
[12]: https://datatracker.ietf.org/doc/draft-jt-add-dns-server-redirection/
[13]: https://datatracker.ietf.org/meeting/115/materials/slides-115-add-use-this-one-encrypted-dns-redirection
[14]: https://datatracker.ietf.org/doc/draft-wing-opsawg-authenticating-network/
[15]: https://datatracker.ietf.org/meeting/115/materials/slides-115-add-aob-asserting-wireless-network-connections-using-dns-resolvers-identities