Skip to main content

Minutes IETF113: add

Meeting Minutes Adaptive DNS Discovery (add) WG
Date and time 2022-03-24 13:30
Title Minutes IETF113: add
State Active
Other versions markdown
Last updated 2022-03-24



Agenda ADD@IETF113

Meeting Materials, Links

Materials, Charter, Documents

Materials, Charter, Documents

  • ADD Chairs: David Lawrence, Glenn Deen
  • Area Director: Eric Vyncke
  • In Room Coordinator: Benno Overeinder

Interim Session times

  • Time: Thursday March 23 2022, 15:15-16:30 Vienna/ 14:15-15:30 UTC

  • Note the time change from the IETF schedule:
    DPRIVE will share this slot and run from 13:30-14:15 UTC, with ADD starting at 14:15 UTC


1 Administration

  • Scribe selection
  • Agenda bash
  • Welcome from chairs
  • Results of WGLCs

3 Drafts in WGLC:

Discovery of Designated Resolvers (DDR)

  • 2 items - minor editorial - have been submitted in Github and will be incorporated. This new version is ready to hand off to the document shepard and pass WGLC.

DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

  • needs some engagement with 6MAN to clarify, other comments on list have been largely resolved.
  • not yet ready to pass WGLC but very close to ready

Service Binding Mapping for DNS Servers

  • ready & has passed WGLC

2 Drafts

2.1 Split-Horizon DNS Configuration 15 min (Tiru)

Dan Wing presenting. Ben Schwartz joined as a co-editor. -07 to -09 removed NSEC allowance, etc. (see slide 2).

Discussions (Slide 3 - 4): Does not allow filtering.

Authors are looking for adoption as an WG item.

Ben Schwartz: Suggests changing title to "Validating local claims of authority", draft presents different technologies to validate these claims. There is even an ancient DHCP option to locally claim authority over domains

Martin Hunek: 1) nameservers having to match between step 1 and step 2 - what happens if that fails 2) process is quite complex. would it be possible by doing a record placed into the zone?

A: Yes, would be possible - we are asking for other security mechanism that we can use. Send text. Figure shows only the last step that we're adding to the existing mechanism.

Eric Rescorla: ... vs - internal vs external..?

A: When trying to resolve the non-public one, you get a NXDOMAIN.

Ben Schwarz: Clarifying - existance of itself is not a secret.

Eric: Agrees that this is not a problem. Second question: internal resolver identified by domain name, or purely by ip address?

A: By name

Tommy Pauly: ..

A: Example on slide 5

Eric: ..

2.2 Network policy to use Network-designated DNS Resolvers 10 min (Tiru) + Discussion time

Tiru Reddy presents. Problem: Inform client that network-signaled resolvers have to be used (eg. when use of other resolves would block client completely)

Uses RFC8801 as mechanism, eg "NetworksDNSOnly": True.

This is a security polcy expression, but not a prescription to the client. Can be ignored, explicitely recommend only for trusted networks.

Comments / suggestion: Is this the right WG for this?

Tommy Pauly: Seems odd for provisioning domain to tell "don't use other resolver" (audio breaking up). other PvD could include own DNS, so it gets complicated. Better "upfront claim" of intentional consequences of use of using other DNSes.

Ben Schwartz: (see mailing list post) - doesn't like the general direction. Trying to fix a non-fixable problem, and is in a space where we shouldn't be.

Martin Hunek: any other resolver should be opt-in, not opt-out. user should be the one to assess other dns to use, not the network. should have a recommendation about usage of 3rd party resolvers in a document. Opt-in first!

Tiru: Have observed the behaviour of clients joining enterprise networks, and network then blokcing them. Understand the downgrading problem that this option allows for. User agreement? Empower the user! Idea is to give a hint to the user what is happening.

Lorenzo Colitti: Confused what effect that this has. Clients have a reason for using other DNSes. Hint will not help in any of these cases. Option only tells the user it will not comply with their security requirements. Option would not be an improvement in security. Doesn't think the hint is useful.

2.3 DNS Resolver Information 10 min (Tiru) + Discussion time

Tiru presenting. Refers to charter item about "information to clients in selection mechanism". Have already two mechanism for discovery, but not how to select (information about the resolver).

RESINFO filling the void, allows for discovery of "meta-information" about a resolver.

Ben Schwartz: Should probably adopt this, replacement for CHAOS TXT version.bind etc. resolver info records - better than squatting on names. Some mechanism like that is required, and that's a good starting point

Daniel Gillmor: Cen see Bens points to "adopt something", but information about a machine in other contexts has caused concerns -> security concerns. Concerned about bindings between URLs and the service - could point to another URL.

Eric: same point as dkg. "oh, it's " pointed by whatever nameserver.

Puneet Sood: seperate information in two parts - "protocol" vs "policy" parts. maybe even two seperate endpoints. For protocol, extend EDNS0?

2.4 Discovery of Designated Resolvers in the Presence of Legacy Forwarders 10 min (Ben) + Discussion time

Situation: Client -> forwarder -> recursive (DoT enabled) - can client switch over to recursive?
DDR default upgrade rule prevents accessing it because of seperate IP addresses

Describes "relaxed validation policy", and describes some problems and mitigations of these.

Note: DDR draft was adjsted to allow for this relaxed policy.

Glenn Deen: Ready to issue WG adoption call, but want to hear from WG first.

Tiru: Supports adopting. Concerns to some of the deployment models - "legacy routers" with non-upgradable FW, for example.

Ben: Upgradability: might be possible to change config, but not eg. add TLS. NXDOMAIN DDR response would not help. User-interactive mitigation: Draft is informational, if some mitigations are impractical we can remove them, but tryint to be descriptive. Attack described: Any attacker could prevent DDR altogether in the first place.

Martin Hunek: v6, where there are no private IP addresses?

Ben: draft considers private IP addresses, common in IPv4, IPv6 could still use link-local IP addresses. this logically applies separately to IPv4 and IPv6.

Martin Hunek: DDR itself: Why rather than _something.pvd ? path components? Ports?

Ben: path components issue - DoH is already widely deployed, so there are specified paths in those. Hence wanted to specify those in the DDR context. Port number: optional for clients, useful when running many different servers (eg. servers with different behaviours)

Tommy Pauly: Appreciate it's not normative. Section 3 (relaxed validation) maybe be more descriptive, stronger recommendation to think about mitigations!

Ben: Normative language in informational docs?

Erik Nygren: unresolved point

Ben: Can pick up Tommy's suggestion

Erik: Worth looking at the IPv6 point a bit more here.

Ben: "Validated the locality" of a public IP address - being "so close" to the address. hop count, ttl2 and ping.. nothing deployable, though. router address might not even be in the same "collision domain"..

3 AOB / Discussion (all)

4 Planning & Wrap up

  • 5 min - Wrap up

Glenn - Reflecting: All of these last 2 years were done online, ADD has made great progress and has docs at or near WGLC, well done everybody! Thanks for the time people put into writing, commenting and contributing to add.

See you in Philly in july!

ADD notes taken by Alexander Mayrhofer

-- End of ADD Agenda --

Jabber notes (chatter edited out)

Meetecho 7:27 From settings / manage slides, though, you can also upload PDF files manually

Chris Box_web_843 7:30 Thanks Vicky. And I like "Verified Split Horizon" as a title.

Chris Box_web_843 7:33 Ben's title also works, and has the benefit of being more precise, but I wonder whether keeping "split horizon" in the title will help people find it?

Vicky Risk_web_427 7:37 +1 'split' or 'split horizon' is helpful in the name

Andrew Campling_web_263 7:39 +1 on keeping a reference to split in the title

Éric Vyncke_web_499 7:41 ++

Benjamin Schwartz_web_995 7:41 ekr: The internal one can probably just act as a recursive resolver for all the public names

David Lawrence_web_612 7:42 split-horizon probably helps best for SEO-type issues, as Chris suggested

dkg 7:47 are there any other PvD attributes that claim some sort of exclusive access?

Tommy Pauly_web_893 7:48 No, there aren't any existing ones

dkg 7:48 that makes it very odd semantically

Eric Orth_web_401 7:49 +1 to Tommy's point. I think most non-network-managed clients are going to ignore any similar flags unless they run into adversarial interference so good to make things more explicitly around that.

Tommy Jensen_web_231 7:50 +1 as well, describing network behavior seems to be more productive than prescribing client behavior and in line with previous discussions near this point.

dkg 7:50 +1 as well

Christian Huitema_web_141 7:50 +1
7:51 Basic problem is the network does control the Wi-Fi network, does not control cellular connection. The device in theory could always run DNS over cellular, and unless the devic eis fully controlled there is no way to block that.

dkg 7:52 and you cannot know that, as the network operator
7:53 it's pretty hard to not characterize this as "when i block the user from using the network as they choose, they get confused and frustrated"

Christian Huitema_web_141 7:53 :-)
7:54 Should we have an IETF position on not endorsing perimeter based security?

dkg 7:54 "the user is willing to agree" is a tough interpretaton of the usual UI/UX modal interruption
7:55 most users see such an interruption as "to get your work done, blah blah blah [OK] [cancel]"

Peter Hessler_web_711 7:55 aka, the ssl warning click-through

dkg 7:56 among many others

Tommy Jensen_web_231 7:56 @christian: that would be lovely

Christian Huitema_web_141 7:56 Perimeter security belongs to the old "inadequate but marketable" legacy...

Andrew Campling_web_263 7:58 @Christian I image malware developers would welcome such a move, ditto surveillance capitalists and others

Christian Huitema_web_141 7:59 @andrew look at zero trust for the actual security response. Or at various ransomware attacks for the inadequacy of perimeter security.

Chris Box_web_843 8:01 In the spirit of bind.version, perhaps we should add to RESINFO response a list of CVEs to which this resolver is currently vulnerable. :-)

Andrew Campling_web_263 8:01 @Christian: not suggesting using it in isolation

Brett Carr_web_252 8:02 I've not read this draft (disclosure), but instead of a new record could we use HINFO (Shows my age)

Tommy Jensen_web_231 8:03 @chris if it claims vulnerability to a CVE that it was already patched for, is that legally misleading the user?

Chris Box_web_843 8:04 Sounds like a honeypot

Tommy Pauly_web_893 8:04 I don't see us using this info in the UI

Tommy Jensen_web_231 8:04 Neither does the other Tommy

dkg 8:05 the binding ekr is talking about needs to go in the opposite direction

Benjamin Schwartz_web_995 8:05 I really think about this as just for debugging. That might point toward it being less machine-readable.

Eric Orth_web_401 8:05 I can't think of any use for this directly in Chrome. All I can come up with is that it might be useful for manually debugging/querying.

Jim Reid_web_261 8:05 @ Brett, is HINFO still a thing?

Brett Carr_web_252 8:05 efforts to increase ease of dns debugging are very much a good idea :)

dkg 8:06 +1 for debugging info 8:06 @dkg: yeah, what I'm saying is that I join the network, it says "go over here to find my policies". What we would need is if the client shows that information it needs to validate that the person asserting the policies asserts that this server is its own

Tommy Jensen_web_231 8:07 +1 to ekr, now there's a whole new chain of trust to build.

dkg 8:07 and another round trip, probably

Brett Carr_web_252 8:07 @Jim still exists as a record type AFAIK but is never used hence my suggestion of re-using ut instead of inventing a new one

dkg 8:08 Brett Carr: does "never used" mean never published or never queried?

Éric Vyncke_web_499 8:10 I should read the I-D but is it relevant for IPv6 only network ?

Eric Orth_web_401 8:11 I have expressed support for adoption of this before, and I still support it. I don't have much else to say.

Jim Reid_web_261 8:11 The RESINFO's JSON goop will likely be much richer than anything HINFO can do.

Erik Nygren_web_244 8:14 @Éric: I worry that DDR is a big problem for IPv6-only networks with forwarders. I think we may need a solution there. For example, if we adopt this draft should it also apply to resolvers on the same (/64?) as the client.

Éric Vyncke_web_499 8:14 @Erik good Q indeed

Peter Hessler_web_711 8:16 @Erik anecdotal data, but my ISP gives me an IPv6 resolver that happens to have the same IP address as the gateway; so that would be helpful in this case

Erik Nygren_web_244 8:19 @Peter: is that a global address?

Peter Hessler_web_711 8:19 yes it is
8:19 sorry, meant to say that

Nicolai Leymann_web_434 8:19 We use a link local IPv6 Address for address resolution in the local network for residential customers.

Erik Nygren_web_244 8:20 Nicolai: how does that work interface scope-wise?

Peter Hessler_web_711 8:22 the client knows what interface they received the slaac or dhcpv6 announcement on, so they can use that when configuring dns information. or, if it was added manually, then the host admin will need to add that by hand.

Erik Nygren_web_244 8:24 permissions issues, I think

Kevin Fleming_web_122 8:27 probably shouldn't use the word 'public' here, but 'global scope' instead?

Tommy Jensen_web_231 8:27 +1 to what Ben exactly just said: "closeness" is not a metric I want to rely on
8:28 @glenn I'd wear that, presuming I ever get to attend in person to show it off to anyone but my dog :(

Peter Hessler_web_711 8:28 scope is trivial for clients. they have to know the interface they learned it from

Kevin Fleming_web_122 8:28 weirdos like me use global-scope IPv6 addresses as anycast to reach in-network resolvers, so link-local-scope would not work there

-- jabber end ---