BIND auto-signing or validns?

[bortzmeyer]

I get an error:

% validns -p all -z example example.signed-text 
example.signed-text:15: example. RRSIG(TYPE65534): bad signature
example.signed-text:3: example. RRSIG(SOA): bad signature

The zone is maintained by BIND "auto-dnssec maintain;" feature (auto-signing). Since the signed zone is in binary format, I extracted it with:

named-compilezone -j -i none -f raw -F text -o example.signed-text  example  example.signed

Is it a bad procedure? A bug in BIND? In validns?

The actual zone file is in https://gist.github.com/bortzmeyer/6105081

[tobez]

On Mon, Jul 29, 2013 at 08:15:35AM -0700, Stéphane Bortzmeyer wrote:

I get an error:

% validns -p all -z example example.signed-text 
example.signed-text:15: example. RRSIG(TYPE65534): bad signature
example.signed-text:3: example. RRSIG(SOA): bad signature

The zone is maintained by BIND "auto-dnssec maintain;" feature (auto-signing). Since the signed zone is in binary format, I extracted it with:

named-compilezone -j -i none -f raw -F text -o example.signed-text  example example.signed

Is it a bad procedure? A bug in BIND? In validns?

Do you get this every time you sign that particular zone, or just once?

Are there other records in the zone (for which validns does not report
problems)?

If you serve the zone with BIND, can a DNSSEC-supporting resolver validate
the records?

\Anton.

Our society can survive even a large amount of irrational regulation.
-- John McCarthy

[bortzmeyer]

You can see in the zone file I posted that, yes, there are other types and they seem OK. I have setup a public zone you can test, auto.rd.nic.fr (the master allows zone transfers). The zone works and can be validated. I now get these results:

% validns -p all -z auto.rd.nic.fr auto.rd.nic.fr             
auto.rd.nic.fr:8: auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:21: ns1.auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:24: 7cc2008ib0aji6pn9m8njb59sacdfdb0.auto.rd.nic.fr. RRSIG(NSEC3): bad signature
auto.rd.nic.fr:13: auto.rd.nic.fr. RRSIG(TYPE65534): bad signature

[tobez]

On Tue, Jul 30, 2013 at 02:13:55PM -0700, Stéphane Bortzmeyer wrote:

You can see in the zone file I posted that, yes, there are other types and
they seem OK.

A question not unrelated to the actual problem, more to get a feel about how
github issues work - in the mail I've got there was no link to the zone
file. Did you edit the issue text at a later point?

At any rate, I think I am not handling repeated sigs correctly - as you can
see for yourself, the SOA RRSIG, and the TYPE65534 RRSIG are in the zone
file twice (with different values). So I guess that explains it.

Are you aware of any standards describing how to deal with such situations?
There are mutliple possible interpretations, like:

• ignore all encountered sigs in an RRSET except the first
• ignore all encountered sigs in an RRSET except the last
• try to check them all, and if one of them is fine, then all is fine

etc.

I have setup a public zone you can test, auto.rd.nic.fr (the
master allows zone transfers). The zone works and can be validated. I now
get these results:

% validns -p all -z auto.rd.nic.fr auto.rd.nic.fr             
auto.rd.nic.fr:8: auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:21: ns1.auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:24: 7cc2008ib0aji6pn9m8njb59sacdfdb0.auto.rd.nic.fr. RRSIG(NSEC3): bad signature
auto.rd.nic.fr:13: auto.rd.nic.fr. RRSIG(TYPE65534): bad signature

It's similar: bad signatures are because RRSIG(TYPE65534) and RRSIG(NSEC3)
have duplicates with different (presumably bad) signature data, which
"non-existing type" are real - there is an RRSIG for a type that is not
there. This sounds like a zone bug, or at least something
not-entirely-sane, no?

\Anton.

Our society can survive even a large amount of irrational regulation.
-- John McCarthy

[tobez]

On Tue, Jul 30, 2013 at 11:42:22PM +0200,
Anton Berezin [email protected] wrote
a message of 41 lines which said:

A question not unrelated to the actual problem, more to get a feel
about how github issues work - in the mail I've got there was no
link to the zone file. Did you edit the issue text at a later
point?

Yes, I did.

This sounds like a zone bug, or at least something
not-entirely-sane, no?

For the TYPE65534, indeed, it looks like a BIND bug. Reported to ISC
as [ISC-Bugs #34439]

[tobez]

On Wed, Jul 31, 2013 at 10:06:28AM +0200, Stéphane Bortzmeyer wrote:

On Tue, Jul 30, 2013 at 11:42:22PM +0200,
Anton Berezin [email protected] wrote
a message of 41 lines which said:

A question not unrelated to the actual problem, more to get a feel
about how github issues work - in the mail I've got there was no
link to the zone file. Did you edit the issue text at a later
point?

Yes, I did.

This sounds like a zone bug, or at least something
not-entirely-sane, no?

For the TYPE65534, indeed, it looks like a BIND bug. Reported to ISC
as [ISC-Bugs #34439]

And for the rest (duplicated RRSIG for SOA and for NSEC3), and bogus RRSIG
for non-existing record types, do you have an opinion?

\Anton.

Our society can survive even a large amount of irrational regulation.
-- John McCarthy

[stirnim]

Hi Anton

And for the rest (duplicated RRSIG for SOA and for NSEC3), and bogus RRSIG
for non-existing record types, do you have an opinion?

I think it is similar to the Algorithm Key Rollover issue (#22). There should be a policy where I can instruct validns to stop moaning about duplicate/obsolete/irrelevant RRSIGs.

Daniel