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

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Nov 2021 09:31:09 -0800

A past draft was written about how to handle split DNS within DNSSEC.

https://datatracker.ietf.org/doc/html/draft-krishnaswamy-dnsop-dnssec-split-view

This may be useful information for the
draft-reddy-add-enterprise-split-dns draft

Also of interest is what problems exist with doing private name spaces
and how hard this problem is and why DNSOP has never managed to publish
something about it:

https://www.rfc-editor.org/rfc/rfc8244.html

And if you back search DNSOP mailing list, this has a huge history
behind it.
-- 
Wes Hardaker

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Nov 2021 08:45:25 -0500

> draft-reddy-add-enterprise-split-dns draft

Yes, I agree that it's useful.
I continue to suggest that split-view is silly (and I sold devices that
promoted this in the mid-1990s)

A private delegation of "internal.example.com" works much better,
particularly in the modern world of IPv6, VPNs, and Remote Access.

    > And if you back search DNSOP mailing list, this has a huge history

yup.
I wrote:
https://datatracker.ietf.org/doc/draft-richardson-homenet-secret-gardens/ a
long time ago, but never pursued it because Provider Domains was too far
along.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Nov 2021 09:29:03 -0500

> particularly in the modern world of IPv6, VPNs, and Remote Access.

What is a private delegation?

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Nov 2021 09:32:44 -0500

On Nov 9, 2021, at 09:29, Ben Schwartz <bemasc=[email-masked]> wrote:

> On Tue, Nov 9, 2021 at 8:45 AM Michael Richardson <[email-masked]> wrote:
> 

I am not Michael Richardson, but I think what is intended is a delegation within a restricted ("private") namespace, such as might be exposed through internal resolver infrastructure that serves a specific set of stub resolvers.

But I agree that it's not a very clear term.

Joe

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 09 Nov 2021 06:47:28 -0800

> On Nov 9, 2021, at 5:45 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

Having a specific zone / subdomain that’s used for non-public hosts is certainly a clean way to handle split-DNS cases. This allows for simple techniques like failing back to some internal resolver when you don’t have an a priori mapping of which names should use the internal resolver, and it makes cases where you have a trusted list of internal domains (like VPN) very simple.

Sadly the reality of so many deployments is that there isn’t a clean cut for “internal” or “private” names. Maybe we can hope that deployments that use dual-facing or dual-resolving hosts will eventually stop, but I don’t see that happening any time soon.

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

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 9 Nov 2021 15:58:46 +0100

> On Nov 9, 2021, at 3:47 PM, Tommy Pauly <tpauly=[email-masked]> wrote:

Heh, Tommy just saved me a bunch of typing.  :-)

My observation is exactly the same.  The problem isn’t so much that new organizations will decide split-horizon is a good idea, as that old organizations have grown very large while doing it, and have decades of momentum.

                                -Bill

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Nov 2021 16:09:35 +0100

Or... maybe it's time for a new trust model with regard to name 
ownership, to account for reality on the ground.  This might also permit 
us to admit that DNSSEC itself has serious deployment problems.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2021 10:15:32 -0500

It might indeed be nice to consider a way to make DNSSEC work that
acknowledges the existence of a shared public/private namespace. But it
would have to be easier to operate than just operating two namespaces that
both validate from the same delegation, which is what we can do today.

On Tue, Nov 9, 2021 at 10:10 AM Eliot Lear <[email-masked]> wrote:

> > Having a specific zone / subdomain that’s used for non-public hosts is
> certainly a clean way to handle split-DNS cases. This allows for simple
> techniques like failing back to some internal resolver when you don’t have
> an a priori mapping of which names should use the internal resolver, and it
> makes cases where you have a trusted list of internal domains (like VPN)
> very simple.
> >
> > Sadly the reality of so many deployments is that there isn’t a clean cut
> for “internal” or “private” names. Maybe we can hope that deployments that
> use dual-facing or dual-resolving hosts will eventually stop, but I don’t
> see that happening any time soon.
> >

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 9 Nov 2021 16:18:30 +0100

> On Nov 9, 2021, at 4:15 PM, Ted Lemon <[email-masked]> wrote:
> 
> It might indeed be nice to consider a way to make DNSSEC work that acknowledges the existence of a shared public/private namespace. But it would have to be easier to operate than just operating two namespaces that both validate from the same delegation, which is what we can do today.

Can you elaborate?

If people are already maintaining two “views” of a namespace, and signing both with the same keys, how would it get easier?  I mean, short of not maintaining two views?

                                -Bill

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Nov 2021 16:20:09 +0100

> If people are already maintaining two “views” of a namespace, and signing both with the same keys, how would it get easier?  I mean, short of not maintaining two views?

More often than not, they're not operating DNSSEC at all because of the 
complexity of the above.

Eliot

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 9 Nov 2021 16:23:28 +0100

> On Nov 9, 2021, at 4:20 PM, Eliot Lear <[email-masked]> wrote:
> 
> 
> More often than not, they're not operating DNSSEC at all because of the complexity of the above.

I don’t see how the two are connected, though…

If you’re operating a split view, there’s a degree of complexity involved in managing the separation after the split (or, more likely, you just have two different sources of authority, but it comes to the same thing).  If you’re DNSSEC signing, you’ve got a process for that, and you’re running zones through it.  Both are complex processes, but neither makes the other more complex than it would have been otherwise, that I can see...

                                -Bill

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 10 Nov 2021 02:25:12 +1100

On Wed, Nov 10, 2021, at 01:58, Bill Woodcock wrote:
> My observation is exactly the same.  The problem isn’t so much that new 
> organizations will decide split-horizon is a good idea, as that old 
> organizations have grown very large while doing it, and have decades of 
> momentum.

My concern is not whether split DNS exists (it does) and whether it will continue to exist (it will), but what the security goals of our work in that area might be and how those might be achieved.

We know that under some conditions (to be determined), some clients (to be determined) might wish to use a particular DNS resolver (varying) for some - but not all - names.

We have already determined that this is not something that is exclusive to Enterprise, as much as the practice is widespread in that sort of setting.  We might also want to consider whether the goal is to use a network-provided resolver as opposed to a VPN-associated resolver or a company-policy mandated resolver.  The split-dns draft proposes that we address the network-provided case, but it proceeds on the basis that the policy that causes this proposal to be used is limited in terms of what is configured and then also very specific about the security posture the client adopts as a result of that.

The whole thing with checking a public resolver is all in aid of something about ensuring that the network resolver is authoritative in some way for the names that the PvD claims should point to it.  But this all assumes greater and greater trust in the PvD and - by extension - the network.  And I'm not even sure that it is operationally feasible.

If this were a company-mandated policy, why could that policy take the form of a resolver identity and a list of names for which that resolver is used over all others?  For simplicity, this could be just be a URL for a policy if updating is important or the number of things to configure is unwieldy.

The advantages of that approach are many. For example, when some software pings the internal host accidentally, that name doesn't leak if the host happens to be somewhere other than the office.

If this were a VPN, the same could be used.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Nov 2021 16:29:06 +0100

> If you’re operating a split view, there’s a degree of complexity involved in managing the separation after the split (or, more likely, you just have two different sources of authority, but it comes…

But Bill, you have to decide in your mind if that complexity is additive 
or worse.  My own experience is worse because the tools integration is 
SOMETIMES lacking.  We can say that this is a point of differentiation 
for vendors, but I think any time we say that what we've just said is 
that it's a hard problem.

Eliot

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 9 Nov 2021 16:39:03 +0100

> On Nov 9, 2021, at 4:29 PM, Eliot Lear <[email-masked]> wrote:
> But Bill, you have to decide in your mind if that complexity is additive or worse.  My own experience is worse because the tools integration is SOMETIMES lacking.  We can say that this is a point of differentiation for vendors, but I think any time we say that what we've just said is that it's a hard problem.

The split-view problem is in the doctor-it-hurts-when-I-do-this category.  The DNSSEC problem is in the “damn, I sure wish this were all a little simpler and more obvious/self-explanatory and the tools were a little better” category.  I don’t (intentionally, anyway) do the former.  I cope with the latter.  So I can’t personally say that it’s worse than additive, but my intuition said just additive.  Which isn’t a strong argument, obviously.

I think there’s a very good argument in favor of better tools and better education around DNSSEC.  I think the train has pretty well left the station in terms of redesigning it to be simpler.  But, anyway, I think there’s definitely room for improvement with DNSSEC.

I think split-horizon is conceptually simple, but just creates an inherently fragile situation, in which it’s easy to have unintended consequences.

While I’d like DNSSEC to be ubiquitous, and I recognize that split-horizon isn’t going away any time soon, I’m not sure that it’s worth putting effort into making that particular combination easier, when effort could be applied to making DNSSEC easier, and it would benefit both the people who are doing split horizon, and everyone else.

                                -Bill

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Nov 2021 15:49:03 +0000

> On 9 Nov 2021, at 15:39, Bill Woodcock <[email-masked]> wrote:
> 

I sort of agree Bill. IMO this is not an either/or choice: both DNSSEC and split DNS could or should be made easier. Both not going to go away any time soon. And both are icky to deploy and operate.

Perhaps this thread needs to move somewhere else since it seems off-topic for this WG.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Nov 2021 16:50:32 +0100

I don't disagree with your description when you say:

> I think split-horizon is conceptually simple, but just creates an inherently fragile situation, in which it’s easy to have unintended consequences.

The very same is true with DNSSEC, especially at large institutions that 
do SLB, services in the cloud, shared (forwarded) services, etc.  It 
just gets fragile.  And we keep thinking the tools are going to help; 
but it's 2021, and the tools have had time to mature.  And so to me this 
ALSO devolves to "Doctor, it hurts..."

But it requires some amount of imagination to sort this.

Eliot

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 9 Nov 2021 17:13:24 +0100

> On Nov 9, 2021, at 4:50 PM, Eliot Lear <[email-masked]> wrote:
> The very same is true with DNSSEC, especially at large institutions that do SLB, services in the cloud, shared (forwarded) services, etc.  It just gets fragile.  And we keep thinking the tools are going to help; but it's 2021, and the tools have had time to mature.  And so to me this ALSO devolves to "Doctor, it hurts..."

If what you’re saying is that when we depend upon tools to cover fragile or overly-complicated things with abstraction layers to “solve the problem” that we’re actually adding complexity and fragility, and that that’s a bad idea (“when you’re in a hole, stop digging”), then yes, I agree with that as well.

The biggest problem I see with standards development now is the desire to solve many problems within single monolithic protocols, rather than making small, simple, easily-comprehended modular building blocks that can be put together in different ways to solve different problems.

                                -Bill

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Nov 2021 17:27:24 +0100

Bill:

> The biggest problem I see with standards development now is the desire to solve many problems within single monolithic protocols, rather than making small, simple, easily-comprehended modular build…

While I don't disagree with what you say, what I'm saying is that DNSSEC 
has had PLENTY of time to diffuse and hasn't done so.  In fact, I would 
argue that new new impediments have shown up that lend themselves to 
centralization, which is the risk of amplification attacks that have led 
secondary services to charge extra.

And my admittedly snide initial comment was meant to convey that we 
ought to think of taking another look at naming and security that 
accommodates mechanisms like split views, rather than simply says, 
“Those are bad!”

Eliot

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Nov 2021 11:30:01 -0500

> We have already determined that this is not something that is exclusive to Enterprise, as much as the practice is widespread in that sort of setting.

Right.

>  We might also want to consider whether the goal is to use a network-provided resolver as opposed to a VPN-associated resolver or a company-policy mandated resolver.

The problem of a network provided solution that is not an enterprise / provisioned deployment is that the user and the network have a trust issue to solve. ADD attempts to do that but I haven’t found a solution that seems to work.

> The split-dns draft proposes that we address the network-provided case, but it proceeds on the basis that the policy that causes this proposal to be used is limited in terms of what is configured and then also very specific about the security posture the client adopts as a result of that.

Yes it can really only cover the enterprise case or it ends up as network coercing the user with no way for the user to opt out and the term user is even confusing as we have system resolvers and application resolvers.

> The whole thing with checking a public resolver is all in aid of something about ensuring that the network resolver is authoritative in some way for the names that the PvD claims should point to it…

I agree.

> If this were a company-mandated policy, why could that policy take the form of a resolver identity and a list of names for which that resolver is used over all others?  For simplicity, this could b…

Yes, provisioning is not an issue. The ADD information could point to something and even a device like a phone could mark the enterprise apps to enforce the resolver information where the non-enterprise apps could to whatever the user wants. But this does not address the “protect the user from bad DNS” use cases.

Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Nov 2021 15:28:45 -0500

Warning! More non-actionable philosophy follows.

https://hitchhikers.fandom.com/wiki/Joo_Janta_200_Super-Chromatic_Peril_Sensitive_Sunglasses

On 9 Nov 2021, at 11:27, Eliot Lear <[email-masked]> wrote:

> While I don't disagree with what you say, what I'm saying is that DNSSEC has had PLENTY of time to diffuse and hasn't done so.  In fact, I would argue that new new impediments have shown up that lend themselves to centralization, which is the risk of amplification attacks that have led secondary services to charge extra.

I don't think DNSSEC is a particularly good example of the more general problem it seems like you're both describing.

DNS is an extraordinarily resilient protocol, by which I mean it is unusually good at hiding things that are broken in ways that end users often don't realise. It seems sometimes like 80% of the DNS could be broken in some way and nobody would notice.

The requirements that DNSSEC intends to solve aren't compatible with that degree of brokenness; the simple facts that signatures have finite validity periods and there's metadata in the form of private keys that exist outside the published data of the DNS make the system more fragile and mean that operational failures that were once invisible now have consequences.

The need for validity periods turns the DNS into a ticking time bomb. The need for private keys means that operational hygiene is more operationally vital than it once was. Neither of these things are the fault of DNSSEC, but rather the fault of the requirements that DNSSEC was intended to implement, combined with the tolerance of the original protocol that allowed bad habits to persist.

The existence or non-existence of a satisfactory toolchain is orthogonal to what I would call a more fundamental problem, a problem that likely doesn't have much of a solution unless we forget about validation. Or perhaps it's not a problem, and rather a useful trigger for errors to be cleaned up, in which case yay DNSSEC!

> And my admittedly snide initial comment was meant to convey that we ought to think of taking another look at naming and security that accommodates mechanisms like split views, rather than simply says, “Those are bad!”

I agree.

Seth Breidbart's famous definition of "The Internet" was concerned with the lie that there is a single Internet from all vantage points. The idea that there is a single namespace, or even the idea that there's a single public namespace conjoined for particular clients with a single private one, is similarly problematic.

The namespace, responses to particular queries and reachability of particular nameservers all vary according to where and how queries are initiated. With transports that provide the potential for authentication, we can add "who" to that list. There are many, many, many namespaces and the problem of recognising and accommodating that simple truism is, I think, broader than a superficial treatment of enterprise "split views" and not something that can be simply stuffed back in the lamp.

Joe

---

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

> draft-reddy-add-enterprise-split-dns draft

Yes, it has useful information and is referred in
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-07#section-7
for deploying DNSSEC operationally with split-horizon domains.

-Tiru

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 10 Nov 2021 10:08:54 -0800

Joe Abley <[email-masked]> writes:

> I am not Michael Richardson, but I think what is intended is a delegation within a
> restricted ("private") namespace, such as might be exposed through internal resolver
> infrastructure that serves a specific set of stub resolvers.

I think it's more likely you delegate internal.example.com to
authoritative servers that are only reachable internally within a
restricted IP space (1918 space or simply addresses that only accept
requests from your internal space).
-- 
Wes Hardaker                                     
My Pictures:       http://photos.capturedonearth.com/

---

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

On Tue, Nov 9, 2021 at 10:26 AM Martin Thomson <[email-masked]> wrote:
...

> The whole thing with checking a public resolver is all in aid of something
> about ensuring that the network resolver is authoritative in some way for
> the names that the PvD claims should point to it.  But this all assumes
> greater and greater trust in the PvD and - by extension - the network.

I don't understand.  The whole point of this is that it _reduces_ trust in
the PvD, by declaring that the client ignores the PvD's instructions unless
it can prove that this is what the owner of the affected domain actually
wants.

If this were a company-mandated policy, why could that policy take the form
> of a resolver identity and a list of names for which that resolver is used
> over all others?

In a company-mandated setting, this is all moot.  The company owns the
device and can configure it precisely how they want, which is probably to
use their own resolver for everything.  I haven't seen demand for complex
client behavior expressions in that context.

I have a lot of issues with the flavortext in this draft, but the core idea
seems potentially valuable.  I would call it "secure resolution hints", a
secure way to prefill DNS resolver caches with nearby authoritative servers
for selected domains.

---

From: Joe Abley <[email-masked]>
Date: Wed, 10 Nov 2021 14:16:27 -0500

> requests from your internal space).

I think those are examples of how someone could achieve what I was trying to describe.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Nov 2021 15:05:14 -0500

https://datatracker.ietf.org/doc/html/draft-krishnaswamy-dnsop-dnssec-split-view
uses it two or three times.
I used that term because it was part of the draft.
It wasn't a term I knew before.
It doesn't explain the term (that I saw), so I figured it was simply unknown
to me.

I have chosen to think that it's a situation where there is an NS record
for a subdomain which does not answer queries from the world.  That could be
a matter of policy (ACLs), or because the query point is not globally
routable (RFC1918, ULAs, ...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Nov 2021 15:08:13 -0500

Tommy Pauly <[email-masked]> wrote:
    > techniques like failing back to some internal resolver when you don’t
    > have an a priori mapping of which names should use the internal
    > resolver, and it makes cases where you have a trusted list of internal
    > domains (like VPN) very simple.

If the VPN has to be up to reach that internal resolver, then the act of
looking for the name brings up the VPN.  This is a major win over the case
where the VPN is down, and the user types in some internal name and is told
it does not exist.

    > Sadly the reality of so many deployments is that there isn’t a clean
    > cut for “internal” or “private” names. Maybe we can hope that
    > deployments that use dual-facing or dual-resolving hosts will
    > eventually stop, but I don’t see that happening any time soon.

CNAME can pave over may failures where a previously public (or privately
private) service can be moved.   This isn't possible if there are two views
of the same example.com.

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 10 Nov 2021 21:12:57 +0100

> On Nov 10, 2021, at 9:05 PM, Michael Richardson <[email-masked]> wrote:
> https://datatracker.ietf.org/doc/html/draft-krishnaswamy-dnsop-dnssec-split-view uses it two or three times.
> It doesn't explain the term (that I saw), so I figured it was simply unknown to me.

I’m pretty sure it’s not a thing.

Historically, the term “split horizon” has been used to describe a situation in which different parties see different views.  In the context of DNS, those views have typically been “internal” and “external."

https://en.wikipedia.org/wiki/Split-horizon_DNS

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 10 Nov 2021 23:01:00 +0100

> On Nov 9, 2021, at 5:30 PM, Paul Wouters <[email-masked]> wrote:
> The problem of a network provided solution that is not an enterprise / provisioned deployment is that the user and the network have a trust issue to solve.

I think we have three common cases, into which most others can be generalized:

One in which a user is assigned a device by their employer and the employer enforces a security policy; and

One in which a user is responsible for their security policy or preferences.

One in which a user, hypothetically named Vaul Pixie, wishes to enforce a security policy upon the devices using their network.

So, in the first case, domain name resolution order could be:

    MDM-assigned
    Manually-configured
    Application-specific
    DHCP
    Local/hosts/best-guess/whatever

In the second case, resolution order could be:

    Manually-configured
    Application-specific
    DHCP
    Local/hosts/best-guess/whatever

In the third case, resolution order could be:

    DHCP
    MDM-assigned
    Manually-configured
    Application-specific
    Local/hosts/best-guess/whatever

The first two cases look alike, in the sense that if there is no MDM configuration, they act the same.  The question is when network-assigned policy should take precedence over employer or user-defined policy.  At some level, there’s the “it’s my house, you’ll follow my rules, or get out” thing… If someone wants to use a network, it’s probably reasonable for the network to be able to define terms of acceptable use, and for the user (or their employer) to be able to make an informed choice about whether those terms are compatible with their policies and preferences, or whether to forego using that network.

But I think the key here is the informed choice bit.  I think the first two cases are close enough to be compatible, in an unobtrusive UI sense… If there’s MDM-assigned configuration, good UI would inform the user, if they tried to manually configure, and tell them that their manual configuration would not take effect because it’s overridden by the MDM configuration.

Likewise, I think it’s reasonable for applications to tell users that the configuration the application is trying to do won’t take effect because of a manually-configured or MDM-assigned resolver overriding it.  If the user wishes to, they can change the former.

But there’s no obvious mechanism for the network to present terms of use to a user, to inform them that they have to change their manual configuration, or allow it to be overridden, if they want to use the network, or to inform them that the network isn’t going to be available to them because of an incompatibility in policy with their MDM-assigned policy.

Do others view this problem differently?

                                -Bill

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 11 Nov 2021 21:38:01 +1100

On Thu, Nov 11, 2021, at 06:02, Ben Schwartz wrote:
> I don't understand.  The whole point of this is that it _reduces_ trust 
> in the PvD, by declaring that the client ignores the PvD's instructions 
> unless it can prove that this is what the owner of the affected domain 
> actually wants.

It's a net increase.  The PvD is being used to allow the network to select a resolver in a way that overrides the choice to use another resolver.