2

Network Solutions DNS servers (ns1 - ns99.worldnic.com) answer the IP 141.8.225.31 for any A query to which they do not hold the answer. E.g.:

C:\>dig @ns11.worldnic.com www.google.com
www.google.com.         3600    IN      A       141.8.225.31

For the corresponding NS query, they claim to give an authoritative answer that their server holds the SOA for that TLD.

C:\>dig @ns11.worldnic.com www.google.com NS
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
com.                    3600    IN      SOA     ns11.worldnic.com. dns.worldnic.com. 2016010801 3600 600 1209600 3600

The same results occur for any name for which they are not authoritative, e.g. previous customers like metacase.com, or non-existent names like xyxyxyxyxy.net. All return the same IP, which is for a spammy advertising site in Switzerland.

This seems incorrect. Although normally ISP DNS servers will not query Network Solutions for these names, when a domain is transferred away from their name servers many ISP DNS servers ("child sticky") continue to ask the previous name server as long as it claims to answer. Thus a domain transfer (or change of authoritative name server) results in a loss of connectivity for that host, even if the host's actual IP remains unchanged and was correct in both losing and gaining authoritative name server.

Full dig output for the above queries:

C:\>dig @ns11.worldnic.com www.google.com

; <<>> DiG 9.11.3 <<>> @ns11.worldnic.com www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44870
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2800
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         3600    IN      A       141.8.225.31

;; Query time: 154 msec
;; SERVER: 207.204.40.106#53(207.204.40.106)
;; WHEN: Mon Apr 09 13:22:19 FLE Summer Time 2018
;; MSG SIZE  rcvd: 59


C:\>dig @ns11.worldnic.com www.google.com NS

; <<>> DiG 9.11.3 <<>> @ns11.worldnic.com www.google.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50950
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2800
;; QUESTION SECTION:
;www.google.com.                        IN      NS

;; AUTHORITY SECTION:
com.                    3600    IN      SOA     ns11.worldnic.com. dns.worldnic.com. 2016010801 3600 600 1209600 3600

;; Query time: 151 msec
;; SERVER: 207.204.40.106#53(207.204.40.106)
;; WHEN: Mon Apr 09 13:22:32 FLE Summer Time 2018
;; MSG SIZE  rcvd: 97
stevek_mcc
  • 125
  • 1
  • 6
  • *many ISP servers ("child sticky") continue to ask the previous registrar as long as it claims to answer.* -- You're implying that the presence of an `A`/`AAAA` record has any bearing on the handling by the DNS server, but this is not accurate. Authority for the zone is tied to the `NS` records on either side of the referral and their cached state. Beyond this, you will need to consult with Network Solutions directly as 1) we do not provide technical support for them, 2) this question has nothing to do with the associated tag, and 3) all answers would be 100% speculative. – Andrew B Apr 09 '18 at 15:34
  • Thanks @AndrewB. "Child sticky" is indeed based on the NS query response; both seem incorrect here, feel free to edit whichever part seemed to imply just A. I'm also happy to hear suggestions of better tags. If Network Solutions' behaviour is correct, and I shouldn't be surprised by this 141... IP, that's great - please enlighten me. If it's not correct, I agree that "why" would be speculative or at best an educated guess, but even an answer of "their behaviour is clearly wrong" would at least be a useful starting point. – stevek_mcc Apr 09 '18 at 20:12
  • "when a domain is transferred away many ISP servers ("child sticky") continue to ask the previous registrar as long as it claims to answer. " How so? A registrar transfer does not change the DNS, and when you update the DNS clients will query the old nameservers for some time because of the TTL but after a while they will only query the new ones. – Patrick Mevzek Apr 12 '18 at 13:19
  • I've edited the question to make clearer that it's not the registrar change itself, but the (often) accompanying change of authoritative name server that is relevant - thanks @PatrickMevzek! – stevek_mcc Apr 14 '18 at 10:26

1 Answers1

1

It is not incorrect per se.

Everyone is free to install a nameserver on its network that is configured the way it likes. It does not matter as this server will not get queried until it appears in some parent zone as authoritative for some domain name.

Registrars typically have nameservers configured as "wildcards" in the sense they will reply exactly the same thing whatever you ask (typically giving an IP address pointing to a website showing a placeholder) so what they can be used for example for parked domain names, before their customers set "real" nameservers.

Doing so enables them to not have to configure the nameserver with some list of domain names beforehand, they just reply the same thing.

Now you claim that "ISP" still query them when they shouldn't but you not give specific examples. To note: a domain name transfer from one registrar to another does not change the nameservers of the domain name (it depends on the TLD but this is the major case); the new registrar, after the transfer completes, can of course change nameservers.

Other recursive nameservers will continue to query the old nameservers for some time, this is normal and per design of the DNS. It is controlled by the TTL (Time To Live) in the zone, rarely greater than 48 hours.

I am not understanding this at all:

Thus a domain transfer (or change of authoritative name server) results in a loss of connectivity for that host, even if the host's actual IP remains unchanged and was correct in both losing and gaining authoritative name server.

If the nameservers change but the zone content is the same on both ones, then the resolution will not change. If the nameservers do not change, and they do not per the registrar transfer just by itself, then the resolution do not change either. If the nameservers do change, after some delay, the old ones will not get queried anymore at all so the zone content at the new nameservers will dictate how the resolution happens.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
  • The instant the domain transfer was approved by Network Solutions, their servers switched from answering the correct IP to answering the spammy advertising site's IP. The old name server was queried by child-sticky ISP DNS servers like Elisa (Finland), Speakeasy (US), TalkTalk (UK), Vodafone (NZ) for a couple of days (>55 hours). Thus for over 2 days ~15% of browsers got the wrong site. My guess is that Network Solutions had simultaneously removed the record from their DNS and thus queries for it fell back on a wildcard. Oddly, the wildcard IP and site there is not one of theirs. – stevek_mcc Apr 15 '18 at 19:05
  • @stevek_mcc You are mixing two things. A domain name registrar is not necessarily the DNS hoster. It can be but it can also be another provider. So if you have a domain name at a registrar **and** you are using its nameservers for your domain name, then as soon as you transfer your domain out of this registrar, since you stopped your contract with it, it could stop answering DNS requests for your domain name. It is certainly not nice to you, but that happens. It is easy to fix: do not use your registrar nameservers or at least change them **before** the transfer. – Patrick Mevzek Apr 15 '18 at 19:35
  • I'm not mixing them up this time, they just happen to be the same in this case :). If I had changed the nameserver before the transfer, it may not have helped: the problem isn't the registrar transfer, it's what happens when they remove our name from their name server. The incorrect A record above would still be returned, and the incorrect(?) NS record above would still be returned. I can see this on another site, dsmforum.org, where Network Solutions is registrar but we have changed their settings to use the new nameservers months ago: NetSol still return the incorrect A & NS. – stevek_mcc Apr 15 '18 at 20:37
  • The problem is not with the change of registrar but the fact that you use the registrar nameservers and your contract with it stopped when you transferred your domain elsewhere. If you did not use its nameserver from the beginning, the transfer would not have changed anything regarding the resolution of your domain name. IF you change nameservers of your domain, **the old ones will not be queried at all** (after some delay) so what the old ones publish is irrelevant. – Patrick Mevzek Apr 15 '18 at 21:04
  • The interesting question is how to avoid the 2-day outage in this situation - what the old server published was relevant then. Child sticky ISP DNS servers + NetSol's instant removal of DNS records + NetSol falling back to a wildcard = problems. The only TTL we could affect on NetSol was for A records, which wouldn't help with child-sticky NS queries. – stevek_mcc Apr 15 '18 at 21:39
  • Again and again: change the nameservers well before the transfer and you will have 0 downtime. You seem stuck at your explication and not wanting to really read what I write so I will stop now, but you are clearly creating problems where they are not. Again: what nameservers reply is not relevant if they are not listed as authoritative in the parent zone. And please stop using new terminology like "Child sticky ISP DNS" which means nothing. You again do not show any tangible proof that some ISPs are using old NS records for your domain, per your writing. – Patrick Mevzek Apr 15 '18 at 21:50
  • Thanks for trying to help, Patrick. We are both a bit stuck in repeating ourselves: your expected reality doesn't match my experienced reality. See https://serverfault.com/a/322524/216 for more info on child sticky resolvers. I have A, NS and SOA results from 22 ISPs, of which 7 were still incorrect until 56 hours after the registrar and nameserver transfer, answering the same incorrect IP as NetSol. For more detailed dig results, see the original post or simply re-run the commands: NetSol results haven't changed. – stevek_mcc Apr 15 '18 at 22:52
  • Then try contacting the faulty ISPs (you are not showing any concrete data...), without too much hope they will reply to you and act on it, but if your problem is business critical.... It also depends on the initial TTLs (specifically on the SOA and NS records). What where they? Also, stop hoping Network Solutions will change: per my answer, as many others, they have nameservers acting as wildcards for any request, be it on your names or others. They will not change it just for you, as unfortunate as it may be for you. I hope the situation will solve by itself for you in some hours/days... – Patrick Mevzek Apr 15 '18 at 23:04
  • The problem at ISPs resolved itself after 56 hours (see previous comment) - I'm trying to figure this out so others can avoid similar outages. Our original A TTL was 3600 (the minimum allowed at NetSol). NetSol DNS customers' NS and SOA TTL are fixed at 7200, and other SOA times are refresh=10800 retry=3600 expire=604800 minimum=3600. The NetSol wildcard NS and SOA TTL is 3600 and other SOA times are refresh=3600 retry=600 expire=1209600 minimum=3600 (the same for non-customers, ex-customers and current customers who have instructed NetSol that they are using other name servers). – stevek_mcc Apr 16 '18 at 09:42