Subject: Re: [Add] some background on split DNS with DNSSEC

From: "Deen, Glenn" <[email-masked]>
Date: Tue, 9 Nov 2021 21:07:51 +0000

Item #1:

Chair dusting off his fancy chair hat and saying, before this gets too off track  ....
     - gentle nudge to everyone to stay focused on the core ADD related issues here -

Item #2:

ADD may at times be willing to tackle some hard stuff such as how to discover encrypted DNS servers, but ADD is very much not chartered to take on something as impossible as trying to unravel several decades worth of various DNS and naming architecture choices that many of us would very much like to go back and have a second, hopefully wiser attempt at.

That is a topic that needs a stool, a beverage and the in-person ability to sigh, roll eyes, shake our heads mournfully and show the all wisdom we have gained by learning the consequences that come years later from decisions that may have made perfect sense at the time.

Item #3:

That said, what ADD is chartered to do is to look at how to do encrypted DNS resolver discovery in the environments that users do live in, and not just environments that we think they should be in, so with the background on DNSSEC that started this chain, and EKR's moment of actually putting a good word in for DNSSEC during the ADD session,  does the group see there being a role here for DNSSEC?

-glenn

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Nov 2021 18:09:19 -0500 (EST)

> That said, what ADD is chartered to do is to look at how to do encrypted DNS resolver discovery in the environments that users do live in, and not just environments that we think they should be in,…

I think the problem is still that the different use cases are conflicting.

1) Enterprise split DNS

Use provisioning tools to get similar security as RFC 8598 with
authenticated list of domains to take over. This would avoid using public
DNS to "verify" or "authenticate" which would leak private enterprise
domains. I think the current draft's text of somehow (still unclear to
me) have public nameservers claim authority for internal only zones is
the wrong method. Signal some URI over DHCP options and let clients
with provisioning retrieve/verify/use it. Unprovisioned users would
not use the option, lacking a method to validate the list, which also
prevents abuse of this protocol in non-enterprise setups.

2) ISP like provisioning domains and hotspot (redirect) domain logins

This is the hardest one, eg .box for the Fritz!Box router in Germany.  In
this case, it requires accessing .box, but it is completely squatted. You
could only allow this if you confirm the external domain does not exist
Also, germany would go offline as soon as .box gets delegated. We don't
care about leaks here, which is good because one has to query the public
DNS. But as ekr pointed out, browsers already have a workaround
behaviour by trying public DNS and if that fails retry on local
network's DNS. systemd-resolved sends out the query on all interfaces
(and uses the first returned answer, which is in itself a security
nightmware, but I digress). The question is, is this something ADD
should take on or leave out. I think it should leave this out as it
cannot in a reasonable way be authenticated and/or authorized.

3) enduser protection mechanisms

I don't think these would be advertised as domains to resolve but rather
would use mandatory use of DNS servers that would filter these.

I have been at a hotel chain that blocked priceline.com. Coffeeshop
wifi might prevent certain domains to prevent things like Google Meet
or other domains that make people use a lot of bandwidth and stay very
long. Schools might grab facebook to block it. While I think network
owners should be able to dictare terms on their clients, I don't think
the current ADD split-dns is the right mechanism for that.

And then we have the issue of this document of split DNS having a run-in
with censorship, either by nationstate or as a security service. In
those cases, the goal is to take over all DNS for the protection of the
user. When that happens, it overrides the split-dns network configuration.
But of course, enforcing of that is impossible and a race of DoH against
the administrator ensures.

I did see the Zero Knowledge Proof DNS blocklist presentation today, but
I also feel that even if the protocol managed to be speed up to be
usable, the problem is that those who want to deploy blocking as a
security service would want to know which domains were queried (eg to
detect the C&C domain to identify the specific malware running). Those
with the power the censor DNS don't often want to give the user full
privacy - especially when they do things that are not allowed on the
network.

I think the one real use case here is to fix is the enterprise list of domains.
This is the use case where every party agrees to play along.

If I need to access internal.aiven.io when I join the wifi and use my own
TRR nameserver, I need to get these domains into my application. The
current browser method of trying external before trying internal
nameserver fixes that but it is not the best solution for all applications
performing DNS. My laptop's build system would fail with DNS in git or
other build tools.

The browser solution also does not work when the view leads to different
valid result. Eg if vault.aiven.io would be landing page with "nothing to
see here" on the external view, and a real vault on the internal view. The
easy fix is "don't do that" but there might be more complicated scenarios
where this cannot be avoided.

Putting a solution in the stub would be good.  I think ADD can specify something
here, but it would really be part of (and authenticated by) the enterprise
provisioning. Which could be as simple as a URI via DHCP option to a signed
list by a CA that I installed. I am not sure dancing around in different
DNS views would be particularly useful. And it would still allow
outsiders to see those public DNS queries which are supposed to remain
private. And I still don't understand the updates to the document from
this Monday, that adds some packet flaw images, but no DNS query
information. I still don't understand it :(

Paul

---

From: "Deen, Glenn" <[email-masked]>
Date: Wed, 10 Nov 2021 00:48:09 +0000

Top posting as there is a lot here, but I’d like to suggest maybe the path is carve out the ADD task and tackle the other issues elsewhere.

ADD is really about finding what resolvers are available and acquiring info about them.     The rest of the problem space - who's authoritative, leaked domain names, blocking, etc are all outside of the ADD mission.   Find the available resolvers, get info about them.  That's it.

The nuance, and why ADD has a couple of different documents on how you discover is that there are a couple different network environments that this discovery needs to work in. These are driving entirely by what the users live in today.      (1)  DDR covers when you can find resolvers by going to the DNS and looking up SVCB records. (2) DDR covers when you are in a DHCP/RA situation.   (3) CPE forwarders and finally (4) Split DNS is when you are in a split network environment where one side is "private" and the other isn't.

If we focused on the question of the split-dns/split-network case, and don't pull in the various DNS zone, authority, visibility, leakage issues which are IMPORTANT, but outside discovery of which resolvers there are - what is the right way to find DNS resolvers for (A) the private side and (B) for the public side.    Why isn't it as simple as specifying the way you do it on the private and the way you do it on the public and punt to other work the other questions?

-glenn

On 11/9/21, 3:09 PM, "Paul Wouters" <paul.wouters=[email-masked]> wrote:

    1) Enterprise split DNS

    Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Nov 2021 20:18:02 -0500 (EST)

> ADD is really about finding what resolvers are available and acquiring info about them.     The rest of the problem space - who's authoritative, leaked domain names, blocking, etc are all outside o…

If you go that way, then I think you would only need an option for
DHCP/RA to convey a URI about where to get the list of internal domain
names, and let the URI specifics handle the authentication (eg via
HTTPS). But that would be a different draft.

Paul

---

From: tirumal reddy <[email-masked]>
Date: Wed, 10 Nov 2021 19:45:32 +0530

On Wed, 10 Nov 2021 at 04:39, Paul Wouters <paul.wouters=
[email-masked]> wrote:

> > That said, what ADD is chartered to do is to look at how to do encrypted
> DNS resolver discovery in the environments that users do live in, and not
> just environments that we think they should be in, so with the background
> on DNSSEC that started this chain, and EKR's moment of actually putting a
> good word in for DNSSEC during the ADD session,  does the group see there
> being a role here for DNSSEC?
>

The DNS query to resolve "pvd.uk.example.com" is sent to the
network-designated resolver. RFC8801 in section 4.1 mandates that the PvD
FQDN must be resolved using the DNS servers indicated by the associated
PvD.  The NS query for the domain "example.com" in dnsZone is sent to the
public resolver. If the network proves authority over the domain, "
example.com" is resolved using the network-designated resolver.

-Tiru

> Paul
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 10 Nov 2021 19:49:16 +0530

On Wed, 10 Nov 2021 at 06:48, Paul Wouters <[email-masked]> wrote:

> > Top posting as there is a lot here, but I’d like to suggest maybe the
> path is carve out the ADD task and tackle the other issues elsewhere.
> >
> > ADD is really about finding what resolvers are available and acquiring
> info about them.     The rest of the problem space - who's authoritative,
> leaked domain names, blocking, etc are all outside of the ADD mission.
>  Find the available resolvers, get info about them.  That's it.
>

RFC8801 already covers most of the above details. It includes discovering
the PvD FQDN using RA and authenticating the network PvD server using
HTTPS.

-Tiru

---

From: Dan Wing <[email-masked]>
Date: Wed, 10 Nov 2021 09:42:44 -0800

On Nov 9, 2021, at 3:09 PM, Paul Wouters <paul.wouters=[email-masked]> wrote:
...
> the administrator ensures.

The split-dns draft does not enable such blocking, except by the domain owner of priceline.com, facebook.com.  That is, the hotel could not use split-dns to block priceline.com.  That is exactly the attack the query to the public DNS prevents.  During Q&A, I was encouraged to document that attack and how it is mitigated better.  We plan to add that explanation to an updated version.

...
> information. I still don't understand it :(

RFC8801's PvD are doing that (albeit using IPv6 RA rather than DHCP as you suggest).  I am not a fan of the IPv6 requirement for RFC8801's PvDs.  Enterprises continue to avoid deploying IPv6 internally.  

The current split-dns document validates the PvD returned by querying public DNS.  If that validation fails, the dnsZones claim in PvD is considered bogus ("lying") by the split-dns document.

This conversation is giving me another idea which I will explore next week.

-d

---

From: Dan Wing <[email-masked]>
Date: Wed, 10 Nov 2021 09:42:47 -0800

On item 3,

We could use DNSSEC to prove the PvD dnsZones is truthful to avoid asking the same question of the public DNS.  

However, we already need IPv6 (for RFC8801's PvD) and adding a DNSSEC requirement means we are deeper in the "room of non-deployability", a dreaded space for our D&D character.  That's why split-dns queries the public DNS:  the procedure in split-dns establishes a *similar* proof of domain ownership as DNSSEC could have provided.

-d

> On Nov 9, 2021, at 1:07 PM, Deen, Glenn <Glenn_Deen=[email-masked]> wrote:
> 
> Item #1:
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 10 Nov 2021 14:47:49 -0500

On Wed, Nov 10, 2021 at 12:43 PM Dan Wing <[email-masked]> wrote:

> However, we already need IPv6 (for RFC8801's PvD) and adding a DNSSEC
> requirement means we are deeper in the "room of non-deployability", a
> dreaded space for our D&D character.  That's why split-dns queries the
> public DNS:  the procedure in split-dns establishes a *similar* proof of
> domain ownership as DNSSEC could have provided.
>

I think the right approach for this draft is to say that the client should
acquire independent confirmation of the delegation's validity before
proceeding, and not get too specific about how it should do that.  Valid
client behaviors should include:
* Send the NS query through the network's resolver and require a valid
DNSSEC signature chain**.
* Send the NS query through a trusted third-party resolver over a secure
channel.
* Same as above but requiring AD=1 in the response.
* Perform full iterative resolution for this NS query, requiring DNSSEC.
* etc.

If a network signs their domains, any participating clients will accept the
delegation.  Otherwise, some compliant clients might ignore the instruction
because it fails their validity check.  That seems fine to me.  Many
clients won't implement this at all, so operators already can't rely on it
unless they have knowledge of a specific client's behavior.

**This is harder than it sounds due to chain-walking, loose consistency,
etc.

---

From: tirumal reddy <[email-masked]>
Date: Thu, 11 Nov 2021 11:31:08 +0530

> * Send the NS query through a trusted third-party resolver over a secure

Yes, first try DNSSEC and if it fails, fallback to a third-party resolver
for the dnsZones domains. It allows the network admin to either deploy
DNSSEC for split-horizon domains or use the existing mechanism proposed in
the draft depending on the operational feasibility. It will also work for
clients not validating DNSSEC. We will update the draft.

> * Perform full iterative resolution for this NS query, requiring DNSSEC.

Please clarify the need for the above two mechanisms.

-Tiru

> * etc.
>
> If a network signs their domains, any participating clients will accept
> the delegation.  Otherwise, some compliant clients might ignore the
> instruction because it fails their validity check.  That seems fine to me.
> Many clients won't implement this at all, so operators already can't rely
> on it unless they have knowledge of a specific client's behavior.
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 11 Nov 2021 11:12:59 +0000

> * Perform full iterative resolution for this NS query, requiring DNSSEC.
This seems like it both provides too many options and like it is too easy
for someone to misunderstand or deliberately misconstrue what independent
validation counts.  I would prefer picking one or two that are fully
described in the eventual draft, with what amounts to
mandatory-to-implement language (e.g. one for v6-available and one for
v6-unavailable situations).

Obviously, we might not be able to get to that level of common practice,
but I think it will be easier for everyone if we can get close; otherwise
there will be a lot of code paths and a real risk that nothing at all gets
wide deployment.

Just my two cents,

Ted

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 11 Nov 2021 07:08:55 -0500

On Thu, Nov 11, 2021 at 1:01 AM tirumal reddy <[email-masked]> wrote:

>>> We could use DNSSEC to prove the PvD dnsZones is truthful to avoid
>>> asking the same question of the public DNS.
>>>
>> I think the right approach for this draft is to say that the client
>> should acquire independent confirmation of the delegation's validity before

The group is not chartered to specify client or network operator resolver
selection policy, so I don't think it is a good idea to try to specify this
in the draft.  In my view, the important thing is to provide the mechanism
(normative) and inform each party of the relevant security considerations.

> Please clarify the need for the above two mechanisms.

The first is effectively "delegated DNSSEC validation".  This is useful for
a client whose threat model includes network attackers on the public
internet, if it doesn't want to implement full DNSSEC validation locally.

The second is a valid client behavior.  It will work, and under our charter
we can't rule it out.  It also might work better in practice than
DNSSEC-via-network-resolver because stub-side DNSSEC validation is
nontrivial due to the need for chain walking.

---

From: tirumal reddy <[email-masked]>
Date: Fri, 12 Nov 2021 13:08:05 +0530

> (normative) and inform each party of the relevant security considerations.

Works for me.

> The first is effectively "delegated DNSSEC validation".  This is useful
> for a client whose threat model includes network attackers on the public

Okay.

>
> The second is a valid client behavior.  It will work, and under our
> charter we can't rule it out.  It also might work better in practice than

I don't get how iterative resolution is better for the stub resolver than
the typical recursive mode.

-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 12 Nov 2021 10:38:39 -0500

...

> the typical recursive mode.

There have occasionally been suggestions in this working group that clients
might want to run full resolvers locally for privacy reasons.  However, I
was specifically referring to the problem of resolving full DNSSEC chains
as a stub.  Resolvers do not ordinarily provide the full chain to the stub
(absent RFC 7901), so validation requires the stub to walk "up" the chain,
querying for DNSKEY and DS records.  This is not easy to do correctly and
is not available in most stub resolver implementations.  It may be simpler
for the client to walk "down" the chain using a standard iterative resolver
implementation.

---

From: tirumal reddy <[email-masked]>
Date: Sat, 13 Nov 2021 17:54:40 +0530

On Fri, 12 Nov 2021 at 21:08, Ben Schwartz <[email-masked]> wrote:

> There have occasionally been suggestions in this working group that
> clients might want to run full resolvers locally for privacy reasons.
> However, I was specifically referring to the problem of resolving full
> DNSSEC chains as a stub.  Resolvers do not ordinarily provide the full
> chain to the stub (absent RFC 7901), so validation requires the stub to
> walk "up" the chain, querying for DNSKEY and DS records.  This is not easy
> to do correctly and is not available in most stub resolver
> implementations.  It may be simpler for the client to walk "down" the chain
> using a standard iterative resolver implementation.
>

Got it, Thanks for the clarification.

-Tiru