3

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
Improve this question
4
  • 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 9, 2018 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 9, 2018 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, 2018 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, 2018 at 10:26

1 Answer 1

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

Improve this answer
9
  • 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, 2018 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, 2018 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, 2018 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, 2018 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, 2018 at 21:39

You must log in to answer this question.

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