9

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.

Community
  • 1
Toby Allen
  • 747
  • 2
  • 10
  • 23
  • Do you mean that you have changed the nameservers defined as authoritative for the domain via their NS records, and the ISPs DNS servers are still using the records from the previous nameservers? Do you have any kind of access to the old nameservers? – dunxd Oct 18 '11 at 10:39
  • No Access, just access to technical support for old webhost. The registrar was asked to change the nameserver which they did, I presume thats authoratitive. But my point really is that whatever I did it work with every other network supplier. – Toby Allen Oct 18 '11 at 10:43
  • How long ago did the changes take place. The rule of thumb is that it can take 72 hours for the changes to take effect everywhere. – dunxd Oct 18 '11 at 10:55
  • Almost 3 weeks ago! – Toby Allen Oct 18 '11 at 11:58
  • Check the answer to this question and consider whether you did everything you should when changing the nameservers: https://serverfault.com/questions/155355/nameserver-change-jumps-back-to-old-nameservers-cause – dunxd Oct 18 '11 at 10:42
  • Well I checked using the link to network lookup and everyone else points to the new nameservers. – Toby Allen Oct 18 '11 at 10:48

3 Answers3

15

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.

Alnitak
  • 20,901
  • 3
  • 48
  • 81
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.

symcbean
  • 19,931
  • 1
  • 29
  • 49
1

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"

Lazy Badger
  • 3,067
  • 14
  • 13