Skip to main content

Minutes interim-2022-add-01: Wed 09:00
minutes-interim-2022-add-01-202201260900-00

The information below is for an old version of the document.
Meeting Minutes Adaptive DNS Discovery (add) WG Snapshot
Date and time 2022-01-26 17:00
Title Minutes interim-2022-add-01: Wed 09:00
State Active
Other versions markdown
Last updated 2022-01-28

minutes-interim-2022-add-01-202201260900-00

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

Agenda

Administration
  • IETF NOTE WELL https://www.ietf.org/about/note-well.html
  • Scribe selection
  • Agenda bash
  • Welcome from chairs

    Introduction

    Notes on this session:

  • Split DNS is widely deployed operationally and there is a desire
    for users of it to have a discovery mechanism to discover DoH and
    DoT relevant resolvers so that they can make use of encrypted DNS.

  • This is not organized as a referendum on Split DNS, nor a workshop
    on how to end the practice.

    1. Background on this Discovery for Split DNS discussion
  • Split DNS in this context means: Networks having different
    internal/external name mapping in their DNS name space.

  • ADD WG has expressed consensus to work on the problem of DoH/DoT
    discovery in Split DNS environments
  • ADD WG has not yet reached clear consensus at this point on how to
    address Split DNS discovery
  • Issues outside of ADD's charter scope have been expressed as
    concerns including: (1) Validation of resolvers authority; (2)
    Validation of answers; (3) Potential Role of DNSSEC
  • ADD WG Adopted Drafts on discovery in non Split DNS environments and
    are nearing WG Last Call: (1) Discovery of Designated Resolvers
    https://datatracker.ietf.org/doc/draft-ietf-add-ddr/; (2) DHCP and
    Router Advertisement Options for the Discovery of Network-designated
    Resolvers (DNR) https://datatracker.ietf.org/doc/draft-ietf-add-dnr/

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

https://datatracker.ietf.org/meeting/interim-2022-add-01/materials/slides-interim-2022-add-01-sessa-the-split-horizon-dns-problem

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

  • Some items:
  • Restricting the scope of discovery to resolers of split-horizon DNS names that are properly rooted in the global DNS.
  • Clarification of Terminology for: (1) hybrid resolver/client; (2) authorized split horizon; (3) domain camping
  • Using DNSSEC to confirm authority over the split-horizon domains

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

  • Seed issues:
  • Is validation of resolvers authority to answer queries for domains needed?
  • Is answer validation needed for domains resolved in Split DNS environments?
  • DNSSEC is generally not used for the non-global names in Do53 Split DNS environments, so why would it be different for Encrypted DNS?

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?

  • Are there past IETF I-Ds/RFCs that need to be referenced?
  • Question to group: Is there related work external to the IETF to be considered?

3.0 Other Discussion Topics

  • From Mic Line

4.0 Planning & Wrap up

  • 5 min - Wrap up

[agenda end]

The following is the Chat Log from the session

  • [16:51:07] < Christian Huitema_web_797> Good morning, adders!
  • [16:51:22] < Christian Huitema_web_797> (or is it addlers?)
  • [16:51:34] < Benno Overeinder_web_758> Goodafternoon DNSOPers
  • [16:52:40] < Glenn Deen_web_770> and welcome dprive too
  • [16:54:34] < Glenn Deen_web_770> oh now, I'm getting page not found from datatracker when trying to use the meeting materials in meetecho
  • [16:58:40] < Ted Hardie_web_626> Aren't adders snakes? Perhaps additions?
  • [16:59:24] < Benjamin Schwartz_web_133> "ADD sufferers"
  • [17:00:30] < Christian Huitema_web_797> You wouldn't want to step on a knot of adders, would you?
  • [17:00:48] < dkg> Christian, i think it's "addleds"
  • [17:01:16] < dkg> looks good
  • [17:01:28] < Chris Box_web_245> A half adder is usually harmless
  • [17:02:31] < Tim Wicinski_web_649> I will be attempting to take minutes here https://notes.ietf.org/notes-ietf-interim-2022-add-01-add?edit
  • [17:03:37] < Éric Vyncke_web_402> Thanks Tim
  • [17:03:53] < Éric Vyncke_web_402> BTW, Warren told me that he will be late by 15 minutes or so
  • [17:05:02] < Michael Richardson_web_518> I can help scribe, but I have to leave at the top of the hour for RATS virtual interim.
  • [17:06:02] < Tim Wicinski_web_649> https://datatracker.ietf.org/meeting/interim-2022-add-01/materials/slides-interim-2022-add-01-sessa-the-split-horizon-dns-problem
  • [17:06:11] < Tim Wicinski_web_649> Ben's slides if you wish to follow along at home
  • [17:07:57] < Petr Špaček_web_115> Excellent "Notes on this session", I have to say.
  • [17:10:27] < Benno Overeinder_web_758> :thumbsup:
  • [17:14:32] < Warren Kumari_web_380> Apologies all for being late - had to deal with appliance drama... :-P
  • [17:14:59] < Paul Wouters_web_338> I am making coffee too :)
  • [17:15:19] < dkg> yes, we see them
  • [17:16:08] < Éric Vyncke_web_402> @Warren you announced 15 minutes and you in at 14:32 ;-)
  • [17:16:25] < Mirja Kühlewind_web_487> @Tim can you mute?
  • [17:16:54] < Tim Wicinski_web_649> apologies
  • [17:16:59] < Mirja Kühlewind_web_487> thx
  • [17:17:31] < dkg> they also do it by accident because they don't understand what they're doing with their IT systems ☹
  • [17:17:43] < Chris Box_web_245> I would say this isn't limited to network-provided resolvers. The device's configured resolver can also give meaningfully different answers.
  • [17:18:42] < Tim Wicinski_web_649> https://www.rfc-editor.org/rfc/rfc8499.html#page-21 current def of "split dns"
  • [17:19:39] < Warren Kumari_web_380> erm.... "not allowed" feel a little funny in this context, but Ok....
  • [17:19:42] < Duane Wessels_web_679> is it hijacking if you give the right answer?
  • [17:19:48] < Éric Vyncke_web_402> Local reply to 1.1.1.10.in-addr.arpa is another example which is ambivalent though ;-)
  • [17:19:59] < Éric Vyncke_web_402> But I like the slides
  • [17:20:14] < Warren Kumari_web_380> "It's complicated" would probably be the best title for that :-P
  • [17:20:16] < dkg> Duane, that sounds like forwarding, not answering
  • [17:20:25] < Petr Špaček_web_115> I think we need to keep in mind that tone of enterprises does "DNS hijacking" as defined here on .local, .internal etc.
  • [17:20:36] < Andrew Campling_web_455> A document that captures the use cases and definitions for terms would be helpful so that we have an agreed starting point that any proposed solutions can reference.
  • [17:20:42] < Benno Overeinder_web_758> I have also heard of scenario's with company mergers. First using split horizon (using one infra for the merged company) and later getting rid of the split horizon.
  • [17:20:52] < Paul Wouters_web_338> not .local ? we have an RFC on that? :)
  • [17:21:04] < Warren Kumari_web_380> @DKG: What if you set the authjorative bit?
  • [17:21:22] < dkg> Benno: those kind of collisions during org merge also happen with RFC1918 IP address ranges
  • [17:21:43] < dkg> Warren: that does sound like hijacking to me
  • [17:21:54] < Tim Wicinski_web_649> i would say not "also" but "always" happens
  • [17:22:36] < Eric Rescorla_web_806> +1 to exactly what MCR is saying
  • [17:22:44] < Ted Hardie_web_308> pomme(de terre)
  • [17:22:56] < Paul Wouters_web_338> "I am protecting you" vs "You are deceiving me"
  • [17:23:16] < Warren Kumari_web_380> I think that much of the "hijacking" definition / term has lots of "I know it when I see it" in it...
  • [17:23:39] < dkg> i know a banana when i see it
  • [17:23:55] < Paul Wouters_web_338> to scale?
  • [17:24:09] < Eric Orth_web_718> The second "boring" case might lead to "alternative" mechanisms that are not split DNS.
  • [17:24:17] < Warren Kumari_web_380> e.g: If I do localroot, I'm answering authoritatively, but perhaps not according to the earlier defintion of authorized...
  • [17:24:36] < Andrew Campling_web_455> @dkg: It might be a plantain
  • [17:24:37] < Warren Kumari_web_380> Anyway, rathole...
  • [17:25:00] < Paul Wouters_web_338> localroot is just caching real answers. not that different from routing port 53 to the live servers
  • [17:25:01] < Tommy Pauly_web_342> @Eric Orth True, the case of using other resolvers — like knowing I have an enterprise resolver for some domains — allows a solution for "split DNS"
  • [17:26:04] < Warren Kumari_web_380> @Paul: Depends on how it is implemented - if you download and forward to it, then the "auth" side of it could be viewed as hickaing. Again, the intent is somewhat important here.
  • [17:27:17] < Vladimír Čunát_web_668> Here I wouldn't call it hijacking if it gives the same answer.
  • [17:28:01] < Warren Kumari_web_380> Yup, I agree. My point was that the provided definition is incomplete, and that any actual definition is hard....
  • [17:28:13] < Christian Huitema_web_797> Memories of NetBios...
  • [17:28:16] < Paul Wouters_web_338> the split in split-dns is on the client, not on the network. Or rather, the network behaviour is a wholy other matter
  • [17:28:28] < Benno Overeinder_web_758> Many resolver already implement this behaviour, not for split DNS, but running local root for example.
  • [17:28:43] < Éric Vyncke_web_402> true
  • [17:28:45] < Tommy Pauly_web_342> Right, the VPN case of split DNS is a local rule for splitting traffic between the network and the VPN
  • [17:28:47] < mcr> I love the shapes.
  • [17:28:56] < Éric Vyncke_web_402> Yeap, nice sldies
  • [17:28:59] < Andrew Campling_web_455> @Warren hickaing? Covfefe!
  • [17:29:05] < Benno Overeinder_web_758> Indeed, very clear!
  • [17:29:28] < Benno Overeinder_web_758> (the slides and presentation)
  • [17:29:45] < Paul Wouters_web_338> flashback to long AD assisted side meetings on IKEv2 split DNS RFC :)
  • [17:29:56] < Warren Kumari_web_380> @Benno: Yah. Or "locally served zones" (e.g: rfc1918 in-addr.arpa) or RPZ, or mitigations for DoS, or...
  • [17:29:57] < Petr Špaček_web_115> The shapes remarkably clearly show architectural complications of DNS resolvers :-D Nice work!
  • [17:30:30] < Benno Overeinder_web_758> @warren: indeed. :-)
  • [17:30:31] < Warren Kumari_web_380> Another really important, but squishy bit is DNS64...
  • [17:30:48] < Paul Wouters_web_338> but only after confirming via provisioning !
  • [17:30:50] < dkg> to work on the DNS you must now be able to solve a jigsaw puzzle
  • [17:30:51] < Petr Špaček_web_115> I was hoping nobody will mention this ...
  • [17:31:29] < Erik Nygren_web_938> oooh, good point on DNS64. I wonder how that best fits into this model, especially given how prevalent it is now. (does it count as hijacking if endorsed by an rfc?)
  • [17:31:43] < Éric Vyncke_web_402> DNS64 could also be split if there are split NAT64 ;-)
  • [17:31:52] < Warren Kumari_web_380> @Petr: I think that it is important -- there is a tendency to underestimate the complxity of the real world in much of these discussions
  • [17:31:59] < dkg> can someone unpack the specific problems raised by DNS64 for this topic?
  • [17:32:07] < Benno Overeinder_web_758> @paul, true
  • [17:32:10] < Warren Kumari_web_380> and / or assertions that they are corner cases.
  • [17:33:24] < Warren Kumari_web_380> @DKG: if all you have is IPv6, and need to reach www.ipv4only.net, your DNS server will "hijack" the lookup for www.ipv4only.net and synthenize a AAAA answer to send to a NAT64 box.
  • [17:33:54] < Éric Vyncke_web_402> DKG: DNS64 will create AAAA for a zone that it does not own
  • [17:34:29] < Vladimír Čunát_web_668> (if the name has A and not AAAA)
  • [17:35:09] < Christian Huitema_web_797> DNS64 is an interesting way to load the camel.
  • [17:35:10] < Paul Wouters_web_338> dkg: it synthesizes DNS records,so it cant have DNSSEC guarantees
  • [17:35:15] < Erik Nygren_web_938> And this is scoped to the network and applies across all zones, so doesn't really fit into this model but is rather orthogonal.The alternative is for clients to resolve ipv4only.arpa (which is explicitly provided by the local network) and for the clients to do the synthesis of AAAA from A.
  • [17:35:18] < Warren Kumari_web_380> So, I look up www.ipv4only.net, and the DNS64 server replaces 192.0.2.1 with 64:ff9b::192:0:2:1. This gets router to a NAT64 box, which extract the last bit, does does nat to convert IPv6 to IPv4. This is quite common, esp on mobile
  • [17:35:25] < dkg> thx all for the explanation; where do folks think this sits in Ben's taxonomy of DNS hijacking / split horizon
  • [17:35:53] < Warren Kumari_web_380> Generally, we try and ignore DNS64, because it makes questions like that hard :-P
  • [17:36:09] < Warren Kumari_web_380> This comes back and bites us later :-)
  • [17:37:07] < Christian Huitema_web_797> Or maybe we should treat DNS64 the same way as other transition technologies...
  • [17:37:16] < dkg> paul, feel free to write here and we can relay
  • [17:37:33] < Duane Wessels_web_679> I think "DNS hijacking is not allowed within IETF standards" is a false statement
  • [17:37:38] < dkg> Christian Huitema: you mean, let it linger indefinitely with no way to effectively kill it off?
  • [17:37:47] < Erik Nygren_web_938> It might be another class of things? (ie, a filter). It may have some degree of similarities to networks that replace names with NXDOMAIN or other values to do content filtering, albeit with different potential desirability on behalf of an end-user. (ie, without DNS64 the network just doesn't work)
  • [17:37:52] < Warren Kumari_web_380> @Duane: Yes.
  • [17:38:06] < Sean Turner_web_651> I had that problem too, seemed to fix itself after returning
  • [17:38:28] < Christian Huitema_web_797> Teredo and 6to4 have seen their usage drop to almost zero. I think we should have the same goal for DNS64.
  • [17:38:37] < Éric Vyncke_web_402> The smoke/vapor on Ben's background is weird...
  • [17:38:45] < Warren Kumari_web_380> Also, DNS hijacking happens constantly -- e.g captive portals. Pretending that things doesn't exist is part of a standard IETF failure mode.
  • [17:39:00] < Éric Vyncke_web_402> @Christian, I do not expect NAT64 going away before 10+ years :-(
  • [17:39:47] < Warren Kumari_web_380> Many ISPs also use these for subscribe menagemnt (when you get a new comcast modem), gvmnts use them for objectionable content blocking, etc.
  • [17:40:05] < Erik Nygren_web_938> If anything, DNS64+NAT64+464xlat is accelerating as one of the major transition technologies. (It's likely that a majority of mobile phone connectivity relies on it globally now, but I don't have exact answers.)
  • [17:40:08] < Christian Huitema_web_797> We could encourage the "in the host" solution. Ten it becomes a matter of accomodating legacy IPv4 only hosts, and that could be segregated.
  • [17:40:59] < Paul Hoffman_web_606> That is not a problem "for ICANN", it is a problem for the entire DNS community.
  • [17:41:22] < Suzanne Woolf_web_698> @Warren +1. We tend to act as if solving a different problem will make people migrate away from the problem they currently have to one we've solved. But telling people to have a different problem usually doesn't get them where they need to go.
  • [17:41:47] < Erik Nygren_web_938> There have been a few drafts in this area (eg, https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec ) but most of those solutions require non-technical mandates that the IETF can't really enforce.
  • [17:42:24] < Eric Rescorla_web_806> Wouters: we can see you, so with luck, we can hear you soon!
  • [17:42:45] < Dan Wing_web_444> DNS64 can work with DNSSEC, details at https://datatracker.ietf.org/doc/html/rfc6147#section-3
  • [17:43:06] < Petr Špaček_web_115> Well, there are published approaches to this "does not exist in public but exists internally" problem. One of them: https://patents.google.com/patent/US20160197898A1/en
  • [17:43:11] < Paul Wouters_web_537> gma1l.com would be tricky for that
  • [17:43:31] < Eric Rescorla_web_806> The local fallback is actually not ideal because it causes leaks of non-resolvable domains
  • [17:43:59] < Petr Špaček_web_115> @Eric: Depends on level. For root it is easy to solve - just grab a local copy.
  • [17:44:18] < Petr Špaček_web_115> I mean - grab a copy and search it locally. Then it does not leak anything.
  • [17:44:35] < Ted Hardie_web_308> This turns out to be advice like "if you sort your nsswitch.conf file so that the public dns resolver is first, this will make your life easier. You may need to make your private namespace design congruent with this approach"
  • [17:45:06] < Ted Hardie_web_308> @Eric agreed, but is this the least worst problem in this can of eels?
  • [17:46:27] < Dan Wing_web_444> @Eric, re-opening browser tabs while on Starbucks wifi leaks those queries, too.
  • [17:47:24] < Christian Huitema_web_797> What f, as a consultant, I have access to several split-DNS resolvers?
  • [17:47:53] < mcr> oooh! we need Spherical DNS resolvers to be compatible with our spherical routers!
  • [17:47:58] < Paul Wouters_web_537> reconfigure your local dns (stub) via different forwarders
  • [17:48:53] < Paul Wouters_web_537> imho: captive portal is a pre-network and pre-dns config scenario. I think we should assume that happens seperately from this split-dns discussion
  • [17:50:09] < Petr Špaček_web_115> +1 to Paul's comment
  • [17:50:48] < Warren Kumari_web_380> A huge number of companies have www.company.com resolve differently internally to www.company.com externally, and they also want this to wok with BYOD devices.
  • [17:51:14] < Paul Wouters_web_537> warren: use guest wifi with IKEv2 VPN ? :)
  • [17:51:44] < Paul Wouters_web_537> (seriously, some kind of trusted / authenticated information exchange of domain list)
  • [17:52:03] < dkg> Warren: i've seen many such deployments, and about half of them are broken in subtle ways (like also resolving company.com, no www, with a wrong address)
  • [17:52:34] < Tommy Pauly_web_342> Agreed with ekr on filtering the fallback
  • [17:52:41] < Warren Kumari_web_380> Oh! I know, we could distribute this list via DHCP! (Warren runs away, giggling)
  • [17:52:42] < Tommy Pauly_web_342> And yes, captive portals are easy to special-case
  • [17:52:48] < Paul Wouters_web_537> yes, +1 ekr on that
  • [17:53:08] < Tommy Pauly_web_342> If you know it's local network (like portals) it's simple to handle
  • [17:53:48] < Paul Wouters_web_537> did ker just reveal is home domain is .ekr ? :)
  • [17:53:52] < Ted Hardie_web_308> @Warren Just hijack sri-nic.arpa and distribute local names as a host file instead of using the DNS.
  • [17:54:02] < Warren Kumari_web_380> @Ekr: Yes, it is a special case, but it needs to be addressed (even if you just say "Don't do X until you know you are in the Internet")
  • [17:54:02] < Éric Vyncke_web_402> Wondering whether this meeting drifts more on a split DNS discussion rather than on designated resolver discovery (albeit both are linked)
  • [17:54:21] < mcr> I have been trying to take notes in the official HedgeDoc. I wonder if someone else is taking notes elsewhere?
  • [17:54:26] < mcr> I have to leave in five minutes.
  • [17:54:41] < Paul Wouters_web_537> the split is the problem space that is vital to what methods of discovery are viable
  • [17:54:57] < Christian Huitema_web_797> I can't help thinking of a simple-but-wrong solution, a configuration line that says "for *.example.com use "internal-dns.example.com"...
  • [17:55:05] < Warren Kumari_web_380> @Eric: yes, to me it feels much more like a "DNS problem" than a resolver problem.
  • [17:55:16] < Eric Rescorla_web_806> Let us also not forget .eth!
  • [17:56:00] < Warren Kumari_web_380> Thank you Paul V! I was just starting to mention that we also need to figure out how this fits with RPZ.
  • [17:56:18] < Paul Wouters_web_537> Also, I think vixie looks like a jedi figher. May the force be with him !
  • [17:56:42] < Warren Kumari_web_380> s/looks like/is/
  • [17:56:57] < mcr> Tim and I found that we had different links, but he is doing a better job than I was :-)
  • [17:57:17] < Tommy Pauly_web_342> I think filtering is a separate case than split DNS as on the table here. Such a case would generally involve a network wanting to see all the names in order to filter.
  • [17:57:28] < Éric Vyncke_web_402> Let's reconciliate the minutes AFTER then ;) rather than having split-horizon minutes
  • [17:58:09] < Vladimír Čunát_web_668> I do consider the splitting closely related to (some kinds of) filtering.
  • [17:58:42] < Tommy Jensen_web_265> In line with Ben's point about building solutions only for technical gaps, I would assert that enterprises should directly manage devices where they want behavior that cannot be verified as secure by protocol use only. In other words, the solution may not be protocol based but product based where behavior about resolver choice is solved out of band.
  • [17:58:44] < Tommy Jensen_web_265> Maybe defining when each is the better solution should be considered for each use case.
  • [17:59:00] < Christian Huitema_web_797> Ben classified as boring the case in which the domain can control the device configuration. Do we agree?
  • [17:59:33] < dkg> the BYOD case is the hard part, i think -- the admin doesn't (and shouldn't) control the device
  • [17:59:45] < Paul Wouters_web_537> also look at the future: mixing BYOB with Managed Devices, we might end up on a per-app DNS setting
  • [17:59:54] < Jim Reid_web_487> Well Christian, I for one think that particular use case is boring
  • [18:00:00] < Robert Evans_web_175> That scenario excludes clients that assume global DNS is available in some way - the crux of the problem is enterprises probably don't want to pay to patch/ban/manage every such client in their network
  • [18:00:10] < Éric Vyncke_web_402> @DKG quite often BYOD is linked to some sort of MDM...
  • [18:00:13] < Eric Orth_web_718> @Christian: I agree. If the device is controlled, they can control it to make the right DNS queries without any IETF mechanism to tell it how.
  • [18:00:13] < Christian Huitema_web_797> Also, do we have agreement on the network topology, i.e. how the BYOD device is supposed to access the internal hosts?
  • [18:00:44] < Erik Nygren_web_938> It seems like there are options even for BYOB if the domain collaborates. (eg, if the PvD record for "use resolver $foo for domain example.com" has a DNSSEC signature from example.com.)
  • [18:00:56] < Warren Kumari_web_380> If the device is MDM'ed, then it largely isn't BYOD, it is "lend your company your personal device"
  • [18:01:28] < Christian Huitema_web_797> If we assume that the device accesses the internal host either through a connection to a controlled network or through a VPN, does it simplify the issue?
  • [18:01:38] < Warren Kumari_web_380> If there is MDM, the 'Y' mostly disappears.
  • [18:01:41] < Éric Vyncke_web_402> Just wondering how many major corporations accept BYOD w/o MDM for 'really usefull apps'
  • [18:02:04] < Paul Wouters_web_537> the world is moving towards compartmentalizing a phone where some apps are managed and allowed access and others are not and just have 'internet access'
  • [18:02:06] < Tommy Pauly_web_342> (A VPN solves the issue, so far simpler)
  • [18:02:13] < Warren Kumari_web_380> @Cristian: it does simplify things, but it conflicts with what many IT admins would want to have to do...
  • [18:03:17] < Éric Vyncke_web_402> VPN from a corp network to the corp is not always the shortest path...
  • [18:03:36] < Warren Kumari_web_380> This again feels like "the real world use makes this harder, lets tell people not to do this, and then we can igonre the problem"
  • [18:03:40] < Éric Vyncke_web_402> ANyway, this is not really linked to the topic of the meeting ;-)
  • [18:04:40] < Erik Nygren_web_938> and the "Zero Trust" push is shifting things away from the "just use a VPN" model and often has something like a localhost agent acting as a DNS resolver or dispatcher.
  • [18:04:54] < Éric Vyncke_web_402> Another interesting case is of course having 2 connections (cellular + WiFi) and asking for internal.example.org ;-)
  • [18:05:10] < Éric Vyncke_web_402> Hence the need for PvD (from a RFC 8801 authors)
  • [18:05:12] < Robert Evans_web_175> also roaming needs consideration
  • [18:05:38] < Dan Wing_web_444> @Paul, I have a proposal for a certificate like you described at the mic. Advantage it avoids the client chatting with public DNS (which might be restricted, as said by others during meeting).
  • [18:05:46] < Éric Vyncke_web_402> @Erik indeed, I can see the end of VPN & split DNS in favor of zero-trust
  • [18:06:02] < Robert Evans_web_175> the same split dns names might be visible via (client authenticated) DoH/DoT as an internal resolver via Do53
  • [18:06:18] < Paul Wouters_web_537> dan: yeah like if you do EAPTLS like things to connect to the wifi, the cert could have a domain list embedded
  • [18:06:25] < Tommy Jensen_web_265> In addition, it seems to make sense that we create solutions even if they rely on public DNS since that will be a common scenario with Zero-Trust evolutions where there is no inherent trust in any network endpoint (not to dismiss the local cases described, simply to say that public-dependent scenarios are still worth solving on their own).
  • [18:06:35] < Paul Wouters_web_537> but again the problem is if that contains rogue entries
  • [18:08:48] < Tommy Jensen_web_265> (in a nutshell, +1 to Erik since I missed that message while typing mine)
  • [18:08:56] < Paul Wouters_web_537> I'd phrase it more as "the enterprise forces me to trust them", but yes what Tommy says :)
  • [18:11:07] < Christian Huitema_web_649> Warren is speaking about filtering. Is that in scope?
  • [18:11:32] < dkg> it would be great to define whether filtering is out of scope -- that has come up repeatedly today
  • [18:11:56] < Vladimír Čunát_web_668> If you split to some other resolver that does whatever, even filtering?
  • [18:13:10] < Dan Wing_web_444> The confusion with filtering is that today's filtering is implemented using the same configuration as split DNS is configured.
  • [18:13:11] < Vladimír Čunát_web_668> I mean, IMHO in both cases you give away control over a subtree.
  • [18:13:19] < Paul Wouters_web_537> dkg: is filtering not a property after the choice of resolver you make? Or are you saying you want a mcehanism to switch based on observed behaviour of your chosen DNS ?
  • [18:14:28] < dkg> Paul Wouters: if i wanted to filter, i'd want it to happen after i choose resolvers, yes. but i also don't want my DNS filtered at all, so i might not be the most representative for the use case.
  • [18:14:32] < Warren Kumari_web_380> @Paul: Maybe. But I suspect that my views and e.g the Australian gvmnt (or my wife's company!) views differ...
  • [18:14:42] < Glenn Deen_web_770> filtering or not isn't part of discovery, it's a behavior of the resolvers. So neither in or out of scope - it's a different conversation
  • [18:14:57] < Robert Evans_web_175> standards-based network assertions over DNS are only going to be useful if most/all use cases are accommodated... otherwise the status quo will continue for the unsupported use cases
  • [18:15:12] < Paul Wouters_web_537> I would say a choice based on detected/advertised filtering is a local client policy
  • [18:15:28] < Christian Huitema_web_649> We keep hearing the "dns as gatekeeper" request, i.e., force (some) clients to use a specific DNS server and only that one, so the DNS server can filter. Should that be a separate topic, and which group should address that?
  • [18:16:10] < Paul Wouters_web_537> signed domain lists certificate transparency ? :)
  • [18:16:27] < Eric Rescorla_web_806> That practice was replaced iwth MITM proxies :)
  • [18:16:36] < Paul Wouters_web_537> :)
  • [18:17:07] < Andrew Campling_web_455> @Ben: Agree its sensible to focus on solvable problems providing that these don't limit solutions to tiny edge cases
  • [18:17:20] < Vladimír Čunát_web_668> Yes.
  • [18:17:20] < Christian Huitema_web_649> At least some organizations do NOT want MITM proxies, because they collect toxic data.
  • [18:17:22] < Erik Nygren_web_938> In many case vendors were able to switch from HTTP filtering to DNS filtering. If we break DNS filtering, those vendors will have little incentive to not switch back to HTTPS MitM filtering.
  • [18:17:42] < Eric Rescorla_web_806> @huitema: true
  • [18:18:12] < Warren Kumari_web_380> @EKR: Actually, yes. We don't want to drive the same sort of thing happening to the DNS or because of this...
  • [18:18:15] < Eric Rescorla_web_806> @Erik: I don't think that's correct, because you need to manage the machine to do HTTPS MITM filtering and if you can manage the machine, then you can also configure DNS filtering
  • [18:18:26] < Tommy Pauly_web_342> @Paul Vixie Preventing tracking can be achieved in other ways (oblivious queries, etc)
  • [18:18:47] < Tommy Jensen_web_265> ekr: bingo, +1
  • [18:18:48] < Warren Kumari_web_380> (We need to beware of unintended consequences)
  • [18:21:11] < Vladimír Čunát_web_668> User's consent is quite tricky in practice, though. Majority of people will just click OK to get their internet working.
  • [18:21:29] < Lixia Zhang_web_816> agree with Vixie on the need for transparency
  • [18:21:34] < Erik Nygren_web_938> @ekr: some customers of filtering products will always want fine-grained filtering. The switch to HTTPS made it easy to argue that "DNS" was all you could get within reasonable trade-offs. If it is as easy to do HTTPS filtering as DNS filtering (eg, installing a CA/policy into the client is needed for either) then those customers will be excited to switch back to fine-grained HTTPS filtering.
  • [18:21:59] < Andrew Campling_web_480> @Vladimir: to be fair, there are many worse instances than DNS where that already applies today
  • [18:22:06] < Vladimír Čunát_web_668> :-)
  • [18:23:09] < Tommy Jensen_web_265> +1 to Paul on being transparent about behavior. This enables clients acting on their own policy. We do have to keep in mind that it's still Hard for that clam to be verifiable, though positive claims about filtering probably can be trusted (who would say they hijack when they don't?)
  • [18:23:19] < Christian Huitema_web_649> Transparency is more than user constant. It is also about making policies public. There is a difference between "your enterprise filtered virus-are-us.net" and "your ISP filtered Wikipedia".
  • [18:24:29] < Tommy Jensen_web_265> +1 Christian. This can also be used automatically say for fallback behavior as ekr said earlier and not cause UX issues (with the blind click through Vladimir calls out)
  • [18:24:31] < Petr Špaček_web_115> Obviously there is many shades of Transparency. Starting with single-bit information "this answer was tampered with" to reasoning why it was tampered with, possibly what was the original value etc. etc.
  • [18:24:58] < Dan Wing_web_444> filtering is a different topic than split DNS. Another document I co-author, https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-01, is a proposal for revealing filtering details to a DNS client.
  • [18:25:04] < Lixia Zhang_web_816> Christian: transparency (if I understand right) just ask users be made aware of what's going on first
  • [18:25:08] < Vittorio Bertola_web_652> @Christian: First of all, transparency would be about making it clear to you (the end-user) that if your connection fails it is because the domain was blocked and not because of network issues
  • [18:25:15] < Christian Huitema_web_649> I think filtering and split are two different issues. Split is about providing access to resources that are generally not available, filtering is about denying access to resources that are available.
  • [18:25:53] < Andrew Campling_web_480> @Petr: There are proposals (in DPrive I think) that provide potential solutions for greater transparency, not limited to split-DNS
  • [18:25:56] < Petr Špaček_web_115> Sorry Christian to disagree. In my mind split is about giving different answers.
  • [18:26:28] < Éric Vyncke_web_402> transparency would assume that the user is knowledgeable, not always a given
  • [18:26:46] < Erik Nygren_web_938> They may also be distinct in that with split the local network or device policy can pre-enumerate the domains wanting different behavior while with filtering you can't.
  • [18:27:06] < Andrew Campling_web_480> @Eric: It's fair to assume that most users do not know of, let alone understand, DNS
  • [18:27:07] < Robert Evans_web_175> split names and filtering are both shades of the same problem: discovery of local network policy... re filtering clients can react in a privacy enabling way if they refuse to operate or present strong warnings on "monitored" networks for instance
  • [18:27:55] < Tommy Jensen_web_265> Transparency doesn't always have to involve real-time user understanding (imagine a stub previously having config for "never use resolvers that claim they hijack", "always defer to local resolvers for names they claim to hijack", etc.)
  • [18:28:28] < Tommy Jensen_web_265> Such a mechanism could be useful to the stub resolver acting on behalf of previous admin signal (or default platform behavior with no user involvement)
  • [18:28:28] < dkg> i find Ted's attempt to constrain the discussion useful
  • [18:28:29] < Petr Špaček_web_115> +1 Tommy
  • [18:29:32] < Warren Kumari_web_380> @DKG / @Ted: Yah.
  • [18:29:57] < Andrew Campling_web_480> Split Horizon Chairs?
  • [18:29:58] < Warren Kumari_web_380> It also seems like much of this could actually be accomplished (and in some places is) by DNSSEC.
  • [18:30:16] < Éric Vyncke_web_402> Special thanks to all the chairs !
  • [18:30:23] < Éric Vyncke_web_402> And Ben for your slides ;-)
  • [18:30:23] < Tommy Jensen_web_265> See ya at 113, thanks chairs
  • [18:30:26] < Benno Overeinder_web_758> Thanks!
  • [18:30:30] < Warren Kumari_web_380> I've seen tiings signed with 2 keys, one of which is only internal.
  • [18:30:30] < tale > Thank you all
  • [18:30:32] < Warren Kumari_web_380> Thanks all
  • [18:30:38] < Tommy Jensen_web_265> And yes, Ben good heavy topic lifting
  • [18:30:44] < Petr Špaček_web_115> Thank you - and hopefully see you in Vienna or elsewhere - soon!
  • [18:30:46] < Benjamin Schwartz_web_133> Thanks!
  • [18:31:51] < Petr Špaček_web_115> @Ben Thank you for attempting to constrain such a broad topic - it was an useful attempt, albeit not 100% effective.

[end notes]