25 Úno
2014
25 Úno
'14
12:25
Why does bind behave differently ?
There must be a reason ?
On 25 Feb, 2014, at 18:54, Johan Ihrén <johani(a)johani.org> wrote:
Hi,
On 24 Feb 2014, at 16:17 , Ondřej Surý <ondrej.sury(a)nic.cz> wrote:
> A while back i only had
udrtld.net hosted on a and b. B was down and A had a hardware failure.... Despite
registering a, b, c, d, f as records on the root servers, they stopped resolving hk.com
after the records expired on the c d and f. The root server did not give any IP's for
udrtld.net and the information they held varied.
Assuming I understand the details of what you're describing here... this is how DNS
is designed to work. Nothing wrong here.
> Yes I undestand that udrtld.net would stop
resolving as any authorative DNS servers but the root server GLUE should have told global
resolvers of the IP of c, d, f... They didn't. The udrtld.net domain went down as
fixed it promptly after. Nothing I did would fix it until a got A back online.
You mean the .net servers, not root servers. Well, they did provide the glue in the
referrals, but that didn't matter, because the udrtld.net servers had expired the
zone.
> Moral is don't rely on the root servers
for IPs, you can't if you have a misconfiguration and you better server your own too.
Don't assume what a resolver will do.
This is correct. 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.
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).
+1
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.
I completely agree with this and AFAIK Knot-DNS is doing the right thing.
Regards,
Johan