6 Replies Latest reply: Oct 3, 2012 4:10 PM by TAA IT
TAA IT Level 1 Level 1 (0 points)

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 'www.ourcompany.com.au' 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)
  • 1. Re: DNS settings for virtual host 10.6 server
    MrHoffman Level 6 Level 6 (12,470 points)

    FWIW, both mycompany.com.au and ourcompany.com.au are real and registered domains; I'll presume they're not the domains you're migrating from or to.  Accordingly, I'll use example.org for your old stuff, and example.com 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 example.org domain inside your network.  That will have (technical) advantages.  (And no, potentially peeving the marketing folks that came up with the example.com 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 www.example.com), and all previous names (including www.example.org) will have CNAME entries.

     

    Internally (and here's why having a different domain inside is handy) use one of the old names; use example.org, 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 example.com hosts and go "duh, lemme ask somebody else for that", and that somebody else is the (public) DNS server your external DNS services for example.com 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 www.example.com domain, and also authoritative for the old www.example.org 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 example.com 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.

  • 2. Re: DNS settings for virtual host 10.6 server
    TAA IT Level 1 Level 1 (0 points)

    Mr. Hoffman,

     

    Than you very much for your reply - unfortunately, despite studying and testing your advice (incl. wesbite) we seem to not get much further.

     

    Please find our comments inserted below...

    MrHoffman wrote:

     

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

    Correct we are not using my bad example domains.

    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 www.example.com), and all previous names (including www.example.org) will have CNAME entries.

    To clarify do you mean the following: internally we should not have more than one A record for each host... i.e. one for example.org and one for example.com and presumably any other subdomains should be CNAME records?

     

    2. externally we should change the A record for www.example.org to a CNAME record and create a new A record for www.example.com;

    Internally (and here's why having a different domain inside is handy) use one of the old names; use example.org, 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 example.com hosts and go "duh, lemme ask somebody else for that", and that somebody else is the (public) DNS server your external DNS services for example.com hosts.

    Exactly what we had initially done - basically we (naively) thought we could get away with only relying on external DNS translations... however that resulted in mail clients on our LAN loosing their connection every 5-10 minutes, thus we decided to setup another primary DNS zone which fixed that problem but created the other.

     

    Please also note we have created a subdomain admin.example.com which properly resolves to the CMS backend - btw. from within this backend you can then preview the any page on the regular website with their non www. URLs.

     

    Since the current setup resolves to the correct IP address I wonder if it could be a problem with the .htaccess rewrite rules the web developer has setup to remove the www. ... or is this too far fetched?

    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 www.example.com domain, and also authoritative for the old www.example.org 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.

    Safari & Firefox present with 'Server not found' errors.

     

    So we are still stuck thus any further advice would be much appreciated.

  • 3. Re: DNS settings for virtual host 10.6 server
    MrHoffman Level 6 Level 6 (12,470 points)

    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.

  • 4. Re: DNS settings for virtual host 10.6 server
    TAA IT Level 1 Level 1 (0 points)

    so here is what has happened...

     

    basically our problem was due to a redirect the webdesigners had put in place... so the DNS was working fine - except some duplicate entires in named.conf, caused by ServerAdmin not cleaning up behind itself properly.

     

    thanks very much for your help - we thought we were going crazy for a short while.

  • 5. Re: DNS settings for virtual host 10.6 server
    MrHoffman Level 6 Level 6 (12,470 points)

    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/publicView.conf.apple";

     

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

  • 6. Re: DNS settings for virtual host 10.6 server
    TAA IT Level 1 Level 1 (0 points)

    Very sorry for the confusion - we were rather stressed out at the time... 

     

    @MrHoffman: you are correct the duplicate entries causing us grief were obviously not in named.conf but in /etc/dns/publicView.conf.apple

     

    Nobody would have added anything outside Server Admin, i suspect the problem might have been caused by adding end removing entries from within Server Admin without stopping DNS...?

     

    Either way it is now all back to normal and we know which files to backup before our next DNS changes - thank you very much for your help.