Cloud DNS providers for secondary DNS
jay-ford at uiowa.edu
Wed Dec 30 17:22:01 UTC 2015
On Wed, 30 Dec 2015, Diggins Mike wrote:
> Thanks for the help. My question is hypothetical at this point and likely
> pointless since I intend to implement it the "right" way, but I'd still
> like to understand this better. I'm not looking to circumvent the rules.
> My more specific question is this: If I'm a site on the internet looking
> for a server in my domain for the first time, I query the TLD servers for a
> list of name servers for my domain and pick one to query. Suppose I pick
> one that has the correct zone information and can answer the query, but
> that specific NS is not listed in the zone record. I believe that's called
> a LAME nameserver, correct? What happens? Does it answer the query
> regardless? Does specifying the NS record in the zone simply confirm to the
> remote site that this is a valid nameserver for this zone?
A lame delegation is when you have an NS record to a server which doesn't
know about the domain in question.
You're glossing over some details which matter, & which often contribute to
broken DNS configurations.
The servers for the parent domain (edu, com, org...) will provide whatever
information you specify via your registrar (NS records & A/AAAA records for
glue if pertinent). However, that information isn't authoritative, because
those servers aren't authoritative for your domain. The information is
offered as hints to find authoritative information. If you specify NS
records for your servers & cloud servers, queriers will use both sets as
A querier with no knowledge of your domain will use those hints to find
authoritative information. In your case, that querier will talk to your
servers and/or the cloud servers. If the cloud servers respond with NS
records for only your servers, the querier will subsequently talk to only
your servers & not the cloud servers, because that's what the authoritative
information says to do. This probably isn't what you want to happen, so you
probably want to include NS records for the cloud servers, so that queriers
will use the cloud servers for subsequent queries.
The flip side of this is what your on-campus (or on-whatever) queriers do.
If you have devices on your campus/whatever which use NS records (as opposed
to just being pointed at a recursive resolver), they will (in general) use
all of the NS records. As result some amount of such queries will go to the
cloud servers when it might be better to have them go to your (presumably
local) servers. As long as all the servers have the same information, the
answers will be consistent, but performance might suffer. This might or
might not be a problem.
If you do split-view games, things get even more interesting.
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford at uiowa.edu, phone: 319-335-5555
More information about the bind-users