secondary DNS server configuration

Posted on 2000-02-23
Medium Priority
Last Modified: 2013-12-16
I am having some problems getting my secondary DNS server configured properly.  Both the primary and secondary DNS servers are running RedHat Linux 6.1.  The primary DNS server appears to be running fine, but the secondary DNS server will not do a zone transfer of the domain's look-up file.  It transfers the reverse look-up file just fine, though.  The error I get is:

named[2044]: Err/TO getting serial# for "DOMAIN.com"
named-xfer[2069]: [xxx.xxx.xxx.xxx] not authoritative for DOMAIN.com, SOA query got rcode 0, aa 0, ancount 1, aucount 0

again, the zone transfer of the reverse table happens correctly.
Question by:brian1
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 4
  • 3
LVL 40

Accepted Solution

jlevie earned 200 total points
ID: 2553186
Have you tried dig on the domain (e.g., dig dom.com)? Does it show a valid SOA? Are both the primary and the secondary listed in NS records in the primary's zone file?

There's a very useful tool for checking the sanity of a DNS configuration. It's not perfect, but it catches an awful lot of problems with namserver files. You can get it from ftp://ftp.ee.lbl.gov, usually as nslint.tar.Z. Fetch it , compile it, and turn it loose on your primary server and see if it likes the files.

Expert Comment

ID: 2553721
1. Check your SOA record (serial line)on primary and secondary servers.
2. Check your NS records on primary and secondary servers (both primary and secondary servers must be listed on both DNS servers NS records).

Serial is number in SOA record which inform secondary server about modification of zone info and zone transfer need. Must be updated after any zone modifications.

For example

@ IN SOA ... (
               2000022400; Serial
2000 - year
02 - month
24 - day
00 - number of modification

Author Comment

ID: 2555751
The dig DOMAIN.com command appears to return appropriate info.  I'm not sure what to expect, but it returns info on the DNS server.

I did not have the secondary nameserver listed in the zone file, only the primary one.  I now have both, but am receiving the same error.

My serial line had a date from two days ago, but when I added the NS line for the secondary DNS server I changed it to '2000022400'.

AGB, I am sure it was an over site, but I don't have the zone file on the secondary DNS server, so I can't add the NS record to it.  I do now have an NS record for my secondary DNS server in the SOA entry.

Here is the first part of my zone file:

 @               IN      SOA     penguin.DOMAIN.com.     root.DOMAIN.com. (
                                2000022400 ; Serial
                                8H       ; Refresh
                                2H       ; Retry
                                1W       ; Expire
                                1D )     ; Minimum
                        NS      penguin.DOMAIN.com.
                        NS      tweety.DOMAIN.com.
localhost               A

The 'NS tweety...' line was just added from your suggestion.

Again the error I am getting:
tweety named[3178]: Err/TO getting serial# for "DOMAIN.com"
tweety named-xfer[3182]: [XXX.XXX.XXX.XXX] not authoritative for DOMAIN.com, SOA query got rcode 0, aa 0, ancount 1, aucount 0

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Expert Comment

ID: 2555798
After Minimum not set ;

@  NS penguin.DOMAIN.com.
@  NS tweety.DOMAIN.com.

Sign @ inform named what NS record relate to your domain.


DOMAIN.com.  NS penguin.DOMAIN.com.

Please check what in primary set correct NS records


Author Comment

ID: 2555843
OK, I tried the NS lines with leading '@' and 'DOMAIN.com' entries, and no difference.  I believe if left blank it assumes the domain the file is defining.

I appreciate your help, but am still getting the same errors, and the secondary server will not copy(zone tranfer) the zone file over.  It does copy the reverse zone file successfully.

Any more suggestions?
LVL 40

Expert Comment

ID: 2555882
Have you tried getting nslint and seeing if it can spot any errors in the primary servers files?

Expert Comment

ID: 2556898
1. Carefully verify that you set needed dots (DOMAIN.com. <-, for example).

2. In primary server define correct A-records for your NS servers.

3. Check up that Serial number on primary larger than Serial number on secondary DNS.

Author Comment

ID: 2566550
Turns out jlevie had the correct answer early on with his nslint suggestion.  I didn't look into that very quickly because the primary server was working correctly and I didn't realize how sensitive the secondary server was going to be to syntax errors.  I had lots of errors because I am moving things over from an older SUN that was using bind4.

An example of the kind of error I had was that the HINFO lines did not have their info quoted.  Not sure if bind4 didn't care, of if the SUN implementation was less strict on things, but bind8 and Linux really didn't like it(at least on the secondary server).
LVL 40

Expert Comment

ID: 2566975
I thought you'd dismissed my suggestion about nslint, or were never going to get around to trying it. It really does a bang-up job of ferretting out errors in a DNS config. And yes the old bind that Sun used to ship (bind 8 comes on Solaris 2.6 and later) was unfortunately too tolerant of errors, which made diagnosing problems a real trip unless you could quote chapter & verse of "DNS and Bind".

Is everything fixed now, or do you still have any problems/questions?

Author Comment

ID: 2567142
nislint was a good suggestion.  Everything is fixed now.  My problem was that the zone file was working properly(names were resolving), but  the secondary server refused to do a zone transfer of the files.  The error on the secondary server told me that the primary server did not have authority for the zone.

Looks like just because the zone file is OK(enough so that it works) the secondary servers will refuse to take it if it contains errors.

Want to submit nslint as a solution?  You originally suggested it as a comment.

Author Comment

ID: 2567374
Yep, nslint showed errors, that when fixed allowed the zone file to transfer to the secondary server.
LVL 40

Expert Comment

ID: 2567394
How about selecting a comment as an answer and grading it, please. Otherwise I can submit a "proposed answer".

Author Comment

ID: 2569978
I did.  Didn't realize at first that I could select a comment as the answer.

Thanks again for the help

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you have a server on collocation with the super-fast CPU, that doesn't mean that you get it running at full power. Here is a preamble. When doing inventory of Linux servers, that I'm administering, I've found that some of them are running on l…
In part one, we reviewed the prerequisites required for installing SQL Server vNext. In this part we will explore how to install Microsoft's SQL Server on Ubuntu 16.04.
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial
Suggested Courses

719 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question