Constantly timing out looking for A and AAAA

Help
1

My domain is: shibumidesignstudios.com
I ran this command: dig @ns1.themindfactory.com shibumidesignstudios.com
It produced this output: its what is expected I get the IP
My web server is (include version): 20.04LTS
and its the latest PLESK control panel

Issue is Lets always timesout and I do not see why....

Thanks!
Richard.

1 Like
2

Please see shibumidesignstudios.com | DNSViz

Multiple nameservers aren't reachable.

5 Likes
3

WOW excellent tool! thanks!

So these DNS servers that are failing I see their IPs and do not know who they are.... I have setup ns1 and ns2.themindfactory.com and they seem to resond just fine, not sure why the others are used....

2 Likes
4

I see they say "glue address" are an issue, the changes we made were weeks ago... propogation should not be issue now???

5

OK so I just googled "glue records" looks like the registrar for some reason has the wrong IPs, will investigate more....

6

Jup, your analysis is correct: both the ns1.themindfactory.com. and ns2.themindfactory.com. hostnames resolve to 184.107.4.207 (which I assume is correct), but the .com nameservers "glue" 72.5.214.239 and 66.11.237.150 respectively.

By the way, having a single IP address for both nameserver hostnames is probably not a good idea. I do it myself for my own stuff, but that's nothing serious (nobody looks at it).

4 Likes
7

yeah I know, its for me too :slight_smile: the registrar has been told the name servers so not sure whats up with them

8

Either:

  • they are lagggging with thier update
  • you updated the wrong place

Global DNS shows:

nslookup -q=ns shibumidesignstudios.com 192.12.94.30
shibumidesignstudios.com nameserver = parking2.whc.ca
shibumidesignstudios.com nameserver = parking1.whc.ca
3 Likes
9

thanks! only been 2+ weeks!

1 Like
10

Are you sure you didn't click: "Park this domain (for me)"
[or something just as useless as that]

3 Likes
11

nope, they are set correctly in their interface

12

I'd change to another registrar.
[they are a dime a dozen]

3 Likes
13

crazy, been doing this since about 1995 and have had 100's of domains, etc.... never.....

14

never ....
? ? ? ?
... have you seen an IP of a root com DNS server ?
nslookup -q=ns com

Name:    e.gtld-servers.net
Address: 192.12.94.30

I guess it would have looked better as:
nslookup -q=ns shibumidesignstudios.com e.gtld-servers.net
[but I'm a numbers kinda guy]

2 Likes
15

I'm not sure how registars "tell" the nameservers upstream what the glue IP address should be. Maybe telling the registar the nameservers isn't enough? Or perhaps when you did, the IP addresses of the nameservers were different at that time?

3 Likes
16

not sure why it quoted that :slight_smile: totally aware of the root ips... when I saw you use it i was like ok.. that I think is verisign :slight_smile: I meant 'never....' have i had issues :slight_smile:

1 Like
17

So to be clear, when you tell the reg that your name servers are X and Y, this is then used as "the glue"

18

No, the "glue" is the IP address associated with those nameservers at the "level" upstream.

Every nameserver that delegates a certain zone to another nameserver has "NS" resource records for those downstream nameservers. But if there weren't any glue records, it would take an entire round of resolving to resolve the IP addresses of those downstream nameservers. This can be streamlined by adding "glue" records as additional resource records to the initial response. You can see these when you use dig and request the .com zone for your domain:

osiris@erazer ~ $ dig @h.gtld-servers.net shibumidesignstudios.com

; <<>> DiG 9.16.27 <<>> @h.gtld-servers.net shibumidesignstudios.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1205
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;shibumidesignstudios.com.	IN	A

;; AUTHORITY SECTION:
shibumidesignstudios.com. 172800 IN	NS	ns2.themindfactory.com.
shibumidesignstudios.com. 172800 IN	NS	ns1.themindfactory.com.

;; ADDITIONAL SECTION:
ns2.themindfactory.com.	172800	IN	A	66.11.237.150
ns1.themindfactory.com.	172800	IN	A	72.5.214.239

;; Query time: 50 msec
;; SERVER: 2001:502:8cc::30#53(2001:502:8cc::30)
;; WHEN: Wed Feb 15 21:29:31 CET 2023
;; MSG SIZE  rcvd: 136

osiris@erazer ~ $

The part in the "AUTHORITY SECTION" is mandatory. In the "ADDITIONAL SECTION" you can see the (incorrect) glue records, which saves a resolving nameserver an entire round of resolving the IP addresses for ns1.themindfactory.com and ns2.themindfactory.com, which speeds up the process.

Note that in some situations glue is MANDATORY. E.g., like in this kind of response:

;; QUESTION SECTION:
;example.com.	IN	A

;; AUTHORITY SECTION:
example.com. 172800 IN	NS	ns2.example.com.
example.com. 172800 IN	NS	ns1.example.com.

;; ADDITIONAL SECTION:
ns2.example.com.	172800	IN	A	198.51.100.35
ns1.example.com.	172800	IN	A	203.0.113.68

Here you can see that without the glue, resolving the address example.com would FAIL, as without the glue, a circular resolving problem would arise. Because the authorative nameservers for example.com are within the same zone. Without the glue, ns1.example.com (or ns2) would never be resolvable and thus nothing from the entire example.com would be.

4 Likes
19

;; AUTHORITY SECTION:
shibumidesignstudios.com. 172800 IN NS ns2.themindfactory.com.
shibumidesignstudios.com. 172800 IN NS ns1.themindfactory.com.

;; ADDITIONAL SECTION:
ns2.themindfactory.com. 172800 IN A 66.11.237.150
ns1.themindfactory.com. 172800 IN A 72.5.214.239

So then where did they get the 66.xxx and 72.xxx ips from?? as they are not correct....

20

You probably should ask your registrar.

3 Likes