Decisions about DNS on IPv6

Question

We are rolling out IPv6, and I'm thinking about our DNS strategy. This is not a technical question--it's more of a "best practice" question.

We have Active Directory internally, and the domain controllers handle both the authoritative DNS for our "internal" zones (e.g., domain.local, 16.172.in-addr.arpa) as well as recursion for all the users. We have about 1200 users, so the 5 domain controllers easily handle DNS recursion, simply forwarding to Cisco Umbrella DNS for zones they're not authoritative for. We rely heavily on dynamic DNS, both for A and PTR records for internal hosts. For our public zones, we use DNS Made Easy.

Now that we're looking at IPv6, we would like to maintain the ability to use dynamic DNS internally, both for AAAA and PTR records. Since there's no need for NAT in IPv6, a given host will have the same address internally as it does externally. Is maintaining two separate databases for the ip6.arpa zone (an internal one and an external one) still what should be done? The alternative is to put a rule in my firewall that allows the public DNS servers to be a secondary for the ip6.arpa zone. I'm not talking about allowing the Internet at large to query my DCs directly--rather allow the DNS Made Easy transfer agent to keep a copy of it.

Doing this "gives away" all my internal DNS entries, but is that really so terrible?

As I'm typing this, I'm thinking that it probably would be best to just maintain two databases--one internal and one external, as I've always done in the past. What does the community think?

Answer 1

This is a best practices question with no real right answers, but these are the questions I would ask myself to arrive at the answer right for me.

Doing this "gives away" all my internal DNS entries, but is that really so terrible?

If your boss doesn't think it's terrible, and you don't think it's terrible, then you have your answer. IPv6 takes much longer to crawl than IPv4, but it can still be crawled. If you don't care whether a DNS lookup for 2001:db8::1 yields YourFinancialServer.Example.com and no one in your management chain seems to care either, you can manage all of your IPv6 reverse DNS with your edge facing DNS authority and call it a day.

Is maintaining two separate databases for the ip6.arpa zone (an internal one and an external one) still what should be done?

This is decided by the previous question. If it is what should be done, the next step is determining the logical separation of your privately routed networks.

• In an ideal world, your network team has cleanly carved out segments of IPv6 space that are not internet routable, which you can use to drive the design behind how you split up the reverse DNS between your authoritative servers. You can set up forwarders on your internally facing recursive servers to steer the reverse requests for privately routed V6 space to your internal authority, and let recursion send the rest of the requests to your internet facing authority as normal.
• In a less than ideal world, your IPv6 space is in a state of design flux with no rules of clear division between public and private. In the worst case your addresses are piece mealed between public and private by a firewall without being divided into cleanly purposed networks. This makes the forwarding rules for your recursive servers difficult (nearing impossible) to manage, and you might have to manage two completely different versions of the same authoritative zones between public and private. This will get inconsistent very quickly without clean automation to remove records as your devices are retired.