Cloud DNS providers for secondary DNS

[Jay Ford]

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.

Good plan.

> 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
hints.

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