Given this zone wtest.com:
$TTL 3600
$ORIGIN wtest.com.
@ IN SOA ns1.wtest.com. ahu.example.com. ( 2005092501
8H ; refresh
2H ; retry
1W ; expire
1D ; default_ttl
)
@ IN NS ns1
@ IN MX 10 smtp-servers.example.com.
@ IN MX 15 smtp-servers
@ IN A 9.9.9.9
* IN CNAME server1
ns1 IN A 1.2.3.4
secure IN MX 10 server1
server1 IN A 1.2.3.4
*.something IN A 4.3.2.1
When I sign this zone with ldns-signzone (1.6.12) and configure it in NSD (3.2.10), I observe (with Unbound 1.4.16):
$ unbound-host -v -C unbound-host-nsd.conf -t a www.something.wtest.com
www.something.wtest.com has address 4.3.2.1 (secure)
$ unbound-host -v -C unbound-host-nsd.conf -t any www.something.wtest.com
www.something.wtest.com ANY:
www.something.wtest.com. 3600 IN A 4.3.2.1
www.something.wtest.com. 3600 IN RRSIG A 5 3 3600 20120323092532 20120224092532 61140 wtest.com. N0nNjNk2wWpgw8MsSJkWi91L4iAZa3L6bJle4jZ7eSzybTvbmNP5X83db8bxNSErjvACC+QLbMcxg3LICb+msQ==
(BOGUS (security failure))
validation failure <www.something.wtest.com. ANY IN>: qtype_any proof failed from 10.0.2.14
Doing the same with BIND (1:9.9.0-0ubuntu0~lucid12~b1) (using dnssec-signzone):
$ unbound-host -v -C unbound-host-bind.conf -t a www.something.wtest.com
www.something.wtest.com has address 4.3.2.1 (secure)
$ unbound-host -v -C unbound-host-bind.conf -t any www.something.wtest.com
www.something.wtest.com ANY:
www.something.wtest.com. 3600 IN A 4.3.2.1
www.something.wtest.com. 3600 IN RRSIG A 5 3 3600 20120325073507 20120224073507 61140 wtest.com. BA8PEvt2bNEr6ZLiOeFJQhQO6BVrj5vTFGFs4tT6vBu5fhvIYyQh1ltzSmaxzyfe9EDMP89upcjW7AQyju9upQ==
www.something.wtest.com. 86400 IN NSEC wtest.com. A RRSIG NSEC
www.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400 20120325073507 20120224073507 61140 wtest.com. LDtcA1C2qk5hYF2qUquVDSa39v18lexViUwlIa9uLGaoDYXzndOWsA0Zbu01cvcipT1GCu6gaAFLieGL/gNdbQ==
(secure)
The difference appears to be that in the ANY case, BIND adds:
www.something.wtest.com. 86400 IN NSEC wtest.com. A RRSIG NSEC
www.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400 ….
but as far as I can see, this offers no information not already offered by:
*.something.wtest.com. 86400 IN NSEC wtest.com. A RRSIG NSEC
*.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400 …
(which is present in both responses from NSD and from BIND). Yet, unbound seems to require it.
I have sent this message to nsd-users instead of unbound-users because regardless of who is wrong here, I fear the authoritative side is where this has to be fixed, for compatibility. I also suspect I will reach the Unbound-developers via this list anyway.
RFC4035 appears not to cover the interaction between ANY and NSEC at all.
I'm looking forward to any opinions on this subject. I would be happy to repost to unbound-users if the question is deemed more suitable for that forum.
[ Quoting <peter.van.dijk@netherlabs> at 13:12 on Feb 24 in "[nsd-users] wildcard..." ]
RFC4035 appears not to cover the interaction between ANY and NSEC at
all.
That's because ANY has been loosly defined (I'm not sure there is a written
down definition) as give me the records you've got. In case you hit a
cache with an ANY query there is no guarantee what so ever that it should
all validate. I think that even for authoritative servers you can pretty
much do what you want if it receives a QTYPE = ANY.
The difference appears to be that in the ANY case, BIND adds:
www.something.wtest.com. 86400 IN NSEC wtest.com. A RRSIG NSEC
www.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400 ….
but as far as I can see, this offers no information not already offered by:
*.something.wtest.com. 86400 IN NSEC wtest.com. A RRSIG NSEC
*.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400 …
This is not the difference that matters. The issue is that NSD puts '*.something.wtest.com NSEC' in the answer section instead of the authority section.
According to unbound (and according to my reading of RFC4035), this is okay:
;; QUESTION SECTION:
;www.something.wtest.com. IN ANY
;; ANSWER SECTION:
www.something.wtest.com. 3600 IN A 4.3.2.1
www.something.wtest.com. 3600 IN RRSIG A 8 3 3600 20120308000000 20120223000000 33955 wtest.com. Cdgl41CONlwN91fMiQV6D1T2/ZaQPArjswqIR5FSnNAdTcfLuADAYJrXmBwdTTtQhfJASkZRidjfdtJOYrCgJC3d1KpeqJWnIf2mLIZtiGVkz9DxoMlXcb8O0U9moOSvPRzoWKyspQrvp6+qIM5BwqifrqbsrzSWTr4PFQehiaA=
;; AUTHORITY SECTION:
*.something.wtest.com. 3600 IN NSEC wtest.com. A RRSIG NSEC
*.something.wtest.com. 3600 IN RRSIG NSEC 8 3 3600 20120308000000 20120223000000 33955 wtest.com. BEa33+lxqfRaPw5GsM6g9TwRGcVsgA/t4oK0WMZ/sikQllvOKNfZLvbdJwTN1/yQzYhrl+xqYWuQCvMHEYCztEo9/z29sPxC/4DQrWhFmPVln1kgAPNdNIO50O8KzynbwMRq5WflvlFMrgh3B65l4I0otoqOuh9UUVYF2fGlKf4=
While this (from NSD) is not:
;; QUESTION SECTION:
;www.something.wtest.com. IN ANY
;; ANSWER SECTION:
*.something.wtest.com. 86400 IN NSEC wtest.com. A RRSIG NSEC
*.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400 20120323092532 20120224092532 61140 wtest.com. YYV4+Bv6N2VATWSx7RhOJV0PkZuvxwWLk88lU5hXVcJNvqyKkGGlJQXpy19L8ftUZJN+p5nzc+lypH06LFQAmQ==
www.something.wtest.com. 3600 IN A 4.3.2.1
www.something.wtest.com. 3600 IN RRSIG A 5 3 3600 20120323092532 20120224092532 61140 wtest.com. N0nNjNk2wWpgw8MsSJkWi91L4iAZa3L6bJle4jZ7eSzybTvbmNP5X83db8bxNSErjvACC+QLbMcxg3LICb+msQ==
While that is true, I feel that whatever an auth chooses to serve up for ANY would still consist of zero or more RRsets, which means the RRSIGs and NSECs that go with them could validate. Right?
[ Quoting <peter.van.dijk@netherlabs> at 14:37 on Feb 24 in "Re: [nsd-users] wild..." ]
> That's because ANY has been loosly defined (I'm not sure there is a written
> down definition) as give me the records you've got. In case you hit a
> cache with an ANY query there is no guarantee what so ever that it should
> all validate. I think that even for authoritative servers you can pretty
> much do what you want if it receives a QTYPE = ANY.
While that is true, I feel that whatever an auth chooses to serve up
for ANY would still consist of zero or more RRsets, which means the
RRSIGs and NSECs that go with them could validate. Right?
That would indeed be a nice thing to do if you are an auth. server. But such
a rule still doesn't help a resolver hitting a cache (which, for whatever
reason, just doesn't have the RRSIG).
[ Quoting <peter.van.dijk@netherlabs> at 14:37 on Feb 24 in "Re:
[nsd-users] wild..." ]
That's because ANY has been loosly defined (I'm not sure there
is a written down definition) as give me the records you've
got. In case you hit a cache with an ANY query there is no
guarantee what so ever that it should all validate. I think
that even for authoritative servers you can pretty much do what
you want if it receives a QTYPE = ANY.
While that is true, I feel that whatever an auth chooses to serve
up for ANY would still consist of zero or more RRsets, which
means the RRSIGs and NSECs that go with them could validate.
Right?
That would indeed be a nice thing to do if you are an auth. server.
But such a rule still doesn't help a resolver hitting a cache
(which, for whatever reason, just doesn't have the RRSIG).
Unbound does validate RRSIGs on data from ANY queries. Because the
reasoning is that it has to protect its downstream client from bogus
data. And the downstream client may be old (i.e. do ANY queries for
mail and no DNSSEC) and need to be given SERVFAIL. Thus, it validates
the data. It does not check if the data is complete (i.e. with the
NSEC) because it may indeed be partial from the cache.
It also validates data where someone does a +norec query to unbound
and its not in cache and thus a cache-referral is returned. This data
is then also validated (the 'proof' consists of checking the signatures).
Unbound takes the same view to additional section RRs. Those are not
really required always and to be validated, but to protect the client
from bogus data it will verify the RRsets there. If some a bogus, but
the message can be make secure by simply removing it, then the
additional RRset is removed (this means, an RRSIG that does not fit at
the end does not make the message bogus).
[ Quoting <wouter@NLnetLabs.nl> at 17:19 on Feb 24 in "Re: [nsd-users] wild..." ]
> That would indeed be a nice thing to do if you are an auth. server.
> But such a rule still doesn't help a resolver hitting a cache
> (which, for whatever reason, just doesn't have the RRSIG).
Unbound does validate RRSIGs on data from ANY queries. Because the
reasoning is that it has to protect its downstream client from bogus
data. And the downstream client may be old (i.e. do ANY queries for
mail and no DNSSEC) and need to be given SERVFAIL. Thus, it validates
the data. It does not check if the data is complete (i.e. with the
NSEC) because it may indeed be partial from the cache.
It also validates data where someone does a +norec query to unbound
and its not in cache and thus a cache-referral is returned. This data
is then also validated (the 'proof' consists of checking the signatures).
But what if an RRSIG expires from the cache and then you get an ANY
query? Unbound is then forced to give out an incomplete answer.
Unbound takes the same view to additional section RRs. Those are not
really required always and to be validated, but to protect the client
from bogus data it will verify the RRsets there. If some a bogus, but
the message can be make secure by simply removing it, then the
additional RRset is removed (this means, an RRSIG that does not fit at
the end does not make the message bogus).
That's interesting to read and a real nice way of dealing with the
additional section and DNSSEC.
[ Quoting <wouter@NLnetLabs.nl> at 17:19 on Feb 24 in "Re:
[nsd-users] wild..." ]
Unbound does validate RRSIGs on data from ANY queries. Because
the reasoning is that it has to protect its downstream client
from bogus data. And the downstream client may be old (i.e. do
ANY queries for mail and no DNSSEC) and need to be given
SERVFAIL. Thus, it validates the data. It does not check if the
data is complete (i.e. with the NSEC) because it may indeed be
partial from the cache.
It also validates data where someone does a +norec query to
unbound and its not in cache and thus a cache-referral is
returned. This data is then also validated (the 'proof' consists
of checking the signatures).
But what if an RRSIG expires from the cache and then you get an
ANY query? Unbound is then forced to give out an incomplete answer.
An RRSIG cannot expire on its own. If the TTL expires, then the data
it came with has expired too. If the expiration-date hits, well if
the TTL is longer than expiration (and the signature is valid) then
the TTL is reduced. So if the RRSIG expires, then its TTL has expired
and so has the TTL on the data
That's interesting to read and a real nice way of dealing with the
additional section and DNSSEC.
[ Quoting <wouter@NLnetLabs.nl> at 18:00 on Feb 24 in "Re: [nsd-users] wild..." ]
An RRSIG cannot expire on its own. If the TTL expires, then the data
it came with has expired too. If the expiration-date hits, well if
the TTL is longer than expiration (and the signature is valid) then
the TTL is reduced. So if the RRSIG expires, then its TTL has expired
and so has the TTL on the data
Nice.
But the point I was trying to make (I think I failed there...) was that
a dump resolver still can not be sure wrt to ANY queries. If it hits
unbound it's lucky, if it hits my soon-to-be-written-Go-dns-cache it's
not so lucky.
A fix is now available in svn branches/NSD_3_2 and trunk, r3526.
It will be included in the next NSD release 3.2.11.
Best regards,
Matthijs
Hi Peter,
You are right, the wildcard NSEC in the answer section is giving
problems. We are working on a fix.
Thanks for reporting.
Best regards, Matthijs
Hello,
The difference appears to be that in the ANY case, BIND adds:
www.something.wtest.com. 86400 IN NSEC wtest.com. A RRSIG NSEC
www.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400 ….
but as far as I can see, this offers no information not already
offered by: *.something.wtest.com. 86400 IN NSEC wtest.com. A
RRSIG NSEC *.something.wtest.com. 86400 IN RRSIG NSEC 5 3 86400
…
This is not the difference that matters. The issue is that NSD
puts '*.something.wtest.com NSEC' in the answer section instead
of the authority section.
According to unbound (and according to my reading of RFC4035),
this is okay:
;; QUESTION SECTION: ;www.something.wtest.com. IN ANY
;; ANSWER SECTION: www.something.wtest.com. 3600 IN A 4.3.2.1
www.something.wtest.com. 3600 IN RRSIG A 8 3 3600 20120308000000
20120223000000 33955 wtest.com.
Cdgl41CONlwN91fMiQV6D1T2/ZaQPArjswqIR5FSnNAdTcfLuADAYJrXmBwdTTtQhfJASkZRidjfdtJOYrCgJC3d1KpeqJWnIf2mLIZtiGVkz9DxoMlXcb8O0U9moOSvPRzoWKyspQrvp6+qIM5BwqifrqbsrzSWTr4PFQehiaA=
;; AUTHORITY SECTION: *.something.wtest.com. 3600 IN NSEC
wtest.com. A RRSIG NSEC *.something.wtest.com. 3600 IN RRSIG NSEC
8 3 3600 20120308000000 20120223000000 33955 wtest.com.
BEa33+lxqfRaPw5GsM6g9TwRGcVsgA/t4oK0WMZ/sikQllvOKNfZLvbdJwTN1/yQzYhrl+xqYWuQCvMHEYCztEo9/z29sPxC/4DQrWhFmPVln1kgAPNdNIO50O8KzynbwMRq5WflvlFMrgh3B65l4I0otoqOuh9UUVYF2fGlKf4=
While this (from NSD) is not:
;; QUESTION SECTION: ;www.something.wtest.com. IN ANY
;; ANSWER SECTION: *.something.wtest.com. 86400 IN NSEC
wtest.com. A RRSIG NSEC *.something.wtest.com. 86400 IN RRSIG
NSEC 5 3 86400 20120323092532 20120224092532 61140 wtest.com.
YYV4+Bv6N2VATWSx7RhOJV0PkZuvxwWLk88lU5hXVcJNvqyKkGGlJQXpy19L8ftUZJN+p5nzc+lypH06LFQAmQ==
