18

In light of the GoDaddy outage we updated our name server list for our domain to include an additional name server provider. The list looks something like this:

  1. ns61.domaincontrol.com
  2. ns54.domaincontrol.com
  3. ns1.dreamhost.com
  4. ns2.dreamhost.com

Both Godaddy and Dreamhost have zone entries to handle the A and MX records. The idea is that if one provider goes out the other will be a fall-back.

However, when I tested my config with http://www.intodns.com/ I am getting a warning about SOA serials not being agreed.

Have I misunderstood some fundamentals in name-server config? What can I do to prevent future problems?

1
  • Services such as intodns.com highlight issues such as the serial mismatch because it can tell you about errors in your configuration, such as DNS servers not being in sync. That does not however mean that this will necessarily be a problem for clients performing a lookup. The trick is learning what you can ignore and under a given set of circumstances. Commented Sep 12, 2012 at 11:53

2 Answers 2

15

The fact that the SOA serial numbers don't match makes perfect sense due to the fact that you're using different DNS providers. The SOA serial numbers between providers isn't going to match unless one provider supports zone transfers to the other, which isn't likely...but that's OK. The serial numbers don't have any bearing on name resolution for your domain, they have meaning only for the name servers hosting the zone, either at the same provider or amongst all of the name servers hosting the zone if zone transfers are allowed to all of them. What you need to make sure is that when you add, change or delete a record at one provider that you do the same at the other provider. The master/slave mechanism that keeps DNS records in sync at one provider isn't going to keep your records in sync at the other provider, you're going to have to manually do that yourself by updating the zone at each provider with the same records.

2
  • 1
    I see, so basically it's expected behaviour given that we're managing our zone records manually at each provider. I guess the next step is to look into automating the sync, however we don't plan on changing the zone records very often.
    – Simon
    Commented Sep 12, 2012 at 0:59
  • Yes, I would expect the serial numbers across providers not to match. You'll need to see if either provider supports third party zone transfers in order to avoid having to manage the DNS records manually across providers... but I wouldn't count on them supporting it.
    – joeqwerty
    Commented Sep 12, 2012 at 1:09
8

You sure can.

For example, where I work, we have 4 name servers, 2 hosted with one DNS host, one hosted by us, and the other one hosted by a second external DNS host.

The SOA (start of authority) serials not being agreed indicates that there's [most likely] a sync issue with your DNS - not all the name servers are serving up the same version of your DNS records. This may be an actual problem, or it may indicate that DNS hasn't fully propagated from your authoritative name server(s) to the rest.

Here's a quick KB I found from MS about the structure of an SOA record. Hopefully that will help clarify what's going on for you.

Serial number - The revision number of this zone file. Increment this number each time the zone file is changed. It is important to increment this value each time a change is made, so that the changes will be distributed to any secondary DNS servers.

2
  • I think there is a slight difference in some of the records, nothing that would impact the name resolving. I'll look at making them identical for completeness.
    – Simon
    Commented Sep 12, 2012 at 1:02
  • 2
    @Simon Well, as joeqwerty mentioned, that might not be possible. Our DNS hosts allow zone transfers, and I neglected to consider that yours might not. If yours don't, the "serial"/revision won't match between DNS hosts (which is expected, and nothing to be concerned about), and you just need to make sure the records are actually the same across all your nameservers. Commented Sep 12, 2012 at 3:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .