Skip navigation

DNS settings for virtual host 10.6 server

1026 Views 6 Replies Latest reply: Oct 3, 2012 4:10 PM by TAA IT RSS
TAA IT Calculating status...
Currently Being Moderated
Aug 27, 2012 7:04 PM

We have just gone through a rebranding exercise, i.e. the company name has changed from 'mycompany' to our 'ourcompany'.

For various reasons we have decided to not rename our complete setup, but rather add a virtual host for our mail server including a second primary DNS zone for the new domain 'ourcompany'.

We are hosting our website externally, however since we added the second primary DNS zone incl. an A record (www) pointing to our external website hosts IP for 'ourcompany', workstations on our LAN can no longer access the website.

Running DIG for '' results in the correct A record IP address being shown, but it is still not showing in any browser – we also made sure we emptied our caches.

Although we thought this should work relatively easily, we are now totally confused as to the additional primary zones general settings... currently we allow zone transfer and provide an entry in the nameserver section.

Any ideas as to what might be going on here would be greatly appreciated.

Apple Mail, Mac OS X (10.6.8)
  • MrHoffman Level 6 Level 6 (11,720 points)
    Currently Being Moderated
    Aug 28, 2012 8:28 AM (in response to TAA IT)

    FWIW, both and are real and registered domains; I'll presume they're not the domains you're migrating from or to.  Accordingly, I'll use for your old stuff, and for your new stuff; the example domains are RFC-reserved for this usage.


    First off, if at all possible, ignore the rebranding and use the old domain inside your network.  That will have (technical) advantages.  (And no, potentially peeving the marketing folks that came up with the rebranding is not considered one of those advantages.)


    Each host should have one A record (and one AAAA record, if you have IPv6 active), and one of the more common errors in these migrations is setting up an A record for each new domain that might arrive; each host has one A (and possibly one AAAA) record, and that's the canonical name for that host.  Externally, that'll probably be the latest name in any sequence (such as, and all previous names (including will have CNAME entries.


    Internally (and here's why having a different domain inside is handy) use one of the old names; use, for instance.  This means you can use the public DNS services for the external web sites and resources; your internal DNS servers receive the requests for hosts and go "duh, lemme ask somebody else for that", and that somebody else is the (public) DNS server your external DNS services for hosts.


    The usual trigger for not reaching the external A (or AAAA) records is either a stale cache on the particular client (for translations inside the Time To Live (TTL) values for the old DNS translations, or pending a local cache flush on each client), or (and this is more common) confusion over authoritative DNS servers; you have your internal DNS configured as authoritative for the new domain, and also authoritative for the old domain, and your external DNS is also authoritative for (probably) both domains.  Internal requests get as far as the internal server, and get an authoritative translation (possibly being "no such host"), and don't go any further.


    If your internal servers are authoritative for hosts, then you'll need to duplicate the external IP addresses in your internal DNS; you'll basically have to mirror parts (or all) of your external DNS translations.  (This part of is why I'm fond of separate DNS domains (or a DNS domain and subdomain) for internal and external hosts; it means I need only have one copy of the IP translations, and I don't need to keep the internal DNS in sync with the external DNS.)


    The single A (and possibly one AAA) record stuff for the host tends to be particularly enforced by other mail servers too, so if you're hosting your mail on these same servers, then the DNS translations for that mail server needs to be correct.  That is, one A (and possibly one AAAA) record for the host, which means the forward and reverse translations will match.  If you have more than one A (or AAAA) record, the names won't match, and other mail servers will assume your mail server is a spam engine.


    In general, you should not be allowing zone transfers from your internal DNS servers originating from outside of your network.


    Here's a long-form write-up on configuring DNS on OS X Server.

  • MrHoffman Level 6 Level 6 (11,720 points)
    Currently Being Moderated
    Sep 3, 2012 9:51 AM (in response to TAA IT)

    If that long-form article doesn't help - and you really want to learn the details - then acquire and read through Cricket Liu's DNS and BIND book.  Or get somebody in to help with this.


    1: One A record per host, and (if you're using IPv6) one AAAA record per host.  No more.


    2: if you need a second or third or subsequent name for a host, use a CNAME for those.


    I don't generally test with HTTP initially, and that's because rewrite rules and some gateway-firewalls can effect that.  External DNS can work, if your gateway-firewall can "reflect" traffic back through the NAT.

  • MrHoffman Level 6 Level 6 (11,720 points)
    Currently Being Moderated
    Sep 9, 2012 6:43 AM (in response to TAA IT)

    There aren't usually host entries in named.conf.  Not in a typical config.


    The entries are loaded via a DNS view, via this section of the /etc/named.conf file:


    // Public view read by Server Admin


    include "/etc/dns/";


    Maybe somebody (with the root password, obviously) added those hosts manually, and went around Server Admin?


More Like This

  • Retrieving data ...

Bookmarked By (0)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.