[svlug] BIND9 on EC2

[Rick Moen]

Scott wrote:

> That's why I "prefer" to ask you (or from this list) rather than dig up
> some strange, unknown, blog post off the web.

Yeah, FWIW, those pages whose URLs you cited were OK as far as they went, 
but didn't provide all you needed to know.  

> I'm used to looking at panels like below where I have access to A,
> CNAME, MX... when I didn't have that with this domain I was thinking
> WTF? Then it dawned on me that it was the first domain I had registered
> without having hosting services automatically attached. 

Context is important.  The WebUI page you were looking at was the _domain_ 
record.  So, it had only settings for the _domain_ - which includes the place
where the owner specifies the domain's authoritative nameservers.

>> And ironically, the nameserver lines in question _are_ DNS records - in
>> the parent zone.
> 
> Ahhh?? (I want to elaborate but not sure how to put it into words). I
> think I get what you're saying here though.

I will elaborate.  

Your domain is 'sldubois.org.'.  The parent of that domain is 'org.' (the
org top-level domain or TLD.  The parent of _that_ domain is '.', the
hypothetical root of all DNS namespace.  (I"m being achingly precise, here,
in putting a period as right-hand terminator of all FQDNs = fully qualified
domain names, as technically the domain is _not_ fully qualified without the
root specifier, though it is often omitted for convenience.)

Got that hierachy?  To review:

   .              The global DNS namespace's root
   org.           The org TLD
   sldubois.org.  Your domain (a second-level domain), part of org's namespace

Stop and consider:  How does a query about your domain get to the right
place?  I mean, anyone with a nameserver can configure it to serve up some
information of that person's choosing for domain sldubois.org, but some
magic causes queries from random members of the public to go to the
_correct_ nameservers.   That magic is delegation of authority.

Every nameserver starts out with knowledge of the names and location of
thirteen root nameservers (each of which is a large cluster somewhere in the
world).  Those thirteen serve the _root zonefile_, which includes NS and A
records specifying where the nameservers for all the various TLDs are,
including org.  Those records are called 'glue records', on account of the
function they fill, of being the glue that ties a query from a higher level
of the namespace (such as the root zone) to a lower one (such as org).  So,
the first part of the answer to the question 'How does a query about your
domain get to the right place?' is that the nameserver trying to find your
domain knows where the root nameservers are, and can & does ask them where
org's namservers are (information the root namservers possess because of the
glue records).

So, the nameserver trying to find your domain can determine where org's
nameservers are, and can therefore ask _them_ about sldubois.org.  And, you
might ask, why would org's nameservers be able to answer where
sldubois.org's nameservers are?  More glue records.  Every time you change
the 'Name server' controls in your registrar's domain record, you are
literally editing (via a WebUI intermediary) NS records in the zonefile for
the org TLD, creating or changing glue records.  Because of those glue
records, if they exist, and the higher glue records in the root zone, the
query about your domain's DNS gets efficiently routed from the root
nameservers to org's nameservers to your nameservers.

Glue records for your domain (the Name server settings you can edit in your
domain record) are thus absolutely vital to your domain being resolvable at
all.  As a reminder, though, the NS lines in _your_ zonefile for
sldubois.org are also vital, and should always be kept identical to the glue
record data, else odd DNS failures and unplanned efffects will occur.


> I'm used to looking at panels like below where I have access to A,
> CNAME, MX...

In current context, those will be provided inside your sldubois.org
zoneefile at your master nameserver.  (Once you get used the the freedom 
to use standard Unix tools to manage your zone information and nameserver
configuration files, you'll never want to go back to cPanel and other
Web-mediated crippleware.)


> EC2 allows me to pick from various locations where my servers will spin
> up at as in SF, NY, FL, (other countries), etc. which I believe would
> meet the necessary requirements of different geo locations as well as
> power grids/circuits.

You're already ahead of the game in bothering to think about geographic and
network diversity, as examples of ways common-mode failures can occur.  A
truly cautious person would ensure that at least one of the slave
nameservers is not on EC2, just in case some common-mode failure across EC2
is a possibility.  I absolutely agree that this is not a priority for you at
the moment, though.

Over the longer term, keep an ear to the ground for other people running
authoritative nameservers on static IPs.  Make friends, and (in due course)
offer to secondary that person's domains, and politely ask if he/she will
secondary yours.