Subject: [Add] add-enterprise-split-dns and split horizon DNS

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Dec 2021 14:26:47 -0500

I have just watched the ADD-20211108-1600 session from IETF112.
I had a conflicting session.

What I took from the conversation is that many people would like to solve DDR
in a split-horizon situation, and that if we could find a solution that
solved typo-squatting by local resolvers that would also be very welcome.
(typo-squatting is of course trivially solved by DNSSEC, which I'm told
browsers refuse to implement because miliseconds...)

The document says:

   A typical use case is an Enterprise network that requires one or more
   DNS domains to be resolved via network-designated DNS servers.  This
   can be a special domain, such as "corp.example.com" for an enterprise
   that is publicly known to use "example.com".  In this case, the
   endpoint needs to be informed what the private domain names are and
   what the IP addresses of the network-designated DNS servers are.  An
   Enterprise can also run a different version of its global domain on
   its internal network.  In that case, the client is instructed to send
   DNS queries for the enterprise public domain (e.g., "example.com") to
   the network-designated DNS servers.  A configuration for this
   deployment scenario is referred to as a Split DNS configuration.
   Another use case for split-horizon DNS is Cellular and Fixed-access
   networks (ISPs) typically offer private domains, including account
   status/controls, and free education initiatives [INS].

and I'd like to strongly distinguish the case of "corp.example.com"
(I've also seen and used "intranet.example.com"...) from one where there are
different "authoritative" views of example.com.

In fact, I'd like the document to put these two into different sections.
I think that we need to write a BCP that strongly encourages corp.example.com
as the model for hiding names.
Dan and Wesley mentioned previous efforts that had failed.
I'd like to understand more about what was proposed and how/when/why they
failed.

Maybe the issues are different now and we could get consensys around something.
Yeah, maybe that does not fit into the ADD charter: but it seems that ADD
(DDR) might be a forcing function to finally do something here.

I don't like the solution in this document.
I am in favour of solving the problem though.
I don't like PvD at all.

But, the entire issue seems to fall into the "Doctor! Doctor! It hurts when I push
this knife into the electrical socket! What can you prescribe to deal with
the hurt?"

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Dec 2021 16:34:10 -0800

> browsers refuse to implement because miliseconds...)

I don't know who told you this, but that's not the reason that browsers do
not
implement DNSSEC. The primary reason that browsers do not implement DNSSEC
is
because of concerns that otherwise valid resolutions will fail due to
recursive
resolvers/middleboxes incorrectly handling DNSSEC records, thus resulting
in increased user-visible error rates.

-Ekr

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

---

From: Geoff Huston <[email-masked]>
Date: Fri, 3 Dec 2021 12:05:11 +1100

> On 3 Dec 2021, at 11:34 am, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Dec 2, 2021 at 11:27 AM Michael Richardson <[email-masked]> wrote:
> 
> I don't know who told you this, but that's not the reason that browsers do not
> implement DNSSEC. The primary reason that browsers do not implement DNSSEC is
> because of concerns that otherwise valid resolutions will fail due to recursive

Hi Eric,

Each time this topic comes up (why browsers do not use DNSSEC, or the related topic
as to why browsers do not use DANE) I hear different “primary reasons”. 

- It takes too long,  
- RSA-1024 is insecure, 
- the DNS does not cope with large responses,
- the DNS provisioning infrastructure does not support DS records,

and now I am reading here from your message that:

- middleboxes (I assume you mean DNS forwarders?) and recursive resolvers erroneously fail. 

So can I take it from your message here that this concern that recursive resolvers
got DNSSEC all wrong is “the primary reason” why browsers do not use DNSSEC, 
and also the related topic as to why browsers do not use DANE.

Over the years, I have picked up this sense that each time this topic is raised, a
different “primary reason” is offered as to why the browserverse appears to be
avoiding use of DNSSEC. So if we headed into pinning down the behaviours of DNS
resolution infrastructure and their DNSSEC capabilities with measurement we could
replace these vague dataless assertions with data that could prove or disprove this
“primary reason”. Would you agree?

Thanks,

 Geoff

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Fri, 3 Dec 2021 01:10:39 +0000

Hi Everyone,

DNSSEC & DANE adoption is a great topic, but needs more beverages than available in a virtual environment.

Can we please focus on discovery issues as I fear this other topic set has the potential to fill up everyone's inbox and still not resolve anything.

Regards
Glenn - one of your friendly ADD co-chairs and someone who doesn't want to wake to a massive thread to wade through tomorrow.

---

From: Dan Wing <[email-masked]>
Date: Thu, 2 Dec 2021 17:46:18 -0800

Split-horizon DNS has the same name on the inside ("private") network as on the outside ("public"), but they resolve to different IP addresses.  So, www.example.com on the inside resolving to, say, 192.168.1.1 (an RFC1918 address to make it clear it is not Internet routed) and www.example.com on the outside resolving to 1.1.1.9 (I would have used 1.1.1.1, but, alas, that's used by a Real Server now-a-days).  If there is an internal delegation where "corp.example.com" is only resolvable from the inside that is not "split DNS" -- at least, not by my definition.  Such an internal-only delegation is a far easier problem because if the wrong DNS server is queried, it won't have any answer (ignoring data leakage issues of querying the wrong DNS, of course).  Split DNS is complicated because querying the wrong DNS returns the wrong answer and the wrong IP address is either not routable from the Internet or gives the public view of the resource when the "employee" view was desired.

I agree the proposal in our document may not be ideal.  During the presentation and Q&A we discussed briefly another approach to test for a squatted domain by using DNSSEC rather than querying a public DNS server.  We intend to add that to the document, but, more importantly, intend to compare/contrast the approaches.  I hope to get to those edits with my co-authors before Christmas and back in front of the working group.

-d

> On Dec 2, 2021, at 11:26 AM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Dec 2021 21:31:16 -0500

On Dec 2, 2021, at 20:46, Dan Wing <[email-masked]> wrote:
> 
> Split-horizon DNS has the same name on the inside ("private") network as on the outside ("public"), but they resolve to different IP addresses.  

That is one form of split dns. Split simply means there is more than one view that is different.

>  If there is an internal delegation where "corp.example.com" is only resolvable from the inside that is not "split DNS" -- at least, not by my definition.

You seem to be trying to redefine the definition then.

> Such an internal-only delegation is a far easier problem because if the wrong DNS server is queried, it won't have any answer (ignoring data leakage issues of querying the wrong DNS, of course).

That it won’t resolve to anything won’t make the problem easier.

>  Split DNS is complicated because querying the wrong DNS returns the wrong answer and the wrong IP address is either not routable from the Internet or gives the public view of the resource when the "employee" view was desired.

I really would not use this definition of split dns. It will lead to confusion and solutions offered would be incomplete and not cover the actual issues this WG is trying to address.

> I agree the proposal in our document may not be ideal.  During the presentation and Q&A we discussed briefly another approach to test for a squatted domain by using DNSSEC rather than querying a public DNS server.

I don’t think typo squatting is a problem in scope for recursive resolver selection for specific domain names.

The problem remains how to securely receive, validate and authorize a list of domain names that should be resolved via the local network advertised nameserver.

The solution seems to steer towards “putting things in public dns”, which I do not think is the right solution. Defining “internal only domains” as “not split dns” is not a workable solution for this.

Paul

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Fri, 3 Dec 2021 15:29:05 +0000

> The problem remains how to securely receive, validate and authorize a list of domain names that should be resolved via the local network advertised nameserver.

I might suggest the addition to the end of " and only by that nameserver." to address the leakage concerns

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Paul Wouters
Sent: Thursday, December 2, 2021 9:31 PM
To: Dan Wing <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Add] add-enterprise-split-dns and split horizon DNS

Paul

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Dec 2021 17:47:41 -0500

> implement DNSSEC. The primary reason that browsers do not implement

Geoff Houston said this at RIPE83 and probably also at an IETF112 side meeting.

    > in increased user-visible error rates.

yet, 8.8.8.8 does DNSSEC resolution, and that doesn't seem to be a concern.

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Dec 2021 17:51:50 -0500

> Can we please focus on discovery issues as I fear this other topic set
    > has the potential to fill up everyone's inbox and still not resolve
    > anything.

Sorry, I can't abide by this.

This is germane to whether or not split-horizon-dns is really a problem that
needs solved. Is typo-squatting really a concern when there is split-horizon DNS?

I claim that it isn't: that DNSSEC provides for corp.example.com delegations
that satisfy all of the issues that multiple-views claims to solve.

If you agree with me, then don't adopt the document.
It you disagree with me, then DDR has to deal with all the shit that DNSSEC
was intended to solve.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Dec 2021 17:56:36 -0500

Dan Wing <[email-masked]> wrote:
    > Split-horizon DNS has the same name on the inside ("private") network
    > as on the outside ("public"), but they resolve to different IP
    > addresses.  So, www.example.com on the inside resolving to, say,
    > 192.168.1.1 (an RFC1918 address to make it clear it is not Internet
    > routed) and www.example.com on the outside resolving to 1.1.1.9 (I
    > would have used 1.1.1.1, but, alas, that's used by a Real Server
    > now-a-days).  If there is an internal delegation where
    > "corp.example.com" is only resolvable from the inside that is not
    > "split DNS" -- at least, not by my definition.  Such an internal-only

Sure, I'd love to give it a clear name to distinguish it.
The document in question attempts to address both situations, however, and
that's the document that we are discussing adopting.

If the document wants to restrict itself to what you think of "real" split-DNS
then that might be easier to decide.

    > delegation is a far easier problem because if the wrong DNS server is
    > queried, it won't have any answer (ignoring data leakage issues of
    > querying the wrong DNS, of course).  Split DNS is complicated because
    > querying the wrong DNS returns the wrong answer and the wrong IP
    > address is either not routable from the Internet or gives the public
    > view of the resource when the "employee" view was desired.

Yeah. It totally sucks.  I think we should tell people to stop doing it.
I think that securing DNS lookups (whether by doing DNSSEC locally, or
speaking to a recursive DNSSEC validator securely), and providing privacy is
a sufficient hammer to get people to change.

    > I agree the proposal in our document may not be ideal.  During the
    > presentation and Q&A we discussed briefly another approach to test for
    > a squatted domain by using DNSSEC rather than querying a public DNS
    > server.  We intend to add that to the document, but, more importantly,
    > intend to compare/contrast the approaches.  I hope to get to those
    > edits with my co-authors before Christmas and back in front of the
    > working group.

Awesome.
Can you also give us a name/handle to talk about the corp.example.com
"private" delegation.   I wrote a document about this a few years ago.
I called them secret gardens, rather than walled gardens.
(I always wanted to read _Secret Gardens_ as a kid. I could never steal the
book from my sister though)

---

From: Dan Wing <[email-masked]>
Date: Tue, 7 Dec 2021 17:32:09 -0800

> needs solved. Is typo-squatting really a concern when there is split-horizon DNS?

What is the desired behavior if a DNS server advertises "I own google.com, send queries to me" or "I own piratebay dot whatever-this-week".

> that satisfy all of the issues that multiple-views claims to solve.

I don't understand what is meant by "corp.example.com delegations".  Are you describing a delegation where the FQDN www.corp.example.com is resolvable when querying a DNS server inside a network but that same FQDN is not resolvable when querying example.com's DNS on the Internet?  Or that it resolves to different A records when queried inside versus on the Internet.

-d

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Dec 2021 08:31:27 -0500

> I don't understand what is meant by "corp.example.com delegations".
    > Are you describing a delegation where the FQDN www.corp.example.com is
    > resolvable when querying a DNS server inside a network but that same
    > FQDN is not resolvable when querying example.com's DNS on the Internet?
    > Or that it resolves to different A records when queried inside versus
    > on the Internet.

That's why it would be nice if the draft explained this and gave it a name.

Yes, "corp.example.com" has an NS record in example.com which points to an IP
address/DNS-server that does not answer queries if you aren't within the
domain.

I have seen it in use at multiple places over multiple decades.
It works far better than having two authorities for the same name,
particularly for entities that have multiple points of presence with VPNs
connecting them.

{IPv6 makes this trivial, but it can also be done with less elegance using
RFC1918, if the enterprise has no public IPv4 and can't hire any. }

---

From: Joe Abley <[email-masked]>
Date: Wed, 8 Dec 2021 08:46:15 -0500

> That's why it would be nice if the draft explained this and gave it a name.

You're saying "this" like it's one thing that is unambiguously achieved in a single way. It's not. 

> address/DNS-server that does not answer queries if you aren't within the

Making a public lame delegation to a private set of servers is one way to do this. 

Hosting an internal zone on servers that sit in the resolver graph for the desired set of clients is another. 

Forking the example.com zone into multiple namespaces served by different servers is another. There is more than one mechanism by which those servers receive particular queries. 

> particularly for entities that have multiple points of presence with VPNs

"Authorities," "name" and "points of presence" are all ambiguous here. 

I point these things out just to illustrate that there are many ways to peel the covering fabric from these multiple rhetorical animals. Clear communication around these issues really needs some work towards a usefully-complete taxonomy. Without a clear description of the deployment scenarios to be covered it's really premature to claim any particular solution is complete. 

As a rule, the DNS in practice is messier than DNS in theory, and DNS in theory is already pretty messy. 

> RFC1918, if the enterprise has no public IPv4 and can't hire any. }

The address family used to reach particular nameservers implicated in the above seems like the most superficial of details to me. 

Joe

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Dec 2021 10:17:08 -0500

Joe Abley <[email-masked]> wrote:
    > I point these things out just to illustrate that there are many ways to
    > peel the covering fabric from these multiple rhetorical animals. Clear
    > communication around these issues really needs some work towards a
    > usefully-complete taxonomy. Without a clear description of the
    > deployment scenarios to be covered it's really premature to claim any
    > particular solution is complete.

+100.

    > The address family used to reach particular nameservers implicated in
    > the above seems like the most superficial of details to me.

Some people get their panties in a knot if a NS resolves to an RFC1918
address.   (And in the absence of DNSSEC, I probably agree)
There are a number of nicer alternatives though.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Dec 2021 11:48:13 -0500 (EST)

> What is the desired behavior if a DNS server advertises "I own google.com, send queries to me" or "I own piratebay dot whatever-this-week".

This has been the unanswered question from the first BoF, through
charter discussion, through draft discussion.

> I don't understand what is meant by "corp.example.com delegations".

Usually it is shorthand for "private view only delegations", but I also
do not understand that in relation to the DNSSEC provision.

Paul