Joint Interim on Split-DNS ADD-DNSOPS-DPRIV Notes

January 26, 2022 Joint Interim on Split-DNS ADD-DNSOPS-DPRIV

This is a joint interim with DNSOP, DPRIVE, ADD groups on the topic of Resolver Discovery in Split DNS environments

Meeting Materials, Links

Materials, Charter, Documents

Materials, Charter, Documents

Interim Session times

Agenda

Administration

Introduction

Notes on this session:

1. Background on this Discovery for Split DNS discussion

2. Acknowledging Split DNS is widely deployed and likely here to stay, what is need for discovery?

2.1 Presentation: Proposed approaches on a few issues - Ben Schwartz et al. (20 minutes + discussion)

Slides for the presentation.

Current Definition of "split dns" https://www.rfc-editor.org/rfc/rfc8499.html#page-21

Michael Richardson: People think they have compatible security assumptions because of overloaded terminology,
but they do not. Are use cases where what is missing is an accurate technical description. Is that in focus?

Ben: Yes

introduce new resolver type: "Hybrid Resolver"

(Most excellent graphics)

Tommy Pauly: dual facing resolution. split horizon w/hijacking.

Ben: name doesn't exist, then hijacking.

Paul Wouters: many meetings over the IKEv2 split DNS, concerns over that trust relationship.
For coffee shop networks, no names can reasonably be overwritten. solution needs to support all of these.

Ben: need to authenicate the identity of network resolver

Warren Kumari: many more messy things, ex DNS64. and this is an RFC.

Andrew Campling: leaking names in Enterprise space. to valudate its not hijacking need a 2nd resolver to confirm.

EKR: concerned about typos, "gsnail.com" leaks. captive portals are special-case.
agree in principle, if i hijack .ekr in practice can not authenicate via root.

Paul Vixie: new use case not compatible to the defintion of 'split-dns'. in pratice defintion of
split-dns is more subtle and involves filtering results.

2.2 Open Mic Line: Discussion on what is important in scoping the discovery requirements

Glenn Deen: A takeaway I have is that anything that comes out of ADD needs to be clear about what use case is being solved.

Paul Wouter: network present a list of domains and some authorization over the list
list signed via certificate

Christian Huitema: assumptions the way the client accesses the internal hosts

ekr: not sure clear statement what we're trying to do. DNSSEC

Tommy Pauly: +1 to Paul W on the hints. one case is the vpn case.

Warren: Make sure we are not only solving use cases that are convenient. Also, not fall into the
behavior of getting list of what authoriative for. don't ignore icky use cases.

Andrew C: +1 to Warren.

Dave Lawrance: Read chat discussion about what is in scope.

Ben S: Want to do the opposite of what Warren said. Let’s address one that we know are needed. Try to map out all the tricky sub-case and identify which solutions fit where. HTTP transparent proxy from the 90s, became clear that was not compatible with HTTPs, so it slowly faded out.

Paul Vixie: when someone is being tracked, not just for their best interest, leakage is still relevant.
there is a perceived good of transparency/non-transparency. Network providers may do some tracking, but it should
be a case of transparency over perhaps consent.

Ted: Be clear about what we can solve and provide what we can and can not cover. do not think it is useful
to lay out all the ways people use split dns and map the problem space.

Eric Orth: Cases map into what is in the charter.

2.3 Other considerations?

3.0 Other Discussion Topics

4.0 Planning & Wrap up

[agenda end]

The following is the Chat Log from the session

[end notes]