[dns-operations] Stale NSEC3 records

Tue Sep 22 08:40:47 UTC 2009

Yesterday, two more ccTLDs have joined the DNSSEC club: CH and LI.  We
haven't published the trust anchors anywhere yet.  This will happen in
about two weeks or so.  Unfortunately, we're forced to use NSEC3 and
we have decided to go without opt-out.

We've been signing the zones for a few weeks before going live
yesterday.  One thing I noticed immediately was that BIND started to
log NSEC3 hash collisions every couple of seconds.  Its way of
expressing this is a bit awkward:

22-Sep-2009 08:59:57.968 client 2001:1b50::82:195:225:5#58695: expected covering NSEC3, got an exact match
22-Sep-2009 09:00:25.290 client 195.50.140.13#65067: expected covering NSEC3, got an exact match
22-Sep-2009 09:00:32.345 client 85.115.54.190#56624: expected covering NSEC3, got an exact match
22-Sep-2009 09:00:45.844 client 85.115.54.190#19259: expected covering NSEC3, got an exact match
22-Sep-2009 09:01:05.041 client 92.46.53.238#7563: expected covering NSEC3, got an exact match

(Note to ISC: it would have been awsome if the QNAME that causes the
collision was included with the message and possibly the hash as
well).

Clearly, these can't be "real" collisions or we would be in real
trouble.  It turns out that dnssec-signzone does not remove NSEC3
records whose original owner name is no longer part of the zone.

The way we do incremental signing (and, I believe, the way it's meant
to be done :) is to replace the full set of delegations (NS, glue) in
the current zone file with those from our registry database while
keeping all existing RRSIG and NSEC3 records and pass everything to
dnssec-signzone.  This means that if a name is removed from the zone,
the corresponding NSEC3 and its RRSIG are still there.  The problem is
that the signer simply ignores them and keeps them in the zone (but
re-news the signature if necessary, I guess, haven't checked that).

AFAICT, it should be the signer's job to remove such stale NSEC3
records.  This should be easy because it needs to hash the entire zone
in any case (e.g. mark all NSEC3 upon reading the zone, remove the
marker for those whose original owner name exists, remove all those
still marked while dumping the new zone).  A workaround would be to
simply remove all NSEC3 records before passing the zone to the signer
while keeping the RRSIGs.  However, the signer also happily keeps
RRSIGs whose associated RRsets don't exist, so we'd have to filter
those out as well in the end.

I also noticed that BIND is not conforming to section 7.2.9 of RFC
5155: in case of such a collision, it MUST return RCODE 2, but it
actually returns NXDOMAIN.  NSD is doing this right, see the dig
output for one such case below (the first one is from a server running
BIND 9.6.1-P1, the second from NSD 3.2.2).  The hash of the
non-existing name "kohmedi" is 1DVEDKQ3T5F1188GP148MNUI1N11JLJC, which
is actually included in BIND's response.  I'll post this to bind-bugs
unless somebody from ISC has already picked it up from here :)

-- 
Alex

; <<>> DiG 9.6.1-P1 <<>> @a.nic.ch kohmedi.ch. a +dnssec +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 492
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;kohmedi.ch.                    IN      A

;; AUTHORITY SECTION:
ch.                     3600    IN      SOA     a.nic.ch. helpdesk.nic.ch. 2009092209 3600 900 2592000 3600
ch.                     3600    IN      RRSIG   SOA 7 1 3600 20090929060324 20090922070736 8060 ch. 1GDehozKF6w2oqlZUIGAXY82UQxK1sn9iGCs/Gsmm8v/myPYDbqhN0fN hgPG9y39tMNoZrIzP8NnJ5qs2hGxplxYn0jkS71KGyccZUtDgvO6XK5r gEB2kUU4iC8kNDg48vmHK3TeduHxGrAfyk7W2FcDrJGqB5RI4evJTMtR bvk=
IVIRTC3ULSKDF3N2FQ0QLT6GHU070D91.ch. 3600 IN NSEC3 1 0 2 0C32 IVIS9UBMOPMI22TEGEN79IIBSRFVV83C NS SOA RRSIG DNSKEY NSEC3PARAM
IVIRTC3ULSKDF3N2FQ0QLT6GHU070D91.ch. 3600 IN RRSIG NSEC3 7 2 3600 20090927191036 20090920200848 8060 ch. vJbSbXOjX5dp8tNXS7MsuzP6zJmlFKqh0knsVGjv4N8iroVENPDa1NwN /s3mOYFzXDzrGhYIT3XgS0fFXikrAvuzd9FKv/8C1FRwLkFhvDNMkDIh fUKCH0sTbPHq1PddpZWvkp5wWyzKfJ/HjjVwC6rezrNFmcYRVvNefg55 hJE=
1DVEDKQ3T5F1188GP148MNUI1N11JLJC.ch. 3600 IN NSEC3 1 0 2 0C32 1DVEHMTTQQ10IK0VPCQN1TVCQ6UB8TPO NS
1DVEDKQ3T5F1188GP148MNUI1N11JLJC.ch. 3600 IN RRSIG NSEC3 7 2 3600 20090926024813 20090919060852 8060 ch. mhguEkbKdfZCKajC3XWO+zHftAK5Gw36ZqJ/BPhDcP4TFU+AZfiu8x6i Nzzax4ypflq6Lm4tOv5dNOs+IVeotyn8uBxwBUGDh1Vy1QObmVdLLVGu 53P7M5r1DP5yMJsBqjTo49eMwAqbqn5uYNcsAJUO4846ZWC2+MLE957u n8w=
4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK.ch. 3600 IN NSEC3 1 0 2 0C32 4IJOJ36DQE9M74HI54TKRHAVLR4Q626D NS
4IJMAQ445J7NCEB5QCV84LLVVF5EAPDK.ch. 3600 IN RRSIG NSEC3 7 2 3600 20090926044908 20090919090844 8060 ch. 726htK0SndVy+7U3skfqKxiyMlfd4UGPdiIh4KPSS6A21UAyGX7/1s9w Tzw9GJ7UyNvzmIt4Ln4edjkyIWZbJDVbpopl10uSO128MwHQNaItXeZb dvxWDcgAr3WtZbrzuR1sosb0l+ZK7/SlaNFzC+g9fKP8cNd5Kh4lJZYm Pmk=

;; Query time: 3 msec
;; SERVER: 2001:620::4#53(2001:620::4)
;; WHEN: Tue Sep 22 10:06:27 2009
;; MSG SIZE  rcvd: 972

; <<>> DiG 9.6.1-P1 <<>> @h.nic.ch kohmedi.ch. a +dnssec +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 865
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;kohmedi.ch.                    IN      A

;; AUTHORITY SECTION:
ivirtc3ulskdf3n2fq0qlt6ghu070d91.ch. 3600 IN NSEC3 1 0 2 0C32 IVIS9UBMOPMI22TEGEN79IIBSRFVV83C NS SOA RRSIG DNSKEY NSEC3PARAM
ivirtc3ulskdf3n2fq0qlt6ghu070d91.ch. 3600 IN RRSIG NSEC3 7 2 3600 20090927191036 20090920200848 8060 ch. vJbSbXOjX5dp8tNXS7MsuzP6zJmlFKqh0knsVGjv4N8iroVENPDa1NwN /s3mOYFzXDzrGhYIT3XgS0fFXikrAvuzd9FKv/8C1FRwLkFhvDNMkDIh fUKCH0sTbPHq1PddpZWvkp5wWyzKfJ/HjjVwC6rezrNFmcYRVvNefg55 hJE=
4ijmaq445j7nceb5qcv84llvvf5eapdk.ch. 3600 IN NSEC3 1 0 2 0C32 4IJOJ36DQE9M74HI54TKRHAVLR4Q626D NS
4ijmaq445j7nceb5qcv84llvvf5eapdk.ch. 3600 IN RRSIG NSEC3 7 2 3600 20090926044908 20090919090844 8060 ch. 726htK0SndVy+7U3skfqKxiyMlfd4UGPdiIh4KPSS6A21UAyGX7/1s9w Tzw9GJ7UyNvzmIt4Ln4edjkyIWZbJDVbpopl10uSO128MwHQNaItXeZb dvxWDcgAr3WtZbrzuR1sosb0l+ZK7/SlaNFzC+g9fKP8cNd5Kh4lJZYm Pmk=

;; Query time: 1 msec
;; SERVER: 194.42.48.120#53(194.42.48.120)
;; WHEN: Tue Sep 22 10:06:32 2009
;; MSG SIZE  rcvd: 523