Broken DNSSEC record for DEFCON.ORG - I can help

[liberator]

I work for a giant ISP that won't resolve DEFCON.ORG because of the broken DNSSEC record. We don't have a NTA for it. I can help get this fixed but need to get in touch with the right person who administers DEFCON.ORG. Please DM me so we can get this fixed. Thanks. Ref: http://dnsviz.net/d/defcon.org/dnssec/

[TheCotMan]

I work for a giant ISP that won't resolve DEFCON.ORG because of the broken DNSSEC record. We don't have a NTA for it. I can help get this fixed but need to get in touch with the right person who administers DEFCON.ORG. Please DM me so we can get this fixed. Thanks. Ref: http://dnsviz.net/d/defcon.org/dnssec/

Thanks for the report. I passed on your notice to a person that can review and likely repair this. I do not know if they will respond here.
Added: (They knew about it and have been working on it.)

[Dark Tangent]

Thanks liberator

The defcon.org DNSSEC problem in a nutshell:

Go to these two sites and run their tool on defcon.org
http://dnssec-debugger.verisignlabs.com/
http://dnsviz.net/

One make it look terrible, the other says everything is (basically) OK. It depends on how validation is done.

The problem is defcon.org still has OLD expired keys listed in the .org registry
defcon.org DS key #59611
defcon.org DS key #64740

These were replaced two years ago with the currently working and validating keys
defcon.org DNSKEY ZSK 14006
defcon.org DNSKEY KSK 38292

Publishing the new DS records did not purge the old records.

The old records were entered by a registrar we are no longer with (NetSol) and the current registrar (Gandi) is working to try and remove the old ones for us.

Some resolvers throw an error when they see the expired DS key. Others walk the whole record, see the valid DS keys and validate.

I'll keep everyone updated when I learn anything new.

DT

[liberator]

Some good news from Comcast:
"On our end, we are looking better now. We did some magic on our resolvers that allows [DEFCON.ORG] to resolve correctly."

[Dark Tangent]

Looks like the problem is now fixed on our end.

To make a long story short the problem revolved around the old zone files and key files (That we signed with the old DS keys) having been deleted but because I never ran an "rndc delzone defcon.org" it lived on in a cache or some meta-file. No matter if I deleted all references to the defcon.org zone the old DS keys would magically appear and sign a new fresh defcon.org zone file.

I ended up doing the following:

rm defcon.org
rm defcon.org.*
rndc delzone defcon.org <-- The magic happened here
rndc flush
rndc reload

(Copy back the unsigned defcon.org zone file)
rndc addzone defcon.org
rndc loadkeys defcon.org
rndc signing -nsec3param 1 0 10 076543211 defcon.org. <-- No that isn't the salt value I used

Mystery solved.

[liberator]

There are still a few errors and warnings showing up at http://dnsviz.net/d/defcon.org/dnssec/ Errors (6)

• RRSIG defcon.org/DNSKEY alg 10, id 38292: With a TTL of 4838400 the RRSIG RR can be in the cache of a non-validating resolver until 4 days after it expires at 2017-09-09 19:21:12+00:00.
• RRSIG defcon.org/DNSKEY alg 10, id 38292: With a TTL of 4838400 the RRSIG RR can be in the cache of a non-validating resolver until 4 days after it expires at 2017-09-09 19:21:12+00:00.
• RRSIG defcon.org/MX alg 10, id 14006: With a TTL of 4838400 the RRSIG RR can be in the cache of a non-validating resolver until 4 days after it expires at 2017-09-09 18:05:37+00:00.
• RRSIG defcon.org/NS alg 10, id 14006: With a TTL of 4838400 the RRSIG RR can be in the cache of a non-validating resolver until 4 days after it expires at 2017-09-09 18:05:37+00:00.
• RRSIG defcon.org/SOA alg 10, id 14006: With a TTL of 4838400 the RRSIG RR can be in the cache of a non-validating resolver until 36 days after it expires at 2017-08-08 18:37:50+00:00.
• org/DNSKEY: No response was received from the server over UDP (tried 4 times). (2001:500:e::1, UDP_0_EDNS0_32768_512)

Warnings (2)

• defcon.org/DNSKEY (alg 10, id 14006): No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (162.222.171.195, 162.222.171.197, UDP_0_EDNS0_32768_4096)
• defcon.org/DNSKEY (alg 10, id 38292): No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (162.222.171.195, 162.222.171.197, UDP_0_EDNS0_32768_4096)