Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have split DNS set up for our domain, which causes internal clients to resolve different DNS records from external clients.

As it is right now, the two zones are managed completely separately. For records that differ between internal and external, it's no problem, but for everything else, all of the records have to be duplicated in both places. Most CNAME records, MX records, SPF records, and some A records all need to be entered and maintained in both places.

While this isn't inherently unacceptable, data duplication like this is less than ideal from a design perspective. I feel like ideally, the internal nameserver would simply forward results from the external nameserver, but allow for us to override or add additional records. While it looks like I could use a designated forwarder (like dnsmasq) to do something like this, the flat file configuration would make it difficult to sell the idea to the rest of the team.

Aside from that, the best solution I've been able to come up with consists of PowerDNS with a MySQL backend and web interface. This makes it fairly easy to add a zone and root A record for each sub-domain we'd like to override (e.g. www.example.com), which means other records on the root domain (e.g. example.com) will still be forwarded from the external nameserver.

That still seems like I'm straying kind of far from the norm for something that's supposedly very common, right? Is there a cleaner way to manage Split DNS without maintaining duplicate records? Or is there something I'm missing?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

In a network where one of the authoritative nameservers sits on the border of the internal network, I use bind views and the $INCLUDE directive:

mydomain-global.zone:

@ IN SOA ns1 hostmaster ( 12345; 1D; 2M; 1M; 3H )
  IN NS ns1
  IN NS ns2

  IN MX 10 mail

  www               IN A 1.2.3.4
  other-public-host IN A 1.2.3.5

mydomain-internal.zone:

$INCLUDE mydomain-global.zone

an-internal-record IN A   10.20.30.40
_kerberos          IN SRV 0 0 88 dir

The zones are chosen based on view definitions:

view "internal" {
  match-clients { 10.0.0.0/8; };
  zone "mydomain" {
    type master;
    file "mydomain-internal.zone";
  };
  include "named.conf.internalzones";
}

view "global" {
  match-clients { any; };
    zone "mydomain" {
    type master;
    file "mydomain-global.zone";
  };

To be able to assign a record different targets for internal/external queries, add two further zone fragments and $INCLUDE at the bottom of mydomain-(internal|global).zone.

share|improve this answer
    
That's an excellent idea. I hadn't thought of doing it that way, but it's conceptually exactly what I'm looking for. Our external DNS will soon be hosted separately, though, so I don't think this particular method would work in our case. –  Moduspwnens Oct 27 '11 at 23:06
    
If your hoster supports this, you could still run your own resolver and use it as a (hidden) master server. IMO it's a really convenient way to manage one's zones. –  al. Oct 28 '11 at 12:21

The fact that zones must have a single authoritative point of administration is inherent in the way DNS works; there's very little chance of this changing any time soon.

The best (and official) way to automate this is with ddns and nsupdate. DDNS has a defined format and can be secured, and scripted in any way you need.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.