One nameserver not sending out glue

N

Nickske00

Verified User
Joined
Nov 30, 2015
Messages
88
Hi guys,

Couple of months ago I moved my main server to a new dedicated server running Debian 11.
I always have had my own nameservers (three servers, different places) but since the move intodns reports an informational message I never had before.

intoDNS: buggedbrain.com - check DNS server and mail server health

intoDNS: Checking health and configurtion of DNS server and mail server for domainbuggedbrain.com.
intodns.com intodns.com
INFO: GLUE was not sent when I asked your nameservers for your NS records.This is ok but you should know that in this case an extra A record lookup is required in order to get the IPs of your NS records. The nameservers without glue are:
78.46.78.132
You can fix this for example by adding A records to your nameservers for the zones listed above.
Click to expand...

I understand this is an informational message, and an extra A lookup isn't that expensive these days, but we all want to deliver a perfect service. ;) So I've been investigating this whole weekend and didn't find a solution...

I suppose into dns does a dig query to the nameservers to find out everything it displays? I discovered the Debian 11 servers has less info in the additional section of the response.

ns1.buggedbrain.com
dig @ns1.buggedbrain.com buggedbrain.com NS

; <<>> DiG 9.16.23 <<>> @ns1.buggedbrain.com buggedbrain.com NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24225
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 19ab739b81ee49100100000061adf556aa36b94e16811bfd (good)
;; QUESTION SECTION:
;buggedbrain.com. IN NS

;; ANSWER SECTION:
buggedbrain.com. 3600 IN NS ns1.buggedbrain.com.
buggedbrain.com. 3600 IN NS ns2.buggedbrain.com.
buggedbrain.com. 3600 IN NS ns3.buggednetworks.eu.

;; ADDITIONAL SECTION:
ns1.buggedbrain.com. 3600 IN AAAA 2a01:4f8:120:3493::2
ns2.buggedbrain.com. 3600 IN AAAA 2a02:c207:2025:7385::1
ns1.buggedbrain.com. 3600 IN A 78.46.78.132
ns2.buggedbrain.com. 3600 IN A 207.180.214.48

;; Query time: 34 msec
;; SERVER: 2a01:4f8:120:3493::2#53(2a01:4f8:120:3493::2)
;; WHEN: Mon Dec 06 12:34:45 Romance (standaardtijd) 2021
;; MSG SIZE rcvd: 231

ns2.buggedbrain.com
dig @ns2.buggedbrain.com buggedbrain.com NS

; <<>> DiG 9.16.23 <<>> @ns2.buggedbrain.com buggedbrain.com NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4790
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 7
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 6efe0418c11a99b548bfd80261adf5d77ab5cea62193d12a (good)
;; QUESTION SECTION:
;buggedbrain.com. IN NS

;; ANSWER SECTION:
buggedbrain.com. 3600 IN NS ns2.buggedbrain.com.
buggedbrain.com. 3600 IN NS ns3.buggednetworks.eu.
buggedbrain.com. 3600 IN NS ns1.buggedbrain.com.

;; ADDITIONAL SECTION:
ns1.buggedbrain.com. 3600 IN AAAA 2a01:4f8:120:3493::2
ns2.buggedbrain.com. 3600 IN AAAA 2a02:c207:2025:7385::1
ns3.buggednetworks.eu. 3600 IN AAAA 2605:a140:2037:7597::1
ns1.buggedbrain.com. 3600 IN A 78.46.78.132
ns2.buggedbrain.com. 3600 IN A 207.180.214.48
ns3.buggednetworks.eu. 3600 IN A 209.126.6.143

;; Query time: 35 msec
;; SERVER: 2a02:c207:2025:7385::1#53(2a02:c207:2025:7385::1)
;; WHEN: Mon Dec 06 12:36:54 Romance (standaardtijd) 2021
;; MSG SIZE rcvd: 275

ns3.buggednetworks.eu
dig @ns3.buggednetworks.eu buggedbrain.com NS

; <<>> DiG 9.16.23 <<>> @ns3.buggednetworks.eu buggedbrain.com NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37671
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 7
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: c3a31828a013f83cc30942d761adf5fb75fc789506838b7b (good)
;; QUESTION SECTION:
;buggedbrain.com. IN NS

;; ANSWER SECTION:
buggedbrain.com. 3600 IN NS ns3.buggednetworks.eu.
buggedbrain.com. 3600 IN NS ns1.buggedbrain.com.
buggedbrain.com. 3600 IN NS ns2.buggedbrain.com.

;; ADDITIONAL SECTION:
ns1.buggedbrain.com. 3600 IN AAAA 2a01:4f8:120:3493::2
ns2.buggedbrain.com. 3600 IN AAAA 2a02:c207:2025:7385::1
ns3.buggednetworks.eu. 3600 IN AAAA 2605:a140:2037:7597::1
ns1.buggedbrain.com. 3600 IN A 78.46.78.132
ns2.buggedbrain.com. 3600 IN A 207.180.214.48
ns3.buggednetworks.eu. 3600 IN A 209.126.6.143

;; Query time: 120 msec
;; SERVER: 2605:a140:2037:7597::1#53(2605:a140:2037:7597::1)
;; WHEN: Mon Dec 06 12:37:31 Romance (standaardtijd) 2021
;; MSG SIZE rcvd: 275

As you can see the additional section of ns2 and ns3 contain all ip addresses for all nameservers, but ns1 only contains those for ns1 and ns2. I think this is what intodns is pointing out?

Bind/Named versions:
ns1: 9.16.22
ns2: 9.11.4
ns3: 9.11.5

These are all standard DA setups, sharing zones through multi server. Named configuration hasn't been changed. So I can only suspect they changed something in bind between 9.11 and 9.16... But I can't seem to pin it down, been searching through the changelog but found nothing. Been searching on google, but it is hard to find (recent) discussions about this.

I tried setting 'minimal-responses no;' in the named config, but this didn't help. Only thing that helped was setting 'allow-recursion { any; };' but as everyone says this is a security risk, this isn't a solution.

So does anyone here have an idea as to what has changed in bind to be less informative?

Like I said at the beginning of this post, an extra A lookup isn't the end of the world, but I like to know what has changed, so if someone can point me in the right direction I would be happy. ;)
 
78.46.78.132 is ip address of ns1.buggedbrain.com
Be sure that this IP is in your DNS records as an A record

Example: ns1.buggedbrain.com. A 78.46.78.132

However I have checked your NS setting with DNS Inspect (Better tool than IntoDNS) and didn't see really problems with your glue

Report for buggedbrain.com

www.dnsinspect.com www.dnsinspect.com
 
Last edited:
As I said, everything works. But as you can see from my own queries, there is a change between bind versions... I'm asking if anyone has an idea where to look for this change. ;)
 
DA nameservers do not send GLUE records. GLUE records are only send by your registrar. If you want GLUE records, ask your registrar to set GLUE records to your nameservers.
A Glue Record is the IP Address of a name server at a domain name registry.

You can also see this at the result page of the link Active8 pointed to, saying the parent nameservers are offering the GLUE.
Also check the A records he mentioned

Some registrars might not provide GLUE records, but that is not a big thing, as it states, it only requires 1 extra lookup, which is not a big deal.
 
They do send out GLUE as you can see in the ADDITIONAL section of the answers. ;)
 
Nickske00 said:
But as you can see from my own queries, there is a change between bind versions.
Click to expand...
Yes That is really odd, according Debian website is 9.16.x branch the latest version.
I'm not familiar with Debian OS , maybe has to with the way the bind is updated (by OS or DA) I'm not certain
 
No they don't. Unless you are the registrar yourself. ;)
ns1.com

What are Glue Records? | IBM

DNS resolution is an iterative process where a recursive resolver attempts to look up a domain name using a hierarchical resolution chain.
ns1.com ns1.com

Which additional answers you mean? Can you give an example? I don't see it.
Edit: But if you set your nameservers with your registrar correctly it should be glue records, however I encountered some registrars in the past where one has to give them the order to set the glue records.
Anyway, you do not set them in DA yourself.

Anyway it's odd, because compare a check between buggedbrain.com and buggednetworks.eu then in both cases it says in the "missing Glue" section:
OK. Parent name servers are offering glue for domain's name servers
Click to expand...

But with buggednetworks.eu in the first section you can see this:
Code: 
ns1.buggedbrain.com. TTL=86400            [NO GLUE4]            [NO GLUE6]
ns2.buggedbrain.com. TTL=86400            [NO GLUE4]            [NO GLUE6]
So in this part no glue is seen for ipv4 and ipv6.

There is a difference between both domains in this result, this is also odd, right?
I don't know if that has anything to do with the bind change.
 
Maybe this is a cause:

That one also says:
Oops! The parent servers don't have A records for each of your nameservers!
And here also ns3 (like with intodns) does not have a Glue. Parent servers are at your registrar, I think you might need to contact them to doublecheck things.
However, feel free to try other solutions.
 
Richard G said:
Which additional answers you mean? Can you give an example? I don't see it.
Click to expand...

NS1:
Code: 
;; ADDITIONAL SECTION:
ns1.buggedbrain.com. 3600 IN AAAA 2a01:4f8:120:3493::2
ns2.buggedbrain.com. 3600 IN AAAA 2a02:c207:2025:7385::1
ns1.buggedbrain.com. 3600 IN A 78.46.78.132
ns2.buggedbrain.com. 3600 IN A 207.180.214.48

NS2 & NS3:
Code: 
;; ADDITIONAL SECTION:
ns1.buggedbrain.com. 3600 IN AAAA 2a01:4f8:120:3493::2
ns2.buggedbrain.com. 3600 IN AAAA 2a02:c207:2025:7385::1
ns3.buggednetworks.eu. 3600 IN AAAA 2605:a140:2037:7597::1
ns1.buggedbrain.com. 3600 IN A 78.46.78.132
ns2.buggedbrain.com. 3600 IN A 207.180.214.48
ns3.buggednetworks.eu. 3600 IN A 209.126.6.143

The glue is set correctly at the registar. The reason you are getting the no glue message at the root servers is because it are different tld's.
.com only has glue for ns1 & ns2 and .eu only has glue for ns3. ;)

Also see https://serverfault.com/questions/142344/how-to-test-dns-glue-record
You should get back the correct list of NS records in the "AUTHORITY SECTION". For any name servers that have correctly configured glue you should see those glue A (and/or AAAA) records appear in the "ADDITONAL SECTION".
Click to expand...

So, the additional section you get back from your own nameserver contains the glue in the additional section of the response. :)

But for some reason bind stopped adding glue for out-of-zone nameservers in a recent version...
 
Nickske00 said:
Also see https://serverfault.com/questions/142344/how-to-test-dns-glue-record
Click to expand...
Ah.... I see where the misunderstanding is. It's mostly on my side. I thought sending to the nameservers, like setting up c.q. adding glue records.... stupid me. ?
But you were talking about sending out as response to a request. So I think we're clear on that now, sorry for the confusion.

l'll send you a pm if you're oke, because I've seen something else, but don't know if that will be of help and I don't want to disturb other responses.
 
Can you have glue across different TLDs?

buggedbrain.com is missing glue for the ns3.buggednetworks.eu nameserver.

i.gtld-servers.net doesn't have authority to return IP addresses for .eu domain names.
 
Did you solve this?

When I upgraded to Cloudlinux 9, I notice that intoDNS now states:
INFO: GLUE was not sent when I asked your nameservers for your NS records.This is ok but you should know that in this case an extra A record lookup is required in order to get the IPs of your NS records.

for .com domains where my nameservers are .net

With previous Cloudlinux versions, the additional section provided those A records.

I'm wondering if there is a named setting that I can set so bind again provides the additional ns A record glue for domains where tld is different than nameserver tld
 
Nope, never solved this. And I didn't find a bind setting that would solve this. Only thing that seemed to solve it was allowing recursion for everyone, but as this is not good I gave up.. :)
 
ocean-interest said:
I'm wondering if there is a named setting that I can set so bind again provides the additional ns A record glue for domains where tld is different than nameserver tld
Click to expand...
Short answer: no. Glue records are to be created by the registrar, you can't make glue records yourself.

However, be aware that intodns.com is not always 100% accurate sometimes. This week it gave an error that one ip from 1 nameserver from somebody I was helping, was not responding. While in fact the nameserver was responding on both ip and dns name and also answered dns requests.

Next to that, since it's only an extra A record, you can safely ignore that. Only thing you can do is doublecheck with your registrar that the glue records still exists correctly.
 
Glue is set at the registrar of your domain, so its them that would send the "Glue".

I'll give you an example, you want to go to myserver.com and the nameservers are ns1.myserver.com and ns2.myserver.com. When DNS queries the nameservers, it first needs to resolve myserver.com. - myserver.com's nameservers are ns1.... & ns2.... you see where i'm going here? It creates an infinite loop as the nameservers won't resolve without the domain name, and that won't resolve without authoritative nameservers. In short it's totally unresolvable.

To break this cycle, the registrar creates glue records, which effectively "Glue" an IP to each nameserver. This way, when your DNS queries ns1 & ns2, instead of being sent on an unresolvable loop, it sends your DNS the Glue, which is the IP addresses of the authoritative nameservers where you would have all your A, AAAA, TXT, NS etc records, bypassing the NS lookup on your DNS for A records that would never happen.

If you've got different TLDs for nameservers, across different ASNs for redundancy, for example ns1.mydomain.com, ns2.mydomain.co.uk, ns3.mydomain.uk, each nameserver has to be resolveable in their own right as .com registry has no authority to send out glue for uk, so you'd have to set the glue records for each TLD at their respective registries. The registries will then send out the glued IP to resolve. Wherever each IP is set to resolve, you'll need the A record set as the correct NS IP, and the NS record set as well.

If you want to use external nameservers as well as your glued (for redundancy) which is a good idea, it's a little harder as you have to host a master zone file on your main server with the DNS records of it's glued NS IPs and all other records, along with the external nameservers you wish to use as well. You'd have to configure the external nameserver servers as slaves and pull in domain.com's records via axfr so if DNS hits ns3.domain.eu, that server can pull in the zone file for domain.com and send out the A record for the site.

Sorry for long explanation but DNS is magic when it works, but fickle when you miss something out.

My advice, keep it simple unless it's mission critical to go all out with this.

Good luck!
 
As far as I know the registrar will never send glue for a different TLD -- so if you have a domain.com using nameservers ns1.host.net and ns2.host.net, the registrar won't send glue for the nameservers.

I still have one server with the old version of named (BIND 9.8.2) that was doing some magic, but I don't know how it was doing it -- it just always did. If the server had both host.net and domain.com on it, bind on that server (and on my previous servers for a decade) would add an additional section for the ns1.host.net and ns2.host.net nameserver IPs. And thus for a decade, intodns.com didn't note that GLUE was not sent when I asked your nameservers for your NS records. Recursion was off for external zones, but it's as if recursion was allowed, the servers were authoritative for both host.net and domain.com, but I don't see a new setting either that allows the new bind to do this.
 
Thinking a lot about this, I've used intodns.com for years and years and love it, but maybe this is a case where this line was always misleading.

As was said, the intent of the registrar is to provide nameserver glue to prevent loops, not necessary when domain.com uses nameservers not at domain.com, not to save a DNS lookup.

That second glue check at intodns.com made me think that in the case of domain.com using ns1.host.net and ns2.host.net the additional section would save an extra lookup, so I was worried I would now slow things down a tiny bit by not having that with the new bind version.

But how would it ever have actually saved a lookup?

If domain.com uses ns1.host.net and ns2.host.net:
1: Client queries root servers
2: Root servers refer to gtld servers
3: Client queries gtld servers
4: Gtld servers provide nameserver hostnames ns1.host.net and ns2.host.net
5: Client performs dns lookup for ns1.host.net and/or ns2.host.net starting from registrar root servers (does it lookup the first, a random ns1 OR ns2, or both at this step 5?)
Either way, client is going to look up IP for nameserver ns1.host.net or ns2.host.net before being able to contact ns1.host.net or ns2.host.net
6.) Then Client queries either ns1.host.net or ns2.host.net
7.) ns1.host.net or ns2.host.net provides response including A record of domain.com. It was at step 7 that BIND previously provided the additional section with IPs for nameservers ns1.host.net and ns2.host.net that it no longer provides.

So thinking about this tonight, it seems like the client would always have the IP for either ns1.host.net or ns2.host.net from a dns lookup BEFORE ns1.host.net or ns2.host.net is queried. The intodns.com check line made me think that the additional section glue could save a dns lookup here, but I'm not sure how that could have ever saved a dns lookup. If the ns1 or ns2 responds, it will provide domain.com's a record so the other ns1. or ns2. isn't needed. And ns1. or ns2. could never be queried to get the additional section if their IP isn't already known. So maybe that extra glue check was actually misleading all those years in that no extra dns query could have been saved in the past???
 
You must log in or register to reply here.
Back
Top