This happens if you have nameservers on different TLD (domain.com for example with nameserver ns.domain.org.)
INFO: GLUE was not sent when I asked your nameservers for your NS records. This cases an extra A record lookup in order to get the IPs of your NS records. The nameservers without glue are: 157.53.224.1 45.54.76.1
You can fix this for example by adding A records to your nameservers for the zones listed above.
Is this anyone can do, somewhere in their deSEC account, or does it require access to deSEC’s nameserver settings? I am a bit confused on how this “Glue” works.
Appreciate your feedback Peter.
While there is no way for me to specifically measure the latency of a DNS resolve with and without “glue”, I can offer the timings it takes to send a UDP packet** to a domain such as google.com
compared to one using deSEC DNS servers:
** http3check.net : Packet RX - This value represents the time between the first packet sent and the first packet received (measured in milliseconds).
I am sure there are other factors in play, yet the discrepancy is not insignificant at more than 10x latency.
Very much appreciate deSEC services, which is why I ask you to test this patch/workaround, for you are in a much more capable position to do so, than us users.
I would expect that the DNS is out of the picture by the time the first packet is sent to the web server, so DNS latency is unlikely to be the cause of that discrepancy.
Google achieves low latency by scattering their servers everywhere so that clients have only a short distance (network-wise) to the nearest server. If you’re testing against a server that isn’t also located close to the client, you can’t expect similarly low latency.
For example, 100ms is just the “line of sight” signal round trip time between Germany and California, without any processing time from routers and servers. A roundtrip time of just under 2ms like in one of the Google connections means the server is within 200km of the client.
Appreciate the explanation, and while I was not expecting Google level latency, lowering it at least closer to 100ms would already be ideal. As I specified, for sure there are other factors - like the ones you mentioned - yet this was the closest test someone from the outside (of deSEC) could provide.
Bottom line: if there is something, any setting that could be added - such as this GLUE record - in order to lower latency, it is worth looking into, don’t you think?
What glue records do is to allow the TLD’s servers to send extra information in their response to the query for the example.com zone - to send the IP address that’s configured for the name servers, too. It’s not authoritative, but it’s a pointer to the authoritative servers, allowing for the loop to be resolved.
There appears to be a misunderstanding about when to use glue records. They are not used to include whatever information may be needed during resolution.
Otherwise, why stop at the nameserver A/AAAA records? You could just as well add the records of your actual DNS query name target in the parent domain, which would save you “an extra record lookup in order to get them” by the usual procedure of following the resolution chain. (This would effectively be flattening the child into the parent zone.)
Glue records are used in particular when the nameservers for a delegation have names that are under that delegation, so that there is a cyclic dependency; glue breaks that catch-22. It’s actually why it’s called “glue”.
In its definition of “glue records”, RFC 9499 distinguishes between three different kinds of relationships that can appear between a delegation and an associated nameserver hostname:
in-domain: “a name server whose name is either subordinate to or (rarely) the same as the [delegation name]” (such as, using ns1.example.com for the example.com delegation)
sibling: “a name server whose name is either subordinate to or (rarely) the same as […] the parent” (such as, using ns1.provider.com for the example.com delegation)
unrelated: “a name server that is […] not part of the same [parent domain]” (such as, using ns1.example.net for the example.com delegation)
RFC 9471 deals with when to use glue. In-domain glue is required to resolve a cyclic dependency (Section 3.1). Sibling glue is optional (Section 3.2), but supported by some nameservers. It is sometimes required when two domains use nameservers of each other (creating another cyclic dependency). Crucially, unrelated glue is not mentioned at all.
So, some final thoughts:
What you brought up is “unrelated glue”, for which there is no deployment recommendation.
This is in stark contrast to the claim of the intoDNS checker, which suggests there is an issue “if you have nameservers on different TLD”. In fact, this is the normal situation.
Glue is sent by the parent domain, not by us (because it is sent along with the delegation). If we wanted to get glue served for unrelated domains (i.e., not under the same TLDs as our nameservers), we would have to convince all other TLD operators in the world to add our glue, and also keep it updated if our IP addresses change. That’s a huge operational dependency, and it seems unwise to take that risk.
In the making of that RFC 9471, there was a lot of discussion about the benefits of glue that is not strictly necessary for resolving cyclic dependencies. It was found that there is often more harm than good (mainly due to the aforementioned operational dependency).
A DNSSEC-validating resolver will not use optional glue anyway, as records sent by the parent are not validateable (because they have no signatures, with the exception of the DS record). Given that our DNS service is targeted at DNSSEC use, optional glue will make no difference.
In addition to the above considerations, the previous objection to the latency argument still holds, because many DNS resolvers will have our IP addresses cached so that the latency benefit would be questionable.
If there’s a latency problem, that’s best addressed by reducing actual roundtrip times. Perhaps our anycast routing could be optimized; if you think that is the case, please send a traceroute from the problematic vantage point so that we can investigate. Also, donations to support additional anycast locations would help.
As pointed out by @GenericUser, the roundtrip statistics you showed are for some web server, not for deSEC nameservers, so they don’t apply. I reiterate that what we really need is data that applies to the actual DNS use case.
