lists.nic.czについて、ここに記述してください。

[knot-dns-users] GLUE and additional records

https://lists.nic.cz/pipermail/knot-dns-users/2014-February/000389.html

Johan Ihrén johani at johani.org 

Do not rely on root servers for things they are not authoritative for,
or even more general: do not rely on any authoritative server for things it is not authoritative for.

DNS simply doesn't work that way.

Referrals are "hints", they can never be a substitute for authoritative information,
regardless of what would be convenient to the resolver.

----
https://lists.nic.cz/pipermail/knot-dns-users/2014-February/000388.html

Ondřej Surý ondrej.sury at nic.cz
Mon Feb 24 16:17:22 CET 2014

If the recursive DNS server emit DNS query for hk.com, the content of the ADDITIONAL section in the DNS response will be ignored unless its contents are also under hk.com (that's the bailiwick).

This strict checking was introduced after Kaminsky attack to increase resilience of the DNS.
The correctly behaving resolver should automatically go and get the IP addresses
for a.udrtld.net, b.udrtld.net, ...  
The resolver can accept those records if it already knows that X.udrtld.net servers are also responsible for udrtld.net domain name (but the resolver doesn't know that until he traverses from root zone to X.udrtld.net and at that time the records are cached, so there's only little to gain by sending the GLUE within hk.com DNS response).

The problem you are mentioning above has nothing to do with GLUE records returned (or not returned)
by the DNS servers.

Also the GLUE returned by .com nameservers (X.gtld-servers.net) is just a coincide of the fact
that .com and .net are run by the same company.  
And strictly speaking they doesn't have to be there since they will (or should be) be ignored by the recursive servers.

Ondrej


https://lists.nic.cz/pipermail/knot-dns-users/2014-February/000393.html