[svlug] BIND9 on EC2

Rick Moen rick at svlug.org
Fri Nov 28 01:22:15 PST 2014

Scott wrote:

> My FQDN host has the following options:
> ns1.default-setting.com
> ns2.default-setting.com
> I want to change this to:
> ns1.sldubois.org
> ns2.default-setting.com (as fallback)

1.  Scott, I read exactly that far, and had difficulty ignoring that bit and
reading onward, because I really had no idea what your phrase 'the following
options' means in this context -- and suspect that understanding the quoted
passage is going to be useful in correctly understanding your question.

One _guess_ is that you're talking about a setting in the administrative
settings for your EC2 host, but have no easy way of knowing what 'options'
you are speaking of.

Alternatively, it's possible that where you say 'My FQDN host has', you mean 
'my domain's record at my domain registrar has', and that by 'options' you
mean 'authoritative nameservers'.

The latter seems an odder interpretation of your wording, but would better
fit your subsequent question.  Please clarify.

2.  The remainder of your posting suggests you wish this nameserver host to
do (at minimum) authoritative DNS, for domain sldubois.org and possibly
other domains, and in fact to be the DNS master for sldubois.org.  You _may_
(or may not) also need the nameserver host to do recursive DNS.  If it does
_not_ need to recursive DNS, then I would urge you to switch to something
better than BIND9.  One extremely good authoritative-only DNS server package
is NSD.

If you indeed need the EC2 host to furnish both authoritative and recursive
DNS, then it is still possible to do so using better software than BIND9,
but we'd need to have a longer discussion.

3.  I notice that there is no such domain as default-setting.com, i.e., you 
substituted a generic fake domain name for whatever the real domain is.  
Over the years, those of us wha answer nameservice questions notice that 
people doing that _often_ (not always, but often) accidentally obscure data
vital to getting correct help.

Please consider re-posting your question with real data.

Quoting your draft zonefile:

> @       IN      SOA     ns1.sldubois.org. sdubois.linux.com. (

Do I guess correctly that hostname 'ns1.sldubois.org' will be mapped to the
new nameserver host on EC2?

>                             007         ; Serial

Unless you have a very compelling reason not to, you really should follow
the traditional YYYYMMDDnn format for zonefile S/Ns, where the first of 100
S/Ns used this date (Friday the 28th) would be 2014112800 , and those would
potentially proceed up to 2014112899.  (If your zone ever needs more than
100 edits in a day, you have a truly unusual use case.)

> @       IN      NS      ns1.sldubois.org.
> ns1     IN      A ; IP for Apache instance

OK, good, the nameserver has a definition in-domain.

And now, we get to the linneus bottomus:

> Do I need to specify ns2.default-setting.com in my zone file under
> ns1.sldubois.org. ?
> OR
> Do I really need to create a slave to my master DNS or can I just use
> the slave assigned by my host?

OK, I _think_ I've just guessed the situation.  You want to have DNS
replication of zone sldubois.org from zone master ns1.sldubois.org -- your
EC2 host -- to at least one other authoritative nameserver.  This is a good
thing.  It probably means you've been reading up, and (correctly) understand
that you need minimum two.  In point of fact, the RFCs actually recommend
minimum three authoritative nameservers for a domain, maximum seven.

And your big problem is:  You haven't yet arranged for any nameserver to do
slave nameservice for zone sldubois.org.  That needs to be your next step.  
You need to get someone who operates authoritative nameservice to say 'Sure,
I'll be glad to secondary your domain.  Where's the master?'  You'll tell
him/her 'Thanks, friend.  Please point your secondary at ns1.sldubois.org,
which is at IP address'  Your friend will eventually verify to
you that he/she has been able to AXFR down the zone, or you can see the
transfer in your nameserver host's logfiles, or you could just use dig to
query his/her nameserver directly for the SOA record of DNS zone
sldubois.org and make sure the returned S/N value matches the master's.

You see, it's not enough to just identify two nameservers and say to
yourself 'I'd like these two to serve up my domain.'  You have to make
inter-human arrangements for the one to autotransfer zone information from
the other - that being the slave/master bit.  

(It need not be a friend.  Maybe, when you are talking about
'ns2.default-setting.com', you mean a nameserver run by some firm obliged to
do secondary DNS for you because you're a customer.)

Once you have verified (using dig) that _both_ your and the other person's
authoritative nameservice are returning correct information, then and only
then, you do these two things:

1.  Edit the NS records in your in-zone records on your master nameserver to
list both of them.

2.  Edit the domain records for domain sldubois.org (at your domain
registar) to list both nameservers - and to delete any others listed there.

Step #2 is the step that makes the two nameservers _authoritative_ -- that
causes public traffic to be directed to them.  It is important that your DNS
be correct and verified before you repoint DNS to your authoritative servers
in that step.

And, as mentioned, you really ought to have at least three, not just two.

I note that the current domain record at your registrar has: 

$ whois sldubois.org 
Domain ID: D174324139-LROR
Creation Date: 2014-10-27T15:07:16Z
Updated Date: 2014-11-27T04:32:04Z
Registry Expiry Date: 2016-10-27T15:07:16Z
Sponsoring Registrar:Domain.com, LLC (R1915-LROR)

So, as usual, the registrar has used nameservers to point your domain to a 
'parking' page.

BTW, I love registrar Domain.com's 'Top Five Reasons for Saying No to Super
Bowl Ads'.  https://www.domain.com/domaincom/about/press/2009/01_30_2009.bml
Now, _that_ has class.  Take that, NoDaddy.

A few pointers about your zonefile SOA record:

>                          604800         ; Refresh

RFC1912 recommends 1200 to 43200 seconds, low (1200) if the data is
volatile or 43200 (12 hours) if it's not. 

>                           86400         ; Retry

Typical values would be 180 (3 minutes) to 900 (15 minutes) or higher,
basically some fraction of the refresh interval (as it's the amount of time
your secondary/slave nameservers will wait to contact the master nameserver
again if the last attempt failed).

>                         2419200         ; Expire

RFC1912 recommendation is 120960 to 2419200 (2-4 weeks).  You're right at
the top end, which is OK.

More information about the svlug mailing list