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.

Improve this question
6
  • 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, 2011 at 10:39
  • Check the answer to this question and consider whether you did everything you should when changing the nameservers: serverfault.com/questions/155355/…
    – dunxd
    Oct 18, 2011 at 10:42
  • 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, 2011 at 10:43
  • Well I checked using the link to network lookup and everyone else points to the new nameservers.
    – Toby Allen
    Oct 18, 2011 at 10:48
  • 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, 2011 at 10:55

3 Answers 3

Reset to default
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.

Improve this answer
1
  • So what is the solution to get ISP to use new name servers? It has been weeks now and a site still does not load properly on some ISPs. domain-a.com has its NS server set to ns.domain-b.com, and the A record for ns.domain-b.com was updated to a new IP forever ago, but they are still trying to hit the old IP when resolving domain-a.com.
    – Mike Marynowski
    Nov 16, 2023 at 13:29
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.

Improve this answer
2
  • 3
    yes, but the problem with NS records is knowing who to ask when they expire - see my answer.
    – Alnitak
    Oct 18, 2011 at 12:07
  • not should, but MUST - in RFC terminology
    – Lazy Badger
    Oct 18, 2011 at 12:17
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"

Improve this answer
4
  • Well, 212.67.202.1 isn't old authoritative server for domain, shadow primary is 212.67.202.2, but it change almost nothing in response
    – Lazy Badger
    Oct 18, 2011 at 11:52
  • 1
    It's not an RFC compliance issue, it's an RFC ambiguity issue.
    – Alnitak
    Oct 18, 2011 at 12:15
  • Aren't they all :)
    – Toby Allen
    Oct 18, 2011 at 12:18
  • 1
    Well, RFC 1034 and 1035 are very old and didn't get as rigorous a review as modern RFCs do.
    – Alnitak
    Oct 18, 2011 at 12:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .