2

My company, 'example.com', has a public host www.example.com. The (legacy Windows managed) internal network has several internal hosts internalhost1.example.com, internalhost2.example.com and so on.

The internal network has an internal private authoritative DNS server for example.com. The public DNS server is hosted somewhere on the internet. External users on the internet cannot resolve the internal hosts, they are not available on the public DNS server. Internal users can resolve internal hosts because they are using the internal DNS server to resolve.

Now the public DNS is in the process of getting secured by DNSSEC. I have verified that currently the internal clients do not seem to care that the external DNS is secured by DNSSEC, they just continue trusting the internal DNS server, the clients are 'non-validating'.

Now my question is if there is any plan or roadmap to force all clients to validate DNSSEC? How long will the above setup work if we secure the public DNS with DNSSEC and keep the private DNS non-DNSSEC? A year? Ten years? Forever? Should we convert our internal domain to example.local or can we leave it example.com?

Improve this question

1 Answer 1

Reset to default
3

TLDR; if you manage your workstations then your workstations will always work as you expect.

Internal systems should've been a subdomain of the public domain and then you can delegate/sign the internal zone with your parent domain, and would also no longer need split DNS as your external records (www.example.com) would resolve externally, you CAN add A records that point internally, externally, but you cannot add glue records for internal IPs. Also I would recommend always using a domain name you control, and not a factitious example.local and absolutely not a domain.companytld

Windows (Named Resolution Policy Table (NRPT)) and linux (systemd-resolve) both support client-side settings for DNSSEC validation as well as the ability to specify what domains should always be signed.

Other things to consider, DoH (DNS over HTTPS) which could bypass all your existing security and dns manipulations.

Improve this answer
4
  • 1
    Lot of stuff in this answer. Windows absolutely has DNSSEC client-side enforcement that can be specified in Group Policy (Name Resolution Policy). Without this client-side requirement/enforcement, DNSSEC would be nearly useless. In addition to this enforcement, IPSEC can be required and the also the chain of trust of the signer. This was introduced in Windows Server 2008 R2 but was vastly improved in Windows Server 2016. Enforcing this would address the specific use case with a tld that cannot be registered and off-network hosts susceptible to DNS hijacking.
    – Greg Askew
    Nov 28, 2020 at 13:58
  • @GregAskew Thanks Greg, NRPT looks extremely powerful, I think everyone should be using it!
    – Jacob Evans
    Nov 30, 2020 at 14:26
  • Delegation to internal DNS or public internal A records: can/should you publish internal LAN ip addresses of such hosts? How about the practice of not publically exposing unnecessary internal information? Validating clients: NRPT seems to involve listing domain names to validate. Should not validation be defined in the DNS DNSSEC tree?
    – anneb
    Nov 30, 2020 at 15:02
  • Your internal network address is not private, it's one of three ranges, all of which are easily scanned. However you can but absolutely do not need to create public NS records if your dns recursive resolves have this information, you would only need DS public keys or imported into your clients (via trust anchors or NRPT). see weberblog.net/signing-a-delegated-subdomain
    – Jacob Evans
    Nov 30, 2020 at 15:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .