24 Úno
2014
24 Úno
'14
13:40
On 2/24/2014 7:00 PM, knot-dns-users-request(a)lists.nic.cz wrote:
Date: Mon, 24 Feb 2014 09:16:27 +0100
From: Jan Kadlec <jan.kadlec(a)nic.cz>
To: "Maren S. Leizaola" <leizaola(a)hk.com>
Cc: knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] GLUE and additional records.
Message-ID:
<1393229787.1717.12.camel(a)labs.jan.kadlec.ws.eth.1.office.nic.cz>
Content-Type: text/plain; charset="UTF-8"
Hello Maren and thanks for your report. Knot normally sends glue records
in additional section, it seems as if you might have encountered a bug.
Could you provide more data? One NS, A (AAAA) combination and a dig
output for this combination should be enough. Thanks again, Jan.
The environment is as follows. I host hk.com on 6 DNS servers, right now
5 are bind and one is Knot. hk.com's name servers are
a,b,c,d,e,f.udrtld.net b is running Knot.
Try this link www.intodns.com/hk.com
This reports that B provides no glue. Please ignore the errors on f.
i've yet not setup urdtld.net on it.
dig -cA hk.com @b.udrtld.net
when I do a
dig -cA hk.com @a.udrtld.net
Am I making any mistakes here?
Maren.
24 Úno
24 Úno
14:11
New subject: knot-dns-users Digest, Vol 28, Issue 9
On 24. 2. 2014, at 13:40, Maren S. Leizaola <leizaola(a)hk.com> wrote:
On 2/24/2014 7:00 PM,
knot-dns-users-request(a)lists.nic.cz 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
-------------------------------------------
Date: Mon, 24 Feb 2014 09:16:27 +0100
From: Jan Kadlec <jan.kadlec(a)nic.cz>
To: "Maren S. Leizaola" <leizaola(a)hk.com>
Cc: knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] GLUE and additional records.
Message-ID:
<1393229787.1717.12.camel(a)labs.jan.kadlec.ws.eth.1.office.nic.cz>
Content-Type: text/plain; charset="UTF-8"
Hello Maren and thanks for your report. Knot normally sends glue records
in additional section, it seems as if you might have encountered a bug.
Could you provide more data? One NS, A (AAAA) combination and a dig
output for this combination should be enough. Thanks again, Jan.
The environment is as follows. I host hk.com on 6 DNS servers, right now 5 are bind and
one is Knot. hk.com's name servers are a,b,c,d,e,f.udrtld.net b is running Knot.
Try this link www.intodns.com/hk.com
This reports that B provides no glue. Please ignore the errors on f. i've yet not
setup urdtld.net on it.
dig -cA hk.com @b.udrtld.net
when I do a
dig -cA hk.com @a.udrtld.net
Am I making any mistakes here?
16:04
New subject: GLUE and additional records
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
-------------------------------------------
16:17
New subject: GLUE and additional records
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
-------------------------------------------
25 Úno
25 Úno
11:54
New subject: GLUE and additional records
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
12:25
New subject: GLUE and additional records
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
13:31
New subject: GLUE and additional records
Hi Maren,
Why does bind behave differently ?
There must be a reason ?
I think it is mostly a question of legacy constraints. I.e. with a user base as gigantic
as there is for BIND9 they have to be really, really ultra careful not to change expected
behaviour unless it is clearly "a bug".
Look at the perhaps most obvious difference, BIND9 being by default both recursive and
authoritative. That's clearly identified as, umm, not a great thing. But it really
doesn't matter whether that is good or bad, because ISC just Can Not change the
default, because that would cause stuff to break and users to be upset.
So new implementations like Knot-DNS really has a much simpler situation when it comes to
"do it right" vs. "do it the way it was done 15 years ago".
Regards,
Johan
26 Úno
26 Úno
10:05
New subject: GLUE and additional records
On 2/25/2014 8:31 PM, Johan Ihrén wrote:
I think it is mostly a question of legacy constraints.
I.e. with a user base as gigantic as there is for BIND9 they have to be really, really
ultra careful not to change expected behaviour unless it is clearly "a bug".
Look at the perhaps most obvious difference, BIND9 being by default both recursive and
authoritative. That's clearly identified as, umm, not a great thing. But it really
doesn't matter whether that is good or bad, because ISC just Can Not change the
default, because that would cause stuff to break and users to be upset.
So new implementations like Knot-DNS really has a much simpler situation when it comes to
"do it right" vs. "do it the way it was done 15 years ago".
Regards,
Johan
Johan,
I know bind maybe wrong, but they are the main dns server
out there. I do not wish to use bind as you have a much better server
but I would like Knot to behave like bind when it comes to Glue records.
They day bind stops delivering the Glue records we can turn it off. I am
adverse to risk in this situation and I prefer to follow the herd.
I am not asking you to change how the default Knot works. Would it be
possible that you give an option which you can highly discourage people
to use which allows to copy bind's behavior?
Regards,
Maren.
11:08
New subject: GLUE and additional records
Maren,
On 26. 2. 2014, at 10:05, Maren S. Leizaola <leizaola(a)hk.com> wrote:
Johan,
I know bind maybe wrong, but they are the main dns server out there. I do not
wish to use bind as you have a much better server but I would like Knot to behave like
bind when it comes to Glue records. They day bind stops delivering the Glue records we can
turn it off. I am adverse to risk in this situation and I prefer to follow the herd.
I am not asking you to change how the default Knot works. Would it be possible that you
give an option which you can highly discourage people to use which allows to copy
bind's behavior?
I am sorry, but what you are really asking is to add an option to add useless records into
the response just for the cosmetic reasons, since those records won't be used by any
resolver out there. Well unless the resolver is really outdated and thus wrong, insecure
and susceptible to poisoning attacks.
We (as the CZ.NIC team behind) would be willing to modify the Knot DNS behaviour if we had
a clear case when the default behaviour causes real operational problems. And we are not
aware of such scenario, because even the really old and outdated resolvers are able to
cope with the response and request the IP addresses of the resolvers.
I am sorry to turn you down like this, but we would like to make decisions based on the
DNS protocol operations and not based on how the (k)dig output looks like. And we are
quite sure that we got this right.
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
-------------------------------------------
23:57
New subject: GLUE and additional records
Ondřej Surý wrote:
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).
Actually, the strict checking that you describe was introduced long
before the Kaminsky attack (2008). Maybe you are thinking of the
Kashpureff attack (1997)? E.g., RFC 3833 § 2.3 explicitly mentions this
scenario.
I think the problem here is that the hk.com nameservers are *also*
nameservers for udrtld.net, and the BIND servers are following the
"unless" clause in RFC 2181 § 6.1, "A server for a zone should not
return authoritative answers for queries related to names in another
zone, which includes the NS, and perhaps A, records at a zone cut,
unless it also happens to be a server for the other zone." Note it says
"should not... perhaps... unless". That is a much looser requirement
than "must" :-)
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 don't know that there's anything wrong *in principle* with a recursive
server noticing that .com and .net (or any other set of zones) are
served by exactly the same nameservers and accepting glue records from
within that set of zones, other than that such an implementation would
probably be more complex and require more memory.
--
Robert Edmonds
edmonds(a)debian.org
3718
days inactive
3720
days old
9 comments
4 participants
participants (4)
-
Johan Ihrén -
Maren S. Leizaola -
Ondřej Surý -
Robert Edmonds