Err/TO getting serial#

[Barry Margolin]

In article <a3rqcs$auc at pub3.rc.vix.com>, Albert Meyer <dont at spam.me> wrote:
>I'm doing backup DNS for a client of ours and my server is presenting the
>following error:
>
>Feb  6 10:03:23 ns named[6184]: Err/TO getting serial# for "bybaxter.com"
>
>Usually this means a bad SN, or a typo in the zone, or something like that,
>and I think it usually means the zone isn't being transferred, but my
>secondary ns.realtime.net believes that it is authoritative on the domain,

Either it is authoritative or it isn't, it's not a matter of faith.  You do
a dig and check whether the "aa" (Authoritative Answer) flag is set.

>and changes made on the primary are propagated to the secondary. The client

There could be a firewall blocking UDP queries from the slave to the
master, or replies from the master to the slave.  If the changes are
propagating, it's probably because when UDP times out, named-xfer tries
again using TCP, and this is presumably succeeding.

>thinks it's because he's running BIND 9 and I'm running 8, and he thinks
>that BIND 8 would like the $TTL statement to be at the bottom of the file
>rather than the top. I have the 3rd edition of DNS and BIND but it doesn't
>cover BIND 9 and doesn't seem to say much about where BIND 8 expects the
>$TTL statement to be. Is my client correct about the location of the $TTL
>statement, or do I need to keep looking for a typo in his config file?

The $TTL statement should be at the top.  It's like $ORIGIN -- it affects
all the records from that point in the file until the next $TTL statement.

You could put it at the bottom of the file, but then you'll have to put
explicit TTLs on all the records in the file.  $TTL isn't required, it's
just the way to specify the default TTL for records that don't have one.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.