3

Like most organizations, we maintain various split domains for a verity of reasons. Due to what we do, we frequently use the same name in different instances of the domain to point to different versions of things and this is a requirement for us to maintain. What has come up more recently, is that this is becoming a barrier for access between the splits. In the simplest case, we want to to be able to provide internal users access to example.com, which exists both internally and externally.

We'd like to be able to access the internal version as example.com and the external version as ext.example.com. We have access to transfer the external zone to our internal BIND server from an external provider.

I've configured a view in the BIND server with none for client-matches so that all it does is preform the zone transfer for the zone. I've then tried to use the same file in the "internal" view as a master under the name ext.mypna.com. When this is done, all of the records are invalidated by bind as "out-of-zone data".

Sifting through the zone file on the internal server vs the external provider, i found that the zone transfered was marked up with "$ORGIN external.com" and "external.com IN SOA". Reverting these to @ allows BIND to use the zone file again, but it just gets trashed after an update.

Is there a standard way to implement this kind of architecture?

Xarses
  • 331
  • 1
  • 5

1 Answers1

2

If I understand you correctly, you run separate independent DNS servers, and each set (I really do hope that you have more than one instance per subnet or network location) of servers contains different uncoordinated information. This is unsustainable. I actually inherited something like this a few years back, and it was our largest source of annoyance, bugs, and outages until we tore it out and built a completely new DNS setup.

Instead of maintaining multiple masters responsible for their own zones, create a single master holding all zones, with multiple views. Set up slaves everywhere they would make sense (another one in the same location, more in other physical locations, put them physically and logically close to where your users are). Replicate all views to all slaves, or only some views if you know that some of your slaves won't serve requests from certain networks. Once this is in place, all your servers will have exactly the same data. You'll only have to ensure that your views are defined correctly, and all clients will get exactly the results they need, regardless of the server they use.

A couple of hints on implementation:

  1. Use $INCLUDE in your zone files so that individual view files only have the entries that are different among different views (for example, your ext.example.com will probably resolve to the same IP regardless of the view, so it'll go into the common include file, while example.com will be specific to every view file).

  2. For replication, you may want to give each DNS server several IP addresses - one per view. This is done, because views use client IP address to determine what to serve - and this also includes XFER requests coming from slaves. So, you have to 1) for every slave, add one and only one of its IP addresses into each view; 2) on the slaves, use transfer-source directive in named.conf so that the XFERs originate on the correct IP. Here's the same idea explained in more detail: http://coding.infoconex.com/post/2010/04/26/Bind-DNS-e28093-Configuring-multiple-views-on-primary-and-secondary-DNS-servers.aspx

Also, see if you can get help from your network admins. In some situations, DNS rewrite can make separate views unnecessary.

Max Alginin
  • 3,284
  • 15
  • 11
  • We are already doing this with the environments, but the issue is the need to allow users to access to multiple versions of the same domain, **without** requiring them to change DNS servers. There is little that includes will help with as there are very few overlapping records but it's a good hit for that issue. Also, as stated, the external zone is hosted by a DNS provider, and we cant bring it in-house. – Xarses Feb 25 '12 at 21:18
  • Well, actually you don't have what I described, because you have to juggle your internal servers and the hosted ones. Two suggestions: 1. Forget the true SOA. Set your DNS to own the zone and serve it internally. You'll just have to maintain it in two places. 2. Rely on firewall DNS rewrite. Make it so that during normal operation your clients use internal DNS servers that connect outside through the same firewall that NAT ext.example.com to inside, but during splits the servers that use a different route would kick in. The former will get DNS response rewritten to internal, the latter won't. – Max Alginin Feb 26 '12 at 04:48