Re: [Add] Usage of NS in draft-ietf-add-split-horizon-authority

[Paul Wouters <[e-mail]>]

On Wed, 8 Feb 2023, Benjamin Schwartz wrote:

>       Using a prefix based on the internal zones, toronto.nohats.ca and Vancouver.nohats.ca would have their NS records at different locations,
>       which would be much cleaner.
> 
> I think we all agree on that.  The current draft would have you publish NS RRsets, enumerating the respective allowed internal resolvers, at
> "toronto.nohats.ca" and "vancouver.nohats.ca" (even if these are not zone cuts).  If the client receives a hint that these are internally-resolved names,
> it can perform an NS query to confirm.
> 
> With a static prefix, these NS records would instead live at "_extra.toronto.nohats.ca" and "_extra.vancouver.nohats.ca".

If we ignore hashing for now, I meant for them to live at
toronto._splitdns.nohats.ca and vancouver._splitdns.nohats.ca. That way,
toronto.nohats.ca is still a non-existing zone in the public dns, which
is what most people want.

>       The hash is to make the internal zone slightly more private (the hash is over the FQDN to prevent rainbow tables)

> It sounds like your goal here is to avoid publicly revealing the "toronto" and "vancouver" labels, in this example.  I don't view that as a significant
> benefit, since it can be resolved by restructuring the names as "toronto.internal.nohats.ca", etc.

For some deployments that works, not for others.

>, and this is the most common layout for internal corporate names anyway.

[citation needed]

For fortune500 companies maybe. For SMB, this is very unlikely the case.

> Also, I think DNSOP's experience with NSEC3 suggests that using hashing to protect these names is more trouble than it's worth.

I think .com and .net would not agree with you. Regardless, the
complexities of NSEC3 is not what we are looking at here.

> I also have some concerns about how to make hashing work with the draft's "walk up the tree" behavior (Section 6, paragraph 1), which allows the client to
> validate arbitrary "local domain hints" without knowing in advance where the internal zone starts.

You receive ns1.toronto.nohats.ca. You try dig NS for:

hash(ns1.toronto.nohats.ca.)._splitdns.toronto.nohats.ca.
hash(ns1.toronto.nohats.ca.)._splitdns.nohats.ca.

I would probably try walking down the tree and skipping the root:
hash(ns1.toronto.nohats.ca.)._splitdns.ca.
hash(ns1.toronto.nohats.ca.)._splitdns.nohats.ca.

Skipping the TLD is tempting for ccTLDs, but not for gTLDs as we could
have some vanity TLDs, eg :

hash(ns1.toronto.google.)._splitdns.google.

Here using the SPL could be used again to skip some queries.

> I believe hashing is appropriate if we need to support a scenario where:
> 1. There is no transition label (e.g. "internal") between the public zone and the first confidential label, AND
> 2. The local nameservers cannot be entrusted with local authority over the public zone.

> This seems like an unusual case to me.

To me 2) is always true and 1) is a very common case.


> It also creates significant interference with DNSSEC, because it forces the client to manage two different views
> of a single zone.

Yes that is correct. That is why RFC8598 for split DNS in IKEv2,
supports receiving trust anchors (eg DNSKEY/DS), where it leverages
the IKEv2 as trusted resource (after validating the IKEv2 GW
credentials).

If you run a split-DNS and you want DNSSEC to work, there is no way
around this. The public view has a DNSSEC that proves the split-dns
zone does not exist. If the public view did prove it, and you want
to use that, you need a significant infrastructure for all your
branch networks and their DNS servers to use the same DNSSEC key,
at which point it becomes questionable if the enterprise is still
in control of the private key distribution. It is much safer to
securely deliver the individual trust anchors (eg via IKEv2).

>  For example, a client that queries "vanx.nohats.ca" will receive an NSEC response that denies the existence of "vancouver.nohats.ca",
> but this must be ignored.

If you connect to a client that claims to be vancouver.nohats.ca, you
will need to flush your cache for everything under that zone. Again,
the libreswan IKEv2 implementation does that. Upon disconnect, it also
flushes the cache for these entries.

>  Getting this right could be complicated.  Having a clear division of responsibilities, like a zone cut, seems easier.

It's not easier to tell an organization that their 100 branches need to
consolidate their DNS deployments and make it fully dependent on the
public zone, so that if the uplink to a branch dies, the entire internal
network dies.

> If the group feels that this case is important to support, I would prefer a hashing scheme that uses a stable high-entropy salt known only to the local
> network participants.  This would remove any concerns about brute-force attacks, but it would likely require an additional network-client configuration
> parameter.

This seems more complicated? It would need a specification or even
provisioning scheme to roll out. If you do provisioning anyway,
why not securely provision a list of internal domains with their
DNSKEYs and forget about all draft?

> If you are authorizing a split dns set of nameservers, you might as well support a DS record so the internal zone can be DNSSEC signed with a trust
> anchor.
> 
> I'm not sure what you mean by "trust anchor", but I agree that it would be good if the local nameserver can serve DNSSEC that validates all the way to the
> root, without having to hold a private key for the public zone.

trust anchor is a DNSSEC term, it basically means a DNSSEC DNSKEY or DS
record that is configured for an FQDN.

My point was, if we are "authorizing" an internal server to zone zone
FOO, why not also allow this mechanism to send the DNSKEY used to sign
that internal zone (as there is no DS record in the parent zone if you
want to keep your internal zones out of the public view).

> You plan to place 50 NS records in one location to support 50 different branch split zones ?
> 
> 
> No, each split zone would have its own NS RRSet, as in the present draft.  Indeed, the presence of the NS RRSet is what defines the split zone.
> 
> It sounds like you're making an assumption that each "site" would use unique NS names.  This is allowed but not required.  Even if unique hostnames are
> used for some purposes, for DNR the same names can be used at each site, allowing a small number of NS records to authorize arbitrarily many sites.

Again, you assume a fresh rollout of DNS over a multi-national
organization. That is not how split-dns zones work. The whole
point of why there are so prevalent is that it is easy to set
them up and doens't require the internal network people to talk
to the DNS people of the public zone. Usually the public zone
is hosted completely different, with different requirements,
much more anti-ddos meassures, etc etc.

>       That will cause TC and TCP.
> 
> I don't think this is a big problem.  These queries should be infrequent, and will most commonly be conveyed to the client over an encrypted (i.e.
> non-truncating) transport.

If I had a dollar for every nameserver that got TCP 53 blocked, I'd be retired :)

> The client needs PSL like awareness regardless, you don’t want .com to start claiming it is split and have believe it.
> 
> I think we can recommend this, but of course the IETF doesn't maintain a PSL.

I believe the IETF is trying to revive the dbound WG, so who knows.

Paul