Home / server / Questions / 322490
Accepted
Toby Allen
Asked: 2011-10-19 02:32:30 +0800 CST

What is the correct behaviour when Nameservers Change

  • 772

I have been having some issues with a certain network supplier over unchanged nameservers making my site invisible to their customers. I wouldnt be bothered except that they are one of the largest ISP's in Ireland.

They claim that the records are still active on the old nameservers for my site so therefore they shouldn't change until they get a response telling them there are no dns records for the site.

My question is, what is the correct behaviour? Every other network provider, isp, dns server on the web has updated to my new nameservers.

Are they following some technically correct but ignored RFC that says they don't need to check new nameservers until the old ones return an error?

Update:

Vodafone eventually contacted me and have said they have resolved the issue, and more importantly are now escalating it to their correct technical staff so this issue shouldn't affect anyone else. Hope this solves the issue.

domain-name-system networking nameserver

3 Answers

  1. Best Answer

    You appear to be seeing an issue known as child sticky resolvers.

    For each domain name there are two possible sets of NS records - those at the parent zone, and those in the zone itself.

    Some recursive resolvers will cache the set learned from the child, and then repeatedly go back to those servers for all subsequent refreshes. This is the child sticky behaviour. If the parent zone records get changed but the (original) child zone records are left unchanged, these child sticky resolvers will fail to notice the change in the parent zone.

    Many (if not most) implementations will revert to the parent NS records to ensure that they haven't changed whenever the current NS record set expires from cache. This is considered "normal behaviour" but isn't unambiguously specified in the RFCs.

    To work around this child sticky behaviour at your end you should replace the NS records in your old servers with the correct records showing the new servers' names.

    For more details see slides 8 through 15 of this presentation by Ólafur Guðmundsson, chair of the IETF DNSEXT working group.

    • 15

  2. Are they following some technically correct but ignored RFC that says they don't need to check new nameservers until the old ones return an error?

    How would we know?

    AFAIK there is no such thing - and they should refresh the records every time they get a request for a cached record with an expired TTL.

    • 2

  3. Well, I saw at ns.webfusion.co.uk records for your domain data in it. Sadly, you didn't kill zones on old NSes, but this t does not excuse the behavior of Vodafone. I'll explain this now. Well, let's assume Vodafone resolvers some time ago cached both records: A for www and NS for domain. But I see

    Quering 212.67.202.1 for {cookingisfun.ie.,NS}
; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: true  TC: false  RD: true
; RA: false  RCODE: NOERROR  qc 1  an 2  au 0  ad 2

; Question section:
;cookingisfun.ie. IN NS

; Answer section:
cookingisfun.ie. 1d IN NS ns2.hosteurope.com. 
cookingisfun.ie. 1d IN NS ns.hosteurope.com. 

; Authority section:
;(none)

; Additional section:
ns2.hosteurope.com. 2h IN A 92.51.159.40 
ns.hosteurope.com. 2h IN A 212.67.202.2

    i.e. NS-records must be expired and removed from cache after one day of receiving

    Quering 212.67.202.1 for {www.cookingisfun.ie.,A}
; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: true  TC: false  RD: true
; RA: false  RCODE: NOERROR  qc 1  an 1  au 0  ad 0

; Question section:
;www.cookingisfun.ie. IN A

; Answer section:
www.cookingisfun.ie. 1d IN A 212.67.220.186 

; Authority section:
;(none)

; Additional section:
;(none)

; Query took: 94 msec
; Server queried: 212.67.202.1[udp]

    same 1-day interval applied to A for www.cookingisfun.ie

    I.e after one day delay Vodafone must re-ask about A, and some recursor on the path will return new NS and new NSes - new A.

    Since we know that this is not happening, I see this as a strong string of RFC-ignoration (storing outdated data in cache - see my answer on your previous question). Toby, I think, you can show my requests above to Vodafone and ask "WTF??? Why you use outdated data? You must not ask 212.67.202.2 about nothing related with cookingisfun.ie long time ago. Fixit ASAP"

    • 1