Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Scott Morizot <[e-mail]>]

I guess I'll speak up as someone who has been managing the DNS/DNSSEC
design and implementation of a large organization with a complex set of DNS
requirements (operational and security-related) since we began the process
of signing our zones in 2011. We have universal DNSSEC validation in place
across our enterprise recursive layers and almost all zones, internal and
external, are DNSSEC signed. I forget the exact count without checking, but
we have 100+ 3rd level and lower internal zones. Outside public placeholder
zones required for proper delegation and chain of trust at the appropriate
level where internal/external divisions are made (typically the 3rd level)
we do not normally maintain differing versions of external/internal zones,
but we have a few explicitly defined for that purpose because there is a
legitimate requirement for differing internal/external resolution. Those
needs are always segregated into zones defined for that purpose to simplify
ongoing administration. (We never want to be in a situation where normal,
routine record updates require changes in multiple versions of a zone. That
would be an administrative nightmare.) We employed manual trust anchors at
different phases of our implementation, but now have very few in place. One
is to establish trust for an internal zone for which we do not control the
administration of the parent zone. Off the top of my head, I believe that's
the only significant one left. Maintain trust anchors was unpleasant and
always viewed as a transitional mechanism, not something we wanted to do on
a lasting basis.

On Fri, Nov 30, 2018 at 11:22 AM Paul Wouters <[e-mail]> wrote:

> On Fri, 30 Nov 2018, Ted Lemon wrote:
> That means your public DNS zone must be signed for your internal DNS
> zone to be signed? Otherwise you cannot have this signed delegation?
> That would mean you cannot run DNSSEC internally before you run it
> externally.
>
>
Outside placing trust anchors on every device performing validation, that's
true. Establishing trust in a zone when the parent zone is insecure is a
pain. I guess DLV could still be used. I considered it at one point. I
forget why I decided not to go that route. It was too many years ago. Then
again, from the signing side, I'm hard-pressed to imagine a reason to start
signing internal zones without signing their external parents except in the
situation where you do not control the public parent zone. Normally you
want to start at the top of the hierarchy and work your way down.


> >   When you look things up in that zone outside the firewall, you get
> NXDOMAIN for everything but the SOA on the zone, which returns an old
> serial number.   Inside the firewall, they get answers, which
> > are signed, and which validate.   There's no need for a special trust
> anchor here.
>
> This scheme seems to require both inside and outside zones are signed
> with the same key, or as Mark pointed out, both internal and external
> zones need to share their DS records and keep these in sync. As these
> are usually different organisations/groups/vendors/services, that is
> an actual management problem.


Or you can do what we did and place DS records for both the internal and
external KSKs (using public placeholder versions of the internal child
zones just to establish the delegation point) in the parent zone. That
establishes chain of trust whichever version of the zone is resolved. That
works whether the public version is just a placeholder with nothing else of
significance in it or if it is a zone where both the external and internal
records matter and are used by the appropriate source for the query, but
differ.


> >   There are two ways to approach this.   One is to assume that the
> validator never checks the SOA on the zone.   This is almost certainly the
> case for nearly any use case.   In that case, you just
> > run the internal and external name servers with the same ZSK, and have a
> delegation above it.   You don't worry about zone serial numbers, because
> they don't affect validation.   When you're inside the VPN,
> > you get answers for the internal zone; when you're outside the vpn, you
> get answers for the outside.   Both validate, because the DS record(s) are
> referring to the same ZSK(s).
>
> coordinating shared ZSK's is even harder then requiring sharing DS
> records! ZSKs roll every month, and a lot of software auto-generates
> and performs the roll without any humans involved. It seems extremely
> fragile to need to coordinate ZSKs between different organisations,
> be ready for the same algorithm rollovers, etc etc.
>
>
Yes, absolutely. I wouldn't want to try to coordinate sharing signing keys
(KSK or ZSK) across different zones under any circumstance. I know some
places that do it with KSKs because the product they use supports it as
long as both versions of the zone are signed on the same device, but we
don't even sign internal and external zones in the same place. Or maintain
the master data in the same place for that matter.

I don't really have any thoughts on the draft itself, but wanted to add my
own real world experience with managing DNSSEC trust. On the validation
side, we also don't allow any device in the enterprise network, including
internal nameservers, to send or receive DNS queries to the Internet.
Period. Only our perimeter recursive, DNS caches can do that and those will
only accept queries from authorized enterprise recursive, caching
nameservers. And we have protections, including different DNS blacklists,
at each layer. So we have a lot of control over what devices connected to
our network can and cannot do and they do not have unrestricted ability to
query Internet DNS even through our multiple layers. We also use the cli
version of dnsviz a lot to ensure we understand what different points on
the recursive side of our enterprise DNS infrastructure are seeing.

Scott