24 Úno
2014
24 Úno
'14
16:04
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.
Maren.
On 2/24/2014 9:11 PM, Ondřej Surý wrote:
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
-------------------------------------------