Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cloud DNS providers for secondary DNS

1,674 views
Skip to first unread message

Diggins Mike

unread,
Dec 29, 2015, 7:40:36 PM12/29/15
to bind-...@lists.isc.org
Hello,

I'm looking into providing secondary name service for my organization using a cloud DNS provider (D-Zone). We would transfer our zones to them using a standard zone transfer and they would publish them to their AnyCast DNS servers. I was going to simply add their DNS servers to my Domain Registrars list of authoritative name servers. Is it enough to do that or do I also need to add these (2) name server addresses to each of my zone files as well (I have about 50 zones).

;------------------------------------------------------------------------------
; Name Servers
;------------------------------------------------------------------------------
IN NS ns1.mydomain.com.
IN NS ns2.mydomain.com.
IN NS ns1.d-zone.ca <== Addition
IN NS ns2.d-zone.ca <== Addition

What happens if I do one without the other? I guess I don't fully understand the relationship between the name servers listed in the zone versus the ones found in my domain record. I'm running BIND locally, if that matters.

-Mike

John W. Blue

unread,
Dec 29, 2015, 7:53:08 PM12/29/15
to Diggins Mike, bind-...@lists.isc.org
Hello Mike!

So you are tracking correctly what needs to be done: update your registrar and your master zone files. Not knowing how the UI to the cloud and at the risk of stating the obvious, the only other agenda item that you would need to address is making sure that the cloud knows it is a slave.

If your secondary servers were normal BIND, you would need to tag your zones in the named.conf file as slaves.

Hope that is helpful.

John
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

John Levine

unread,
Dec 29, 2015, 8:09:18 PM12/29/15
to bind-...@lists.isc.org
> IN NS ns1.mydomain.com.
> IN NS ns2.mydomain.com.
> IN NS ns1.d-zone.ca <== Addition
> IN NS ns2.d-zone.ca <== Addition

These questions would, as always, be easier to answer if you gave us
the actual names rather than inventing other names that may or may not
be similar to the real ones.

If your servers are not authoritative for d-zone.ca, which in this
case they very likely aren't, there is no benefit from putting their A
or AAAA records into your zones, since nobody will ask for them. Just
add the NS records to your own zones, and add them to the list that
the registrar uploads to the TLD zone and it will work.

If you're using nameservers with names within your own zone you have
to set up glue records, but in this case you don't.

R's,
John

Michelangelo De Simone

unread,
Dec 29, 2015, 8:36:08 PM12/29/15
to bind-...@lists.isc.org
On Tue, Dec 29, 2015, at 04:40 PM, Diggins Mike wrote:

> What happens if I do one without the other? I guess I don't fully
> understand the relationship between the name servers listed in the zone
> versus the ones found in my domain record. I'm running BIND locally, if
> that matters.

Hi Mike,

I'm not sure I understand your question entirely; for a correct
master/slave configuration you usually need:

1. the NS records have to point toward all the nameservers that are
authoritative for your zone (primary and secondary/ies)
2. your slave nameserver(s) should be aware that they're slave for the
specified zone and they need to know who the master is
3. your master nameserver should allow AXFR (zone transfer) toward the
slave server(s)

Generally speaking your master should never allow zone transfers, saved
the explicitly defined slave server(s); also, in order to avoid
unecessary polling, you may think of enabling the "notify" options from
your master toward your slaves.

An excellent tutorial might be found on [1]. I don't know whether this
answers your questions.:)

[1]
http://www.microhowto.info/howto/configure_bind_as_a_slave_dns_server.html
--
Bye,
Michelangelo

Reindl Harald

unread,
Dec 29, 2015, 9:05:25 PM12/29/15
to bind-...@lists.isc.org


Am 30.12.2015 um 01:40 schrieb Diggins Mike:
> Is it enough to do that or do I also need to add these (2) name server addresses to each of my zone files as well (I have about 50 zones)

each zone has to have it's nameservers as NS records
just use http://www.intodns.com/ after any DNS infrastructure changes

http://www.noip.com/blog/2011/04/08/anatomy-of-a-zone-file-part-two-what-are-ns-records-and-why-are-they-important-to-dns/

signature.asc

Luis Daniel Lucio Quiroz

unread,
Dec 29, 2015, 9:12:40 PM12/29/15
to Reindl Harald, bind-...@lists.isc.org

You could use dyndns for that, but it is not free.

With a little knowledge, you can save that and put your own slaves. As cheap as 6 USD per year.

Reindl Harald

unread,
Dec 29, 2015, 9:20:57 PM12/29/15
to bind-...@lists.isc.org


Am 30.12.2015 um 03:12 schrieb Luis Daniel Lucio Quiroz:
> You could use dyndns for that, but it is not free.

do the provide anycast?

> With a little knowledge, you can save that and put your own slaves. As
> cheap as 6 USD per year.

the OP asked for https://en.wikipedia.org/wiki/Anycast#Domain_Name_System

when you run the master servers you have already the little knowledge
but you hardly get your own slaves with your own anycast infrastrcuture
for 6 USD per year - drive your own master and slave is dead simple but
not the question of the OP

[harry@srv-rhsoft:~]$ dig NS thelounge.net @8.8.8.8
; <<>> DiG 9.10.3-P2-RedHat-9.10.3-7.P2.fc23 <<>> NS thelounge.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62766
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;thelounge.net. IN NS

;; ANSWER SECTION:
thelounge.net. 11284 IN NS ns1.thelounge.net.
thelounge.net. 11284 IN NS ns2.thelounge.net.


> Le 29 déc. 2015 9:05 PM, "Reindl Harald" <h.re...@thelounge.net
> <mailto:h.re...@thelounge.net>> a écrit :
signature.asc

John Levine

unread,
Dec 29, 2015, 9:40:29 PM12/29/15
to bind-...@lists.isc.org
>Am 30.12.2015 um 03:12 schrieb Luis Daniel Lucio Quiroz:
>> You could use dyndns for that, but it is not free.
>
>do the provide anycast?

Yes, of course. Dyn is one of the largest DNS providers in the world.

Their basic secondary service is $40/yr.

R's,
John

Lightner, Jeff

unread,
Dec 30, 2015, 8:33:26 AM12/30/15
to bind-...@lists.isc.org
The OP mentioned notifying Registrars. He'll also need to notify whoever his ISP is if he has arpa zones for reverse lookups and they are delegating to his name servers.


-----Original Message-----
From: bind-user...@lists.isc.org [mailto:bind-user...@lists.isc.org] On Behalf Of John Levine
Sent: Tuesday, December 29, 2015 9:40 PM
To: bind-...@lists.isc.org
Subject: Re: Cloud DNS providers for secondary DNS

>Am 30.12.2015 um 03:12 schrieb Luis Daniel Lucio Quiroz:
>> You could use dyndns for that, but it is not free.
>
>do the provide anycast?

Yes, of course. Dyn is one of the largest DNS providers in the world.

Their basic secondary service is $40/yr.

R's,
John

Diggins Mike

unread,
Dec 30, 2015, 11:52:20 AM12/30/15
to bind-...@lists.isc.org
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?

-Mike

-----Original Message-----
From: bind-user...@lists.isc.org [mailto:bind-user...@lists.isc.org] On Behalf Of Lightner, Jeff
Sent: Wednesday, December 30, 2015 8:33 AM
To: bind-...@lists.isc.org
Subject: RE: Cloud DNS providers for secondary DNS

The OP mentioned notifying Registrars. He'll also need to notify whoever his ISP is if he has arpa zones for reverse lookups and they are delegating to his name servers.


-----Original Message-----
From: bind-user...@lists.isc.org [mailto:bind-user...@lists.isc.org] On Behalf Of John Levine
Sent: Tuesday, December 29, 2015 9:40 PM
To: bind-...@lists.isc.org
Subject: Re: Cloud DNS providers for secondary DNS

>Am 30.12.2015 um 03:12 schrieb Luis Daniel Lucio Quiroz:
>> You could use dyndns for that, but it is not free.
>
>do the provide anycast?

Jay Ford

unread,
Dec 30, 2015, 12:22:07 PM12/30/15
to Diggins Mike, bind-...@lists.isc.org
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-...@uiowa.edu, phone: 319-335-5555

Chris Buxton

unread,
Dec 30, 2015, 12:54:46 PM12/30/15
to Michelangelo De Simone, bind-...@lists.isc.org
> On Dec 29, 2015, at 5:36 PM, Michelangelo De Simone <mic...@ngelo.eu> wrote:
>
> also, in order to avoid
> unecessary polling, you may think of enabling the "notify" options from
> your master toward your slaves.

No, that's not what that does.

The notify mechanism is enabled by default, although it probably needs some tweaking using also-notify in an anycast scenario.

The notify mechanism allows the master server to notify slave servers (or other hosts) when a zone changes. This speeds up the synchronization process between master and slaves, but does not preclude the regular scheduled SOA queries.

If for some reason you were concerned about zone refresh traffic (typically 1 query per zone every several hours), you can tune it in a few ways, including adjusting your refresh timer upward to, say, a day or even two. This is safer to do when you know that the notify mechanism is working properly. Is that perhaps what you meant?

Regards,
Chris

John Levine

unread,
Dec 30, 2015, 1:35:00 PM12/30/15
to bind-...@lists.isc.org
>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?

Not sure I understand your question. If you're looking for, say,
www.blah.example, you (actually your DNS cache that does the recursive
lookups) ask the example TLD servers for www.blah.example, and it
answers with some NS records that say that the blah.example domain is
handled by some set of servers. Then the cache looks up the address
of one of the servers if it doesn't have it already, and asks it for
www.blah.example. If the server doesn't know the answer, i.e., it
doesn't handle the blah.example zone, that's a lame delegation. At
that point most caches will try other servers to try and find a
non-lame one so it's not fatal, but it's not a great idea either.

Extra complication ensues when the server's name is within the zone,
e.g., the server for blah.example is ns.blah.example. In that case,
the A or AAAA record(s) for ns.blah.example are copied into the upper
level zone (the TLD in this case) as "glue" that are returned in the
additional section of the answer, so caches can use it to handle the
request.

R's,
John
0 new messages