Stuck with old box DNS entry?

Help with Unusual Circumstances
1

Good morning,

before migrating to 22.04, I did a reinstall test and I had chosen the default name for the box (box.domainame). I also pointed DNS etc to do the test.

When doing the proper install, on a new fresh machine, I instead used my usual name for the box (mail.domainname).

After 6 days, then I run the STATUS page, I randomly get the below:

The nameservers set on this domain at your domain name registrar should be ns1.mail.xxxx.yy; puck.nether.net. They are currently ns1.box.xxxx.yy; puck.nether.net. If you are using External DNS, this may be OK.

Like if the box.xxxx.yy was cached somewhere…I cannot really understand where…I tried dig, nslookup etc with no luck, this is totally random

Any hint on where to look?

Thank you

F

1 Like
2

Will you share the domain in PM … maybe I can solve the mystery.

3

While reviewing the OP’s zone files, I noticed that the SOA records on the master and the slave were different. Puck had the old hostname while the master was of course up to date. The bizarre part was the both had identical serial numbers.

The solution was to add a record (temporarily) so that the serial number changed leading to an update of the slave.

I suspect that this may have happened when the OP changed the box’s name. I am not sure why the box wouldn’t have updated the serial number though.

4

Thanks Alento,

yes, all good now, your suggestion did the trick perfectly. And yes, I could not really understand the source of the problem!

Cheers

F

5

Hey,
I have the same issue.
I created a new MIAB and the Serial number on the new MIAB is older then the one on the slave servers.
I tried adding a record in the DNS of that domain.
Where are the SOA data stored on the MIAB?
I’m thinking I have done something wrong and there might be a permission issue and the SOA doesn’t get updated on my new MIAB because it doesn’t have the permission to write it…

Now sure where the SOA data is stored.

6

Ok I found the Zone files they are here:
/etc/nsd/zones
The SOA is updated correctly in the zone file.
2025012700 ; serial number
7200 ; Refresh (secondary nameserver update interval)
3600 ; Retry (when refresh fails, how often to try again, should be lower than the refresh)
1209600 ; Expire (when refresh fails, how long secondary nameserver will keep records around anyway)
86400 ; Negative TTL (how long negative responses are cached)

Everything looks good there.
Doesn’t seem to be a permission issue.

Now why is the slave stock on the old serial…

slave

You see the Serial of the Master is way back…

7

I think that this is key here:

What is a failover master?

By default slaves stop responding to queries for the zone when the SOA expiry time has been reached and no contact has been made with the master. The failover master is a secondary hidden master which keeps a copy of the zone keeping it available in case the real master is offline for a longer period than defined in SOA.

It appears that 1984.hosting has added a failover master in the mix. You’ll need to get them to clear that. I haven’t dug into their docs enough to learn anything more about it. Yet. Maybe tomorrow?

8

I disabled the slave and waited a few days for the data to get deleted but they are not updating:
secondary nameserver ns2.afraid.org has inconsistent SOA record (primary: ns1.mail.sssssss.email. hostmaster.mail.ssssssss.email. 2025012900 7200 3600 1209600 86400 versus secondary: ns1.mail.ssssssss.email. hostmaster.mail.ssssssss.email. 2025012500 7200 3600 1209600 86400). Check that synchronization between secondary and primary DNS servers is properly set-up.

I cannot get it to sync. I will wait a few more days.