24 Úno
2014
24 Úno
'14
16:17
Maren,
On 24. 2. 2014, at 16:04, Maren S. Leizaola <leizaola(a)hk.com> wrote:
Ondrej,
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.
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.
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.
| dig www.rfc1925.org @pagan.rfc1925.org
I see this work, like on the dns of nic.cz my case is different. In my case I am have to
use one domain to host all the zones we manage and that domain is different from all the
zones.
Nope. The case isn't different[1] from yours.
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
1. and those are not nic.cz servers, this is my personal box
Maren.
On 2/24/2014 9:11 PM, Ondřej Surý wrote:
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
Hi Maren,
as far as I remember the {a,b,c,d,e,f}.udrtld.net would be ignored by the (good behaving)
recursive servers because they don't come in the bailiwick of the queried zone.
So, since those records are not used anyway, we are slimming down the responses.
You may compare responses to:
dig www.sury.org @pagan.rfc1925.org
- no GLUE since pagan.rfc1925.org is not in the bailiwick of www.sury.org
with
dig www.rfc1925.org @pagan.rfc1925.org
- GLUE added since pagan.rfc1925.org is in the bailiwick of (www.)rfc1925.org and can be
used
You can read more about cache poisoning attacks, f.e. here:
http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug
Or you can try yourself with unbound recursive server, set the verbosity to 3
(unbound-control verbosity 3), flush the zone cache (unbound-control flush_zone .) and ask
the server, you should be able to observe something like this:
Feb 24 14:00:52 unbound[16038:0] info: sanitize: removing potential poison RRset:
a.udrtld.net. A IN
Feb 24 14:00:52 unbound[16038:0] info: sanitize: removing potential poison RRset:
b.udrtld.net. A IN
Feb 24 14:00:52 unbound[16038:0] info: sanitize: removing potential poison RRset:
c.udrtld.net. A IN
Feb 24 14:00:52 unbound[16038:0] info: sanitize: removing potential poison RRset:
d.udrtld.net. A IN
Feb 24 14:00:52 unbound[16038:0] info: sanitize: removing potential poison RRset:
f.udrtld.net. A IN
in the syslog, and the recursive server will go and resolve the {a,...}.udrtld.net names
itself.
Ondrej
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------