# Non-Authoritative DNS conflicting with established TLD Registrar

I am having problems understanding what the problem is here. Something isn't adding up.

It started with a website "www.taapcs.ca" not being resolved on our network. One of the managers asked me why it works on his cell phone but not on our network.

I did an nslookup and found that the Non-Authoritative answer had the correct IP address, but when I tried to get an authoritative answer - it couldn't connect.

The non-authoritative answer was showing the name servers as ns5.newtekdns.com. I could ping that host but using "server ns5.newtekdns.com" in nslookup, failed to connect when I ran the query. To make sure it wasn't a problem with nslookup - I tried telnetting on port 53 did not result in a connection. Instead it timed out.

I thought I had the problem solved - their name server was not responding to DNS queries .. but then it got wierd.

I could do authoritative lookups when I tried from other networks outside my own - but not all. ALSO - When I looked at the registrar record on CIRA (the TLD for .ca) .. it showed that the name server was "ns5.webcontrolcenter.com" ... and the last updated date on the record was "2017/05/17" - nearly a year ago.

This made no sense - how did ns5.newtekdns.com even make it into the non-authoritative records??

So I did some googling and found that Newtek had their domains hijacked in February .. and one of those domains was webcontrolcenter.com ...

Okay - explains how webcontrolcenter.com came into the mix .. but it still doesn't explain why I am getting non-authoritative answers of ns5.newtekdns.com when the TLD is reporting ns5.webcontrolcenter.com ... nor does it explain why I can connect to the newtekdns.com DNS server but only from certain networks ..

I thought that maybe some of the ISPs I was using may be blocking any DNS connections other than to their DNS servers .. but I have a VPS on liquidweb and it too was having this issue. So that seems unlikely.

I should also mention too that ns5.webcontrolcenter.com does not resolve.

This is has me stumped a bit .. It seems lame-brain but my gut feeling at this point is that either newtek is trying to out-propagate the TLD .. or the TLDs have some sort of anti-hijacking mechanism in place that can override the registrar's SOA.

Can someone shed some light on this for me?

• "the TLDs have some sort of anti-hijacking mechanism in place that can override the registrar's SOA." No, because dig @a.root-servers.net taapcs.ca +trace takes you right back to the nonexistent ns5 and ns6.webcontrolcenter.com. The most likely explanation seems like it would be that ns5/ns6.webcontrolcenter.com were recently deleted from DNS but they previously pointed to the same IP addresses as ns5/ns6.newtekdns.com, which would have named themselves as you saw in the response even if they were accessed via the now-unconfigured hostnames. DNS recursion doesn't send names forward. – Michael - sqlbot May 4 '18 at 0:27
• Also, this: newtekone.com/info This site needs to change its authoritative DNS servers with their registrar. – Michael - sqlbot May 4 '18 at 0:31
• "DNS recursion doesn't send names forward" .. that would be one of the pieces of the puzzle I was missing - thanks – DHW May 4 '18 at 3:29

First have a look at http://dnsviz.net/d/www.taapcs.ca/WuvNaw/dnssec/ : you will see that taapcs.ca is not configured at all correctly.

The specific error is:

taapcs.ca zone: The following NS name(s) did not resolve to address(es): ns5.webcontrolcenter.com, ns6.webcontrolcenter.com

There is no need to dig(!) any further: this domain is broken. It may work or not, but it is certainly not correctly configured. So this have to be fixed by its owner/handler.

For the rest of your questions/observations you do not show precisely what requests you are doing and into what nameservers so it is difficult to explain what you see because it is not even clear. You can try multiple open recursive nameservers to see their opinion:

$dig www.taapcs.ca A @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.taapcs.ca A @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32886 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.taapcs.ca. IN A ;; Query time: 86 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu May 03 22:08:17 EST 2018 ;; MSG SIZE rcvd: 42$ dig www.taapcs.ca A @9.9.9.9

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.taapcs.ca A @9.9.9.9
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41973
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.taapcs.ca.         IN  A

;; Query time: 296 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Thu May 03 22:08:22 EST 2018
;; MSG SIZE  rcvd: 42

$dig www.taapcs.ca A @1.1.1.1 ; <<>> DiG 9.10.3-P4-Debian <<>> www.taapcs.ca A @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54227 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1536 ;; QUESTION SECTION: ;www.taapcs.ca. IN A ;; ANSWER SECTION: www.taapcs.ca. 3600 IN A 216.119.109.200 ;; Query time: 374 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Fri May 04 05:10:46 CEST 2018 ;; MSG SIZE rcvd: 58  Note the two SERVFAIL, and indeed CloudFlare replies instead with an IP and NOERROR. I do not know how/where you see non-authoritative elements: $ dig www.taapcs.ca @any.ca-servers.ca A

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.taapcs.ca @any.ca-servers.ca A
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42958
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.taapcs.ca.         IN  A

;; AUTHORITY SECTION:
taapcs.ca.      86400   IN  NS  ns5.webcontrolcenter.com.
taapcs.ca.      86400   IN  NS  ns6.webcontrolcenter.com.

;; Query time: 45 msec
;; SERVER: 199.4.144.2#53(199.4.144.2)
;; WHEN: Thu May 03 22:16:55 EST 2018
;; MSG SIZE  rcvd: 98

• Non authoritative replies were cached -- coming from the ISP DNS server of the places I tried. It was clear early on that the DNS record was broken and needed to be fixed - but when I started seeing newtekdns.com appear during nslookups it confused me. Of course as soon as @sqlbot pointed out the reverse dns lookup - I was like "ah - of course!" – DHW May 4 '18 at 4:00
• Why would CloudFlare reply with an IP when the other servers do not? When I use DNS propagation tools online - it shows the vast majority of sites are able to resolve the host. – DHW May 9 '18 at 15:13
• @DHW I have no specific idea, but the fact that the domain in badly configured is for me enough reason not to search further, as so many level of DNS brokenness can produce so many levels of strange and erratic behavior. Maybe taapcs is a CloudFlare client, and they learnt their IP in some way, I do not know. – Patrick Mevzek May 9 '18 at 17:19
• I agree - it was more of a curiosity. I know they aren't cloudflare. The IP address delegation would have remained delegated with newtek despite the domain names changing .. so maybe that factors in somehow. – DHW May 11 '18 at 19:44