DNSSEC – Configure Secondary Nameserver

binddns-hostingdns-zonednssecdomain-name-system

I have this hidden master DNS nameserver notifying and updating the two public slave DNS servers:

my own VPS running Debian/Bind9 DNS
3rd-party secondary nameserver provider (afraid.org)

I finally got DNSSEC working with the hidden master and my public slave server (VPS).

Now I am searching high and low for a secondary nameserver service provider that can ALSO support DNSSEC. I couldn't find one. I couldn't understand why.

Then I saw this clue on GoDaddy Secondary NameServer wiki:

"You cannot use both DNSSEC and Secondary DNS with the same domain name."

Why can't a 3rd party provide asecondary name server with DNSSEC?

Best Answer

As has been noted, the quoted statement is one service provider noting a limitation in their own service, it's not a universal truth.

All that is really needed to make what you ask for work is this:

Slave nameserver gets an exact copy of the full zone data (including public keys, signatures, everything) such as what happens with a normal zone transfer (AXFR/IXFR), and simply uses the received zone data verbatim, no mucking about with the data.
Slave nameserver software supports DNSSEC. Ie, supports EDNS0, knows to act on the DNSSEC-relevant flags in the header/EDNS0 fields (such as returning relevant RRSIG/NSEC in responses to queries that request DNSSEC).

As for why the service provider referenced in the question cannot do this, you will really need to direct the question to them to get a proper answer.
Maybe they are using some custom or outdated nameserver software that cannot meet the above requirements? Maybe it's some kind of policy decision that is not even purely technical?

If you look at service providers that have more of a focus on DNS hosting, my impression is that requirements like the above are usually a non-issue (provided they have a slave nameserver option in the first place).

Related Solutions

Why is BIND giving me a SERVFAIL in this case? (Notes inside)

You probably ran foul of the "EXPIRE" field in the SOA record - from §3.3.13 of RFC 1035:

EXPIRE          A 32 bit time value that specifies the upper limit on
                the time interval that can elapse before the zone is no
                longer authoritative.

This field tells a secondary server how long to serve a zone for if the master is no longer responding.

When you changed the zone file on "ns3" did you also reconfigure BIND so that the zone was listed as a "master" rather that a "slave" ? If so, it's that change rather than the change to the first SOA field that actually fixed it.

DNS – Why Aren’t DNS Records Propagating on the Internet?

Yes, you are misunderstanding how DNS works. I'm going to use some emphasis here, but please don't be offended as none is intended.

DNS RECORDS ARE NOT PROPAGATED. THEY ARE CACHED.

That being said, here's a simplified explanation of what happens:

You create a new DNS record (A, CNAME, etc)
A remote user (more specifically a process\application launched by the user) tries to access a service accessed via that DNS record (a web browser trying to access the web site running on funny.example.com for instance)
The users DNS client sends a DNS query to it's DNS server, the DNS server then finds your name servers (usually through a series of recursive DNS queries) and asks them for the information regarding funny.example.com
Your name servers respond with the answers
The users DNS server then sends this information to the user (more specifically to the users DNS client resolver), which in turn returns the information to the process\application. This information comes with what is called a TTL (Time To Live) that tells the DNS client resolver how long this information may be kept in it's DNS cache (in memory) and how long the information can be considered current and accurate
The user's DNS client resolver then flushes this information when the TTL expires. Any new requests for the DNS record(s) in question requires a new DNS lookup and the above process repeats.

So the long and short of it is this:

Your DNS records do not propagate. No other DNS server has a copy of your DNS records or zones. A DNS client or server may cache information about your DNS records or zones (based on their DNS queries of your DNS records and zones) into their DNS cache. This information is temporarily cached and will be removed from their DNS cache when the TTL expires.

If your name servers are down, only those DNS clients that have any of your DNS records in their cache will be able to resolve those DNS records and only until the TTL expires. Also, when the TTL expires (neccessitating a new DNS lokkup) those DNS clients will no longer be able to resolve your DNS records.

Best Answer

Related Solutions

Why is BIND giving me a SERVFAIL in this case? (Notes inside)

DNS – Why Aren’t DNS Records Propagating on the Internet?

Related Topic