Subject: [DNSOP] howto "internal"

From: "A. Schulze" <[email-masked]>
Date: Tue, 24 Jul 2018 16:52:05 +0200

Hello,

some times ago there was an proposal (?) from Warren Kumari to define a zone "internal." for internal use.

We consider a major DNS redesign of a large enterprise network. Part of the network is private (RFC1918 address space in use)
some other parts are public. The whole network is currently organized as subdomains of example.com. 

One problem is the inability of users to distinguish the public/private state of different subdomains.
sub1.example.com is public, sub2.example.com isn't :-/

For that I like the proposal to use "internal." But that's far away from being a standard.
So I like to ask about alternatives...

Thanks for suggestions
Andreas

---

From: Petr Špaček <[email-masked]>
Date: Tue, 24 Jul 2018 17:08:43 +0200

Hello,

> So I like to ask about alternatives...

I would recommend you to use subdomain of your public domain.

My operational experience indicates that it is easiest to just use
"corp.example.com.", "office.example.com.", or even "i.example.com.".

These are legible to users and clearly indicate that anything below it
is internal name only. The rest of matter of configuration on the
authoritative server.

Nice thing is that this approach doesn't require:
- views
- forwarding
- explicit trust anchor (if you want DNSSEC inside internal network)

and generally just works :-)

-- 
Petr Špaček  @  CZ.NIC

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jul 2018 11:09:58 -0400

It would probably be easier to get internal.arpa, similar to home.arpa.
 You could use home.arpa now, but it would look a little funny... :)

On Tue, Jul 24, 2018 at 10:52 AM, A. Schulze <[email-masked]> wrote:

> We consider a major DNS redesign of a large enterprise network. Part of
> the network is private (RFC1918 address space in use)
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Jul 2018 08:20:06 -0700

i do not love the 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-10 draft, 
but i would love even less to see it reinvented in our ignorance.

re:

Ted Lemon wrote:
> On Tue, Jul 24, 2018 at 10:52 AM, A. Schulze <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>     some times ago there was an proposal (?) from Warren Kumari to
>     define a zone "internal." for internal use.
>
>     We consider a major DNS redesign of a large enterprise network. Part
>     of the network is private (RFC1918 address space in use)
>     some other parts are public. The whole network is currently
>     organized as subdomains of example.com <http://example.com>.
>
>     One problem is the inability of users to distinguish the
>     public/private state of different subdomains.
>     sub1.example.com <http://sub1.example.com> is public,
>     sub2.example.com <http://sub2.example.com> isn't :-/
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Tue, 24 Jul 2018 16:32:44 +0100

> "corp.example.com.", "office.example.com.", or even "i.example.com.".

We use private.cam.ac.uk.

> Nice thing is that this approach doesn't require:

We have an empty version of private.cam.ac.uk in an external view,
originally set up to avoid problems with CAA checking for X.509
certificates. It also massively reduces retries for REFUSED queries from
outside. (Our qps went down by about 50% when we introduced this view!)

> - forwarding

However you do still need forwarding (or stealth secondarying) for RFC1918
reverse DNS. Catalog zones make stealth secondaries almost as easy as
forwarding to set up and maintain :-)

> and generally just works :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole: Westerly backing southerly, 3 or 4, increasing 5 or 6 later in west.
Slight, becoming moderate in west. Mainly fair. Moderate or good.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 24 Jul 2018 12:00:18 -0400

At my employer we use real domains, but do not expose them to the outside
world (they just see 127.0.0.1).   It's a better than inverting  security
through obscurity like I have seen elsewhere (not that you would do
that Andreas).

Paul,  I am not with 100% love of the .alt name./idea but I do agree that
if we don't do something the Real Users (tm) will do something even more
broken and horrific.

Tim

---

From: Joe Abley <[email-masked]>
Date: Tue, 24 Jul 2018 12:02:43 -0400

Hi Andreas,

One problem with using non-unique namesapaces is that if you ever find yourself needing to join your infrastructure to someone else's you run the risk of collisions. 

[This is an analogue to the problem at the IP layer with using RFC 1918 addresses -- if I'm already using 192.168.1.0/24 and so is the other person, either one of us needs to renumber or we need a world of translation complexity to be able to talk to each other.]

My usual answer to your question is to register a domain for internal use and name everything within it. You can make the DNS records available to your internal resolver and not even delegate the zone in the public DNS if you like. The point of the registration is just uniqueness.

Using a subdomain of a name you already use is a functionally-equivalent answer, but it involves some degree of change to domain names you already use. Even if this is clearly low-cost today, it might add unwelcome complexity in the future.

There are many more angles to the wider discussion about new TLDs like internal, alt, etc or using names under example.com, but in your case since you get to start from scratch I think a few dollars per year to reserve a unique name is a cheap and good answer.

Joe

> On Jul 24, 2018, at 10:52, A. Schulze <[email-masked]> wrote:
> 
> Hello,
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Jul 2018 09:10:15 -0700

Tim Wicinski wrote:
> At my employer we use real domains, but do not expose them to the
> outside world (they just see 127.0.0.1).   It's a better than inverting
>   security through obscurity like I have seen elsewhere (not that you
> would do that Andreas).
>
> Paul,  I am not with 100% love of the .alt name./idea but I do agree
> that if we don't do something the Real Users (tm) will do something even
> more broken and horrific.

i also use real domains for my private stuff. but i also use RPZ locally 
for the internal bindings, not NS RR delegations that i'd have to keep 
out of my externally-served zone files.

-- 
P Vixie

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 24 Jul 2018 12:14:28 -0400

On Tue, Jul 24, 2018 at 12:10 PM, Paul Vixie <[email-masked]> wrote:

> for the internal bindings, not NS RR delegations that i'd have to keep out
> of my externally-served zone files

I had forgotten our threat intelligence teams use RPZ internally as well,
absolutely.

---

From: Grant Taylor <[email-masked]>
Date: Tue, 24 Jul 2018 12:11:09 -0600

> I would recommend you to use subdomain of your public domain.

Agreed.

The alternative might be to use a different public domain.

> - explicit trust anchor (if you want DNSSEC inside internal network)

Public (sub)domain(s) also make it easier to use external / 3rd party 
CAs.  -  Rather I've found it difficult to use private / non-public 
(sub)domain(s) when using public CAs.

-- 
Grant. . . .
unix || die

---

From: Grant Taylor <[email-masked]>
Date: Tue, 24 Jul 2018 12:31:16 -0600

Paul,

On 07/24/2018 10:10 AM, Paul Vixie wrote:
> for the internal bindings,

Do you leverage anything like Dynamic DNS updates in conjunction with 
DHCP?  If so, how well does that play with the configuration that you're 
using?

> not NS RR delegations that i'd have to keep out of my externally-served 
> zone files.

Is there a best practice around this method of delegating to 
sub-domain(s) that are inaccessible to the public?

Is it better to return NODATA or NXDOMAIN to global clients querying for 
host.sub-domain.example.net?  Or is there a different error that can be 
returned to indicate no access?

I guess there's always delegating to a server that is inaccessible 
externally too.

-- 
Grant. . . .
unix || die

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Jul 2018 12:18:03 +0100

Grant Taylor <gtaylor=[email-masked]> wrote:
>
> Is there a best practice around this method of delegating to sub-domain(s)
> that are inaccessible to the public?

I recommend having an empty public view of your private zone, so that
external queries succeed with NXDOMAIN / NODATA. Returning REFUSED for a
private zone causes retries, and not responding at all causes even worse
problems such as EDNS fallback attempts. I haven't tried delegating to
RFC1918 addresses, but that is likely to cause similar weirdness.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: South 3 or 4, becoming cyclonic 5 to 7, occasionally gale 8 for a
time. Slight or moderate, becoming rough or very rough. Rain. Moderate or
poor.

---

From: Grant Taylor <[email-masked]>
Date: Wed, 25 Jul 2018 13:14:45 -0600

On 07/25/2018 05:18 AM, Tony Finch wrote:
> external queries succeed with NXDOMAIN / NODATA.

ACK.

What is your opinion on blindly grafting the sub-domain onto the parent 
zone without proper delegation.  I.e. internal DNS server hosts 
internal.example.net and external DNS server returns NXDOMAIN for 
internal.example.net.

I have my doubts about this sort of scheme supporting DNSSEC.  -  I 
think it would be better to have a mostly empty zone that is properly 
delegated that re-use the same DNSSEC keys.

I might even go so far as to have the external server be a slave for a 
specific empty view transferred from the internal server.  That way the 
keys stay internal.

> Returning REFUSED for a private zone causes retries, and not responding 
> at all causes even worse problems such as EDNS fallback attempts.

ACK

> I haven't tried delegating to RFC1918 addresses, but that is likely to 
> cause similar weirdness.

As I type this I wonder about delegating to RFC 1918 address via names 
in an NS record that are within delegated zone.  Thus they would require 
glue records.  Externally I'd omit the glue records.  Internally I'd 
have the records within zone scope along with all the other zone data.

I suspect that this may cause odd retry issues too.

It may leak some information, but I do think that the hard NXDOMAIN / 
NODATA is likely cleanest for the DNS protocol.

-- 
Grant. . . .
unix || die

---

From: Scott Morizot <[email-masked]>
Date: Wed, 25 Jul 2018 15:32:09 -0500

On<gtaylor=[email-masked]> wrote:

> I have my doubts about this sort of scheme supporting DNSSEC.  -  I think
> it would be better to have a mostly empty zone that is properly delegated
> that re-use the same DNSSEC keys.
>
A true "internal" enterprise network with entirely private DNS zones will
often have distinct authoritative nameservers for the private versions of
zones, distinct internal recursive nameservers, and will restrict clients
on the enterprise network from accessing any recursive nameservers outside
the enterprise network. The decisions I've made for my employer's
architecture reflect those requirements and preconditions. We also DNSSEC
sign most authoritative zones and DNSSEC validate responses on all
recursive nameservers.

With those conditions, every zone needs to be rooted in an officially
registered and delegated domain to support proper chain of trusts with
valid secure or insecure delegations as appropriate. With those conditions
in mind, most zones (domains and subdomains within a tree) are designated
as either public or internal/private. At the point where a delegated
subdomain shifts to internal, a public placeholder version of the zone is
created. While we have multiple registered second level domains, we have
two primary second level domains that also support our enterprise. One of
them is, for all practical purposes, entirely private. So only a second
level zone placeholder is public. The other is public at the second level
and third level (and lower) domains are a mix of public and private. Third
level zone that represent the top of an internal zone hierarchy off that
second level domain tree all have a public placeholder.

At the demarcation point where a domain in the tree shifts to private
(typically the second level domain in one case and at a number of the third
level domains in the other) the DS records for both the public placeholder
and the private version of the zone are placed in the public parent zone.
Whether the placeholder or the real version of the zone is resolved, an
appropriately signed DS record for a key signing the DNSKEY RRSet can
always be resolved.

Given the complex, layered nature of our recursive DNS infrastructure we
used forward zones and default forwarders within the enterprise itself. Our
Internet/extranet recursive configuration is also more complex than even
most enterprises.

Yes, trust anchors are an alternative within the standard in the absence of
valid delegations or when "fake" TLDs are used, but those are not really
manageable at a large enterprise scale. We do use them to anchor RFC1918
reverse arpa zones with our own versions. That's relatively
straightforward, but I wouldn't want to attempt it on any broader basis.

Admittedly, the above represents a DNS architecture supporting a large,
highly restricted enterprise network. But in any architecture where DNSSEC
validation is a factor, the chain of trust will always need to be
considered.

We also do employ RPZ. And we do break DNSSEC (and have encountered at
least one malware domain that was DNSSEC signed). We're fine with DNSSEC
validation failing for responses we've rewritten to block with RPZ. Our key
considerations are that the query will not go out to the Internet and the
client will not get a response from the Internet. Failed validation at the
client if it should validate or SERVFAIL from a lower level nameserver to
the client are perfectly acceptable results from our perspective.

Scott

---

From: Tony Finch <[email-masked]>
Date: Thu, 26 Jul 2018 14:00:12 +0100

Grant Taylor <gtaylor=[email-masked]> wrote:
>
> What is your opinion on blindly grafting the sub-domain onto the parent zone
> without proper delegation.

Asking for trouble. We used to do that in the dim and distant past but
not any more because it's incompatible with DNSSEC.

> As I type this I wonder about delegating to RFC 1918 address via names in an
> NS record that are within delegated zone.  Thus they would require glue
> records.  Externally I'd omit the glue records.  Internally I'd have the
> records within zone scope along with all the other zone data.
>

Yes.

However, if you are willing to have views in the parent public zone, you
might as well omit the private delegation entirely in the public version.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight, Humber: East 3 or 4 veering southeast 4 or 5, increasing
6 at times. Slight, becoming slight or moderate later. Thundery showers
developing. Good, occasionally poor.