ns7 not updating

RHunt7

RHunt7

New Member
Mon 08:29:~$ nslookup mlca.info ns7.zoneedit.com
Server: ns7.zoneedit.com
Address: 198.199.82.247#53

Name: mlca.info
Address: 125.238.96.200 VERY OLD!!!

Mon 08:29:~$ nslookup mlca.info ns9.zoneedit.com
Server: ns9.zoneedit.com
Address: 23.27.48.60#53

Name: mlca.info
Address: 115.188.107.201 CURRENT :-)

What's going wrong here?
 
ns7 is the new server running a different type of nameserver (powerdns) and we had some sync issues. We ran a job to catch-up the domains affected but we must have missed yours. I just ran it for you now and it's looks good now.

bash-3.2# dig +short -t soa mlca.info ns9.zoneedit.com
dns0.zoneedit.com. zone.zoneedit.com. 1433166472 43200 10800 604800 300
bash-3.2# dig +short -t soa mlca.info ns7.zoneedit.com
dns0.zoneedit.com. zone.zoneedit.com. 1433166472 43200 10800 604800 300
bash-3.2#
 
This appears to be a problem again with ns7. We added an A record a few days ago which is showing correctly on NS14 and NS17, but has not propagated to NS7.
 
Is this for mlca.info again? It looks in sync to me:

$ dig +short -t soa mlca.info @ns17.zoneedit.com
dns0.zoneedit.com. zone.zoneedit.com. 1436903189 43200 10800 604800 300
$ dig +short -t soa mlca.info @ns14.zoneedit.com
dns0.zoneedit.com. zone.zoneedit.com. 1436903189 43200 10800 604800 300
$ dig +short -t soa mlca.info @ns17.zoneedit.com
dns0.zoneedit.com. zone.zoneedit.com. 1436903189 43200 10800 604800 300
 
Mark, would this be a permanent change? I've removed ns7 from my registrar and set t1 as my 3rd name server to get things to actually work for now. I don't have any way of really knowing which one would be a better fit. One would tend to assume that all of the name servers in your system would work equally well. (and if not, they would not be used at all--why should we be using questionable name servers?) Seems like this ns7 set up is not as robust as the others.
 
Hi, you can use t1 on a go forward basis. The t1 and t2 nameservers are supposed to be the "additional tertiary" nameservers that you got when you added the third under the legacy zoneedit, but we see in many cases they got a regular tertiary. In our implementation, t1 and t2 are colocated within staminus.net datacenters, so they are a lot more resistant to ddos.

all things being equal, ns7 should be behaving, obviously it isn't - this could be a bug introduced in a recent update. Part of our core philosophy is to operate a heterogenous nameserver environment (running different types of nameservers) as from a DNS perspective - diversity is good. A zero-day or critical bug in one type of nameserver software won't cripple your entire fleet if they are not all running the same daemon. Etc.
 
Ok. Understand (and that makes sense). I appreciate the detailed explanation. Is there any way to force ns7 to update? Since it was one of the nameservers listed as a parent for my domain (and it still doesn't have the correct information), several DNS servers are still expecting ns7 to be authoritative to my domain. Google and Charter's DNS are still looking to ns7 for at least some of their look ups. The expiry was set to 1 week and I really can't wait a week for this to be correct. (TTL was set to 1 hour)
 
Was just discussing this with dev this morning and we've escalated internally to systems. It's a problem with the database replication out to this pdns node, all the other pdns nodes are in sync.
 
You must log in or register to reply here.
Back
Top