dblacka/jdnssec-tools

Java command line tools for DNSSEC

jdnssec-tools's Issues

Exit code 0 when an unhandled exception occurs in jdnssec-verify

Hi,

We are using this in our tests and are using the exit code to see if the jdnssec-verify passed it's test.

Now, when there is an unhandled exception (like this one: #9) then it exits with code 0, so this goes unnoticed for us.

Suggestion is to have a catch all for all exceptions in jdnssec-verify and to exit with non-zero code in that case.

Thanks

Do not de-duplicate RRs in jdnssec-verifyzone

Instead, jdnssec-verifyzone should complain if duplicate RRs exist in a zone.

jdnssec-verifyzone incorrectly handles NSEC3 existence in opt-out zones

In particular, it thinks that empty non-terminals created by insecure delegations should have NSEC3 records.

jdnssec verify can not handle CAA records

org.xbill.DNS.Tokenizer$TokenizerException: dns.be.zone.forfast.axfr:30: Invalid type 'CAA'
at org.xbill.DNS.Tokenizer.exception(Tokenizer.java:710)
at org.xbill.DNS.Master.parseTTLClassAndType(Master.java:161)
at org.xbill.DNS.Master._nextRecord(Master.java:364)
at org.xbill.DNS.Master.nextRecord(Master.java:388)
at com.verisignlabs.dnssec.security.ZoneUtils.readZoneFile(ZoneUtils.java:74)
at com.verisignlabs.dnssec.cl.VerifyZone.execute(VerifyZone.java:141)
at com.verisignlabs.dnssec.cl.CLBase.run(CLBase.java:336)
at com.verisignlabs.dnssec.cl.VerifyZone.main(VerifyZone.java:164)

version jdnssec-tools-0.14-0

TypeMap.fromBytes() does not work

Doing some internal testing, we noticed that fromBytes() (which isn't used in the rest of the tools) is incorrect.

Bug: A zone with two ZSK with identical keytag causes jdnssec-verifyzone to report Reason: Signature failed to verify cryptographically

We encounted this bug during a rollover of one ZSK key to another ( with same keytag)

KeyGen writes out DNSKEY to .key files without TTL

The DNSKEYtoString generation which is the string serialization being written into the .key file generated does not include the TTL value of the DNSKEY record type, resulting in errors of missing TTL when using the jdnssec-signkeyset.

Steps to reproduce

$ jdnssec-keygen -a ECDSAP256SHA256 -d . test

results in 

test. IN DNSKEY 256 3 13 2PWH6GR4uKmAffpfg01eAoe13xaEWXGCwPqkv67GDw4XZypwmADMxjN6o20uDyKdbHO0CPuCX6ymmA5zQ+/FXA==

Expected

test. <TTL> IN DNSKEY 256 3 13 2PWH6GR4uKmAffpfg01eAoe13xaEWXGCwPqkv67GDw4XZypwmADMxjN6o20uDyKdbHO0CPuCX6ymmA5zQ+/FXA==

Potential patch

--- a/src/main/java/com/verisignlabs/dnssec/security/BINDKeyUtils.java
+++ b/src/main/java/com/verisignlabs/dnssec/security/BINDKeyUtils.java
@@ -355,6 +355,8 @@ public class BINDKeyUtils
     StringBuffer buf = new StringBuffer();
 
     buf.append(rec.getName());
+    buf.append(" ");
+    buf.append(rec.getTTL());
     buf.append(" IN DNSKEY ");
     buf.append(rec.getFlags() & 0xFFFF);
     buf.append(" ");

bad base64 causes early abort

With reference to tobez/validns#69:

$  jdnssec-verifyzone minimal.com
org.xbill.DNS.Tokenizer$TokenizerException: minimal.com:5: invalid base64 encoding
	at org.xbill.DNS.Tokenizer.exception(Tokenizer.java:710)
	at org.xbill.DNS.Tokenizer.getBase64(Tokenizer.java:617)
	at org.xbill.DNS.Tokenizer.getBase64(Tokenizer.java:631)
	at org.xbill.DNS.SIGBase.rdataFromString(SIGBase.java:80)
	at org.xbill.DNS.Record.fromString(Record.java:472)
	at org.xbill.DNS.Master._nextRecord(Master.java:365)
	at org.xbill.DNS.Master.nextRecord(Master.java:388)
	at com.verisignlabs.dnssec.security.ZoneUtils.readZoneFile(ZoneUtils.java:74)
	at com.verisignlabs.dnssec.cl.VerifyZone.execute(VerifyZone.java:141)
	at com.verisignlabs.dnssec.cl.CLBase.run(CLBase.java:318)
	at com.verisignlabs.dnssec.cl.VerifyZone.main(VerifyZone.java:164)

verifyzone completely bails out on the base64 decoding failure, while it could theoretically still check the rest of the zone file.