1

I am having what I feel will end up being a simple problem, however I am not seeing the obvious problem.

Here is an example flow first of all to get a better understanding of how things occur in order -- please note that this is infrastructure that is already in place and the order of operations needs to remain intact:

  1. Register domain IE GoDaddy
  2. Point domain at our nameserver
  3. Create nameserver record and reload Bind

Now .. Between step 1 and 2 we start seeing this (obviously because the domain is not in our system yet:

Jun 12 15:32:40 DNSSERVER named[25262]: client 230..xxx.xxx.xx#61333 (example.com): query (cache) 'example.com/SOA/IN' denied

Next I create the zone file /var/lib/bind/example.com.hosts:

$ttl 38400
example.com.                       IN          SOA      ns1.ourdnsserver.com. some.email.com. (
                            1494611262
                            10800
                            3600
                            604800
                            38400 )
example.com.                       IN       NS      ns1.ourdnsserver.com.
example.com.                       IN       A       40.xx.xx.xx
www.example.com.                   IN       A       40.xx.xx.xx
mail.example.com.                  IN       A       173.xx.xx.xx
webmail.example.com.               IN       A       173.xx.xx.xx
example.com.                       IN       MX      10 mx1.server.com.
example.com.                       IN       MX      20 mx2.server.com.

After this I insert the zone into the configuration /etc/bind/named.conf.local:

zone "example.com" {
     type master;
     file "/var/lib/bind/example.com.hosts";
     };

Then I issue a restart sudo service bind9 restart

After this, I still get the

Jun 12 15:32:40 DNSSERVER named[25262]: client 230..xxx.xxx.xx#61333 (example.com): query (cache) 'example.com/SOA/IN' denied

What I have to do to resolve this is edit my file /var/lib/bind/example.com.hosts -- Update the serial with a new unix timestap -- re-save and restart Bind. And viola, the notifiers get sent out that the zone was updated.

EDIT

Then I get the following in the log

8377:Jun 12 14:12:57 OURSND named[25262]: zone example.com/IN: sending notifies (serial 1494611231)

END EDIT

Here is the question, why don't the notifiers get sent out when I create the zone and restart Bind? Why do I have to go back in, edit, re-save and restart Bind for the zone to be seen as "updated"? I want this to happen the first time, every time. What am I not seeing?

5
  • Perhaps it is just censored in your example here, but you only seem to have one NS record in your zone? Who are these notifications supposed to be sent to? Do you have an NS record in your zone for every name server that notification are supposed to be sent to?
    – Zoredache
    Jun 12, 2017 at 21:44
  • We only have one domain server for now until this issue get ironed out .. Like I said it denies the site, even after zone creation, until you go in, update the serial, re-save and restart. Then you can see the notifies sent .. See edit ^^
    – Zak
    Jun 12, 2017 at 21:52
  • 1
    I see. I have never seen the symptoms you describe, but I usually work the other way around. I buy the zone, configure my name servers, and finally I update the delegation at the registrar. Are you sure there are no errors being reported by bind after that initial zone creation and restart?
    – Zoredache
    Jun 12, 2017 at 22:04
  • Something is definitely odd. My interpretation of the 'example.com/SOA/IN' denied message is that the server hasn't actually loaded the new zone definition. Not sending notifies is a symptom of that. Bumping the serial number would not fix that. It's possible that either the zone actually wasn't reloaded the first time, or there's a typo here that isn't being captured due to domain obfuscation.
    – Andrew B
    Jun 13, 2017 at 16:25
  • Sending notifies to who? If your domain has only one NS (not recommended but will technically work) it has no other nameserver to send notifies to! Jun 13, 2017 at 20:06

1 Answer 1

2

Think of the serial as a version number. You (re)start bind, it checks the version number on its data cache vs. version number in config (the serial). If the version is the same, why bother re-processing everything, and why waste network bandwidth telling secondary servers that you have zone(s) to transfer...

Always update your serial. Only rule is that it must go up. Using a unix time stamp is good, or a format like YYYYMMDDNN where NN is a revision number for that day (do you need to change it more than 99 times a day?).

The problem, as you have discovered, is remembering to update the serial when you edit the file. Use some template files, data files, and shell scripting to create a "build" process where you'd make your edits to the data, then tell it to regenerate the zone file(s) part of which would include putting out a new serial, or even go to a (way overkill) web based front end with a "service provider" control panel like ISPConfig where the data will all be in a sql database and the ispconfig software will create the zone file(s) automagically.

2
  • I think you are misinformed .. I use the unix time-stamp on zone file CREATION ... At this time the notifies don't get send out. THEN (it can be 1 hour or 5 days later) I go in and UPDATE the serial with a new unix timestamp .. and it then works ... How am I supposed to "update" a serial that never existed - If I were to follow your logic. What I am wondering, is why when I "create" the zone initially, with a NEW serial, it doesn't work ..
    – Zak
    Jun 13, 2017 at 0:14
  • @Zak - "What I am wondering, is why when I "create" the zone initially, with a NEW serial, it doesn't work " Ah... I misinterpreted the question! So sorry.
    – ivanivan
    Jun 13, 2017 at 0:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.