Contents x
Using private or internal DNS zones - guidance and best practice
  • 04 Jul 2022
  • 6 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Contents

Using private or internal DNS zones - guidance and best practice

  • Updated on 04 Jul 2022
  • 6 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Article Summary

Overview

For some organisations, it may be desirable to add private, internal names to their DNS - that is, names that can be resolved only by their internal nameservers. When setting these up, it is important to be aware of potential pitfalls and to follow good practices in order to avoid name resolution and operational problems for users and applications.

Pick your private domain names wisely..

  • Do use names that can be delegated by you from your own registered domains. For example:
internal.isc.org

This is a name that is within the isc.org registered name space. Names within internal.isc.org can be properly managed or delegated from the isc.org zone and will never collide with other names in the Internet.

  • Do not use names in domains that don't belong to you or which are currently unassigned, even though they may give the appearance of adhering to a DNS naming standard. For example:
isc.internal

The internal top level domain (TLD) did not exist in the public Internet at the time of writing this recommendation. Its future ownership or existence is uncertain.

  • Do not use names in domains that have not been registered to you. For example:
private.myisc.org

The domain myisc.org does not belong to ISC. If we use it privately, then it is possible for someone else to take ownership of this domain, establish their own nameservers for it, and to use it (either accidentally or deliberately) to redirect our applications or users.

See this ICANN FAQ on Domain Name Collisions for more information: https://www.icann.org/namecollision

Configure your DNS services robustly

Servers providing answers for names in private space usually also need to field and respond to client queries that require resolution via the public Internet. Making this work seamlessly is easy, once you understand how DNS resolvers find answers to client queries.

  • One robust and future-proof configuration is one in which your internal resolvers are also authoritative for your private zones.
Use zone types primary or secondary

A resolver that is authoritative (primary or secondary) for a zone will always respond directly from those, irrespective of what may be in cache that could conflict and/or cause dnssec-validation to fail.

  • Delegate your private zones from your registered/public domains. You do not also need to have your internal nameservers externally accessible.
Add the delegation NS RRset for your private zones to their parent domain (i.e. your own registered domain)

If the private zones are not served authoritatively by your resolvers, then it is important that those resolvers do not accidentally 'learn' that the the private zones names don't exist. This can happen if they have not been delegated from their parent, which in turn can cause DNSSEC validation failures. Additionally the synth-from-dnssec optimisation option may immediately synthesise NXDOMAINs for names within undelegated private namespace. Using properly delegated private/internal zones prevents this mischance.

  • Be aware that names in private domains that have been obtained via forward, stub and static-stub zone directives will be eligible for validation on DNSSEC-validating resolvers..
Zone types forward, stub and static-stub do not make your server authoritative for any zones so defined

BIND configuration allows for global, per-view and per-zone forwarding. For convenience, we use the zone type forward for adding per-zone forwarding directives. However, these per-zone forwarding instructions do not create a 'zone' in BIND. Similarly, static-stub and stub zones are not authoritative zones, although these two zone types do create entries in BIND's internal zone table. For the purposes of whether or not to perform DNSSEC-validation, they are considered non-authoritative. Therefore, if dnssec-validation is enabled and working, BIND will attempt to validate content that has been obtained and added to its cache using using the zone types listed above.

NOTE: names in zones that have been delegated from zones in the public Internet will validate as there is a path upwards to the root. Names in private, orphaned zones will fail validation because no such path exists.

  • Properly delegated private zones don't need validate-except
Do you really need validate-except?

If you've followed all of the advice above for your private/internal-only namespace, then even if your resolvers are performing DNSSEC validation, you shouldn't need to create (or add them to) a list of exceptions.

Considerations when upgrading your version of BIND

Option synth-from-dnssec is enabled by default in BIND 9.18.0 and newer.

This may break resolution of names that exist in zones that are using unallocated or unowned Internet name space. NXDOMAIN will be locally generated and added to cache on DNSSEC validating resolvers if the synth-from-dnssec optimisation option asserts that a higher level name doesn't exist. No further lookups will be attempted, and depending on the client query being processed, the query response to the client will be NXDOMAIN or SERVFAIL

The default for option dnssec-validation changes from yes to auto in BIND 9.16.0 and newer

BIND resolvers that didn't have dnssec-validation explicitly disabled (no) in named.conf may become DNSSEC validating when upgraded from BIND 9.11 to BIND 9.16. For poorly-chosen or poorly-configured internal private domains, this can cause resolution failures.

RFC 8020 was not supported by BIND at the time of writing this article - 16 June 2022

For those not using DNSSEC-validation, internal-only domains can be configured and resolved, despite higher level domains not having any delegation records for them in their zones. But this works solely because BIND does not (yet) support RFC 8020 "NXDOMAIN: There Really Is Nothing Underneath": https://datatracker.ietf.org/doc/html/rfc8020

Most BIND resolver configurations that enable resolution of private names under domains that do not exist in the Internet name space will work, despite information to the contrary that is added to cache. If you are using private domains, we recommend reviewing BIND release notes and testing your configuration when upgrading because support for RFC8020 may be added to BIND in future releases.

Workarounds

This section exists to provide interim advice for those whose configurations are currently imperfect, and who need to implement short-term workarounds until they're able to do things properly...

The DNSSEC validation situation for private namespace zones can be quite complex ...

DNSSEC validation requires a chain of trust that can be verified, between the RRset that has been received in a query response, and the DNSSEC trust anchors configured on the resolver, which are usually just the Internet root, but others can also be specified. What you need to do may depend on whether or not your public zone is DNSSEC-signed, and whether or not you have delegated your private zone from your public zone, or perhaps are instead using views. But the chances are that listing your internal-only zones within option validate-except will prevent resolution failures due to DNSSEC validation.

You may need to temporarily disable the named.conf option synth-from-dnssec if you recently upgraded to BIND 9.18.0 or newer and have just started to experience problems

If you have enabled DNSSEC validation on your resolver, are using private internal-only name space, and one of the apparent higher level zones asserts using DNSSEC-signed RRs that the private space cannot exist, then you will need to disable synthesis of NXDOMAINs to prevent resolution failures. This is because this optimisation option is automatically enabled from BIND 9.18.0 and newer. You will need to add this option to your named.conf and then review how you are using private name space in your organisation:

synth-from-dnssec no;

For specific advice please see our community mailing list:
https://lists.isc.org/mailman/listinfo/bind-users
Private advice and support is also available to our Subscribers:
https://www.isc.org/support/

What's Next

Cookie consent

We use our own and third-party cookies to understand how you interact with our Knowledgebase. This helps us show you more relevant content and ads based on your browsing and navigation history.