[svlug] BIND9 on EC2

Rick Moen rick at svlug.org
Sun Nov 30 00:34:33 PST 2014

Scott wrote:

> Please clarify.
> Sorry, I tried to convey in words what I'm looking at for my only
> options from my host.

What?  I have no idea what the above is trying to say.

> A can only access nameserver settings; no records.


I'm sure all that is really clear in your mind.  Please remember that we are
not seeing what you're seeing.  If you're attempting to describe something
important to you question (and I'm not convinced you were), then actual
description has to arrive here, else we're in the dark.

Let's back up.  I expressed confusion about what problem you're trying to
solve, because of some introductory sentences I really couldn't parse.

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

I was (and remain) literally stumped about what the sentence 'My FQDN host
has the following options' is trying to say.  No comprende, senor.  Je ne
comprend pas.  Jeg forstar ikke.

That was precisely the thing about which I said 'Please clarify'.  And you

Also, I pointed out that your framing your problem in terms of existing
nameservers in domain default-setting.com, when no such domain exists, is
probably a bad idea, and therefore suggested you re-post your question with
real data, i.e., with whatever the real domain name is instead of the fake
default-setting.com placeholder name.  You haven't done that, either - maybe
because my suggestion wasn't clear enough?  (If so, I'm sorry.)

By 're-posting your question with real data', I did _not_ mean 'Please
bulk-post your BIND configuration files and zonefiles', though thank you for
taking the trouble.

>> 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.
> I ran:
> sudo named-checkconf
> and
> sudo named-checkzone
> They're ok. EC2 doesn't allow pings or netstat so I'm short on anything
> else other than dig.

Ummmm.... that's nice, but dig is precisely and solely what you need for
what I said in the quoted paragraph.  Also, it's not obvious to me what the
relevance is of netstat or ping, let alone whether Amazon EC2 'allows' them.
The way you test whether published DNS is correct or not is to query it
directly and look at the returned results.  The tool you use to query it is
dig.  The copy of dig you use may be anywhere at all, as long as it has
network connectivity to the relevant nameservers.

Let's start over with a brief high-level overview.  You own a domain and
wish to publish authoritative DNS for it.[1]  Apparently, you've configuraed 
a master nameserver for the domain on an EC2 host.  You should test its
functionality by querying it (using dig) for the SOA record of your domain.

You should then round up at least one (prefereably at least two)
authoritative nameservers whose administratiors are willing to secondary
your domain.  Configure zone-transfer ACLs on the master nameserver to
permit AXFR/IXFR (zone transfer queries) by the IP addresses of those one or
two slave nameservers.

Get the administrators of those slave namservers to get secondary
nameservice going for your domain.  When it's believed/claimed that they've
accomplished this for you, test the outcome by running a query against each
such slave nameserver, using dig, asking once again for the SOA record of
your domain.  Verify that they are returning the same zone S/N (a subfield
of the SOA record) as wat returned when you queried the master nameserver.

Once all relevant nameservers have been thus verified to be giving correct
results, make sure all of the nameservers have in-zone 'NS' lines in the
zonefile.  Then adjust the nameserver list at the domain registrar to exactly
match.  This last step is (as i said) what makes the namservers
authoritative for your domain.  It results in editing the NS records in the
domain's parent zone.

I forgot to mention, the first time, that the roster of NS lines in the
master namserver's zonefile (the in-zone list) must always be changed in
lockstep with the domain's namserver list at your registrar.  The in-zone 
set of NS lines should be checked to ensure that they always match the NS
records in the domain's parent zone.

There probably are parts of the above that you don't yet understand.  Please
ask about the parts that are unclear.

[1] You never answered my question about whether your nameservers also need
to do recursive DNS.  Once again, if the answer's no, then you really ought
to use better software than BIND9, such as NSD.

More information about the svlug mailing list