On Sat, 1 Dec 2018, Scott Morizot wrote:
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
Thanks for the write up! It is always good to hear actual enterprise
deployments.
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.
So the interesting question here is, how is this one zone securely
resolved when you are connected to the network via a VPN? Or is this
zone not available for VPN users? And if this draft could make it
available, would you? Or, do your VPN users not use split-tunnel,
and connect to an inside DNS server once connected?
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.
That is a good solution as well. Although I would be a little worried that
a compromise of the public view could trick people into establishing the
"internal" zones in the external view to trick people into logging on
and giving out their password. But that is surely far down the list of
easy attacks to run.
I don't really have any thoughts on the draft itself
That is too bad, because I'd be very curious how you handle DNSSEC with
your VPN clients. Not many large organizations run DNSSEC on both
internal and external views. So I am curious how you handle DNSSEC
for your (split?) VPN clients. But I understand if you cannot share
more data about that in a public forum.
, 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.
So I guess the interesting thing here is the device that is in
split-tunnel mode. It would not receive the protection of your
DNS infrastructure for external lookups, so if you allow BYOD
to connect to your network, it would be bypassing those DNS
security checks for non-organisation DNS queries, which would
put the BYOD under greater risk. Perhaps you do not allow
split-tunnel or BYOD for those reasons :)
Thanks for your input,
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
