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.
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.