slave zone updates

[dissy614]

Is it normal for slave zone updates to take 24 hours?  Or is it just me?

My master server does send notifications to slave.he.net.
Watching logs in real time, clicking "validate" performs an AXFR within seconds.  Still, the slave zone does not reflect the data just transferred for about 24 hours.

With more services utilizing DNS records to verify domain ownership, it's starting to become a problem.  By the time the slave data updates to contain the TXT record token, it has already expired long ago.

I can certainly imagine a free service like this under enough of a load that limits are required to stay up and working.
But I don't quite get why the verify button performs an axfr and the data is seemingly discarded, only to be transferred again a day later.  That seems like doubling the data transfer.

That plus no similar issues being posted here leads me to believe this might be some problem with just me.
Any thoughts or suggestions or ideas?

[passport123]

I use NSD as the master server.  When NSD notifies the he.net severs of a zone change, I see those changes  reflected on the he.net servers within ten minutes.  I have a script that runs ten minutes after the notification, and the script always sees the update on the he.net servers within that timeframe.

[passport123]

> Still, the slave zone does not reflect the data just transferred for about 24 hours.

How do you check this?  What command do you run?   (you can use example.com instead of your domain)

[dissy614]

The first time I noticed this, I was using "dig" against ns1.he.net to query the SOA record, so as to check if the serial number incremented to match the master servers.  (I still use the serial format yyyymmddxx where xx starts at 01)

Specifically:  dig @ns1.he.net. example.net. soa

More recently I've also just looked at the records in the slave zone through HE's web interface.

My master server is bind 9, specifically 9.11.5.P4 (it is the default Debian stable package)

Right now the slave zone data is fully up to date, so this time it did not take 23 hours as it did the last time a year or so ago, but certainly far longer than 10 minutes.

At this point I'm thinking the quickest and safest solution for me would simply be to convert the HE slave zone into a master zone, and just remove my bind9 server from the mix entirely.

[passport123]

I use drill instead of dig, but that's the syntax I use.  :)

I use he.net since I want to use DNSSEC on the three domains, and he.net doesn't provide DNSSEC when used as a master.  However, he.net does support the DNSSEC capability I need when used as secondary DNS servers.

My master DNS server does 1 to 5 updates each day as the records' signatures expire and need to be re-signed.  A script checks that each update has made it to the secondary DNS servers.  I get notified when there is a problem, e.g., an update does not make it to the secondary DNS servers.

The only time an update did not propagate correctly occurred during the time I was setting up the system.  The master DNS server was sending updates to he.net too quickly, i.e., too many in a short period of time.  I suspect I may have triggered some manner of DoS protection at he.net.

When I figured that out, I changed my scripts to do a maximum of one update every two minutes.  Since I made that change (about 7 or 8 months ago), I've not had any issues.