[dns-operations] (co.)bw DNSSEC failure

Tue Sep 20 16:58:06 UTC 2016

On Tue, Sep 20, 2016 at 10:27 AM, Peter van Dijk
<peter.van.dijk at powerdns.com> wrote:
> Hello,
> yes, I can see it is not signed - but validators cannot see that, because
> one of the .bw servers (‘master’) fails to provide the insecure (lack of DS)
> proof.
> Kind regards,

Ok, so I have what is (probably) a stupid question -- we often see
these sorts of weird DNS issues, and I keep asking myself "Ok, how did
this happen? If I wanted to recreate this problem, how would I
accomplish it?" and not coming up with an answer....

In the "bad" example, the nameserver is returning a helpful RRSIG, so
it has to have at least heard of DNSSEC. The serials match, so
(likely!) they have the same data. Sure, master.btc.net.bw could
simply be pathological, or someone could have hand edited the signed
zone file and <handwave>, but I'm not really sure how else this
situation could have come about.

Similar questions spring to mind when you see things like nameservers
which e.g never set AA bits in TCP responses[0], include completely
unrelated RRSIGs (query for foo.example, get back an RRSIG for
bar.example), etc.

Much of this is caused by braindead firewalls / LBs, but are the
remainder weird memory corruption issues, homegrown resolvers, or
what? And if it is homegrown software, why? What causes someone to
look around and think "Nah, none of the free, widely deployed software
does what I want, I'll roll my own instead"?

W

[0]: Ok, this is almost always some LB which sends TCP to forwarders,
and so the responses actually come from a cache, but, again, why?

> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
> On 20 Sep 2016, at 16:26, Moakofi Kamanga wrote:
>
> Hi Peter the zone co.bw has not been signed.Whe we started signing we
> started with the smallest zones and left co.bw while observing how other
> zones behave
>
>
>
> From: Peter van Dijk [mailto:peter.van.dijk at powerdns.com]
> Sent: 20 September 2016 04:12 PM
> To: dns-operations at dns-oarc.net
> Cc: Moakofi Kamanga <kamanga at BOCRA.ORG.BW>
> Subject: (co.)bw DNSSEC failure
>
>
>
> As (currently) visible on http://dnsviz.net/d/co.bw/dnssec/, -one- of
> the auths for .bw (the one with ‘master’ in the name) responds
> without any DNSSEC data to a DS query for co.bw, turning all names under
> co.bw bogus if a validator happens to hit this auth.
>
> See also, bad:
>
> $ dig +dnssec ds co.bw @168.167.168.37 +norec
>
> ; <<>> DiG 9.11.0a2 <<>> +dnssec ds co.bw @168.167.168.37 +norec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55749
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;co.bw. IN DS
>
> ;; AUTHORITY SECTION:
> bw. 3600 IN SOA dns1.nic.net.bw. registry.nic.net.bw. 2016092010 21600
> 3600 604800 3600
> bw. 3600 IN RRSIG SOA 8 1 3600 20161004224314 20160920130009 30513 bw.
> zSVNWUlYuP8JvpLazV2qy7GZ7DhPDkAcwGDeIx9K4EJwiOPRJW/PxSJW
> 1zulj9dZXDTbtu5CtgBc5RfXuFVlocLdPO2a8YrhOgmFBZV/QUfQ3521
> L9ulDOU7ugB0Rdkqk+hwRm7EDLkRRFFK8wKs7Pur7caG2myFBoCqW7s5 qfk=
>
> ;; Query time: 371 msec
> ;; SERVER: 168.167.168.37#53(168.167.168.37)
> ;; WHEN: Tue Sep 20 16:10:48 CEST 2016
> ;; MSG SIZE rcvd: 254
>
>
> good:
> $ dig +dnssec ds co.bw @204.61.216.70 +norec
>
> ; <<>> DiG 9.11.0a2 <<>> +dnssec ds co.bw @204.61.216.70 +norec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27343
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;co.bw. IN DS
>
> ;; AUTHORITY SECTION:
> bw. 3600 IN SOA dns1.nic.net.bw. registry.nic.net.bw. 2016092010 21600
> 3600 604800 3600
> bw. 3600 IN RRSIG SOA 8 1 3600 20161004224314 20160920130009 30513 bw.
> zSVNWUlYuP8JvpLazV2qy7GZ7DhPDkAcwGDeIx9K4EJwiOPRJW/PxSJW
> 1zulj9dZXDTbtu5CtgBc5RfXuFVlocLdPO2a8YrhOgmFBZV/QUfQ3521
> L9ulDOU7ugB0Rdkqk+hwRm7EDLkRRFFK8wKs7Pur7caG2myFBoCqW7s5 qfk=
> 0r0vq8vnkjq0q8h8a21rf8vstnl8cpoj.bw. 3600 IN NSEC3 1 0 5
> CE1457EE88F2A780 0R4R9PE5RACFBV1D2QKKHU3APDT24GJI NS
> 0r0vq8vnkjq0q8h8a21rf8vstnl8cpoj.bw. 3600 IN RRSIG NSEC3 8 2 3600
> 20161004194150 20160920130009 30513 bw.
> dVxbk65WdNrwMt56HU1FCSvv1hmF7V4VhJByV9tyav56uKLEVgTA5VFM
> RZjyReGj6LFQuaczsgXDCbVoCDS1NMjLl6hgkMrje9I/rZ4tdeQ6FGyU
> OIIUsj8LX1/Xf0d3wckFXDO8n3WzYZHbpH26RiuK85kLlecEiYCO1vh0 10s=
>
> ;; Query time: 23 msec
> ;; SERVER: 204.61.216.70#53(204.61.216.70)
> ;; WHEN: Tue Sep 20 16:11:13 CEST 2016
> ;; MSG SIZE rcvd: 498
>
>
> Technical contact from https://www.iana.org/domains/root/db/bw.html in
> Cc; sending to dns-operations in case anybody has a better contact.
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf