DNSSEC problems

[Matthias Scheler]

Hello,

I'm using BIND 9.7.2-P3 built from "netbsd-5" sources on a NetBSD 5.1 system.
I recently enable DNSSEC after it was turned on by default in the
"named.conf" that is shipped with NetBSD. It worked fine for several days
until this morning. At this point my server was refusing to resolve a lot
of domains e.g. "apple.com" or "spiegel.de". Here are some of the
error messages:

Jan 22 09:32:42 colwyn named[9658]: error (broken trust chain) resolving 'kliniksuche.spiegel.de/AAAA/IN': 2001:8b0::2021#53
Jan 22 09:32:42 colwyn named[9658]: error (broken trust chain) resolving 'kliniksuche.spiegel.de/A/IN': 2001:8b0::2021#53
Jan 22 09:32:42 colwyn named[9658]: validating @0x7f7ff6be2000: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Jan 22 09:32:42 colwyn named[9658]: validating @0x7f7ff6be1000: www.dastelefonbuch.de.dlv.isc.org DLV: bad cache hit (de.dlv.isc.org/DS)
Jan 22 09:32:42 colwyn named[9658]: error (broken trust chain) resolving 'www.dastelefonbuch.de.dlv.isc.org/DLV/IN': 2001:8b0::2021#53
Jan 22 09:32:42 colwyn named[9658]: error (broken trust chain) resolving 'www.dastelefonbuch.de/A/IN': 2001:8b0::2021#53
Jan 22 09:32:42 colwyn named[9658]: validating @0x7f7ff69e5000: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Jan 22 09:32:42 colwyn named[9658]: validating @0x7f7ff69e4000: dastelefonbuch.de.dlv.isc.org DLV: bad cache hit (de.dlv.isc.org/DS)
Jan 22 09:32:42 colwyn named[9658]: error (broken trust chain) resolving 'dastelefonbuch.de.dlv.isc.org/DLV/IN': 2001:8b0::2021#53
Jan 22 09:32:42 colwyn named[9658]: error (broken trust chain) resolving 'www.dastelefonbuch.de/AAAA/IN': 2001:8b0::2021#53

Any idea what is going wrong here? 2001:8b0::2021 is one of the recursive
resolves provided by my ISP.

Kind regards

[Jeremy C. Reed]

Post by Matthias Scheler
dlv.isc.org SOA: got insecure response; parent indicates it should be
secure

For some reason, a query for dlv.isc.org's SOA got a response that was
not signed. Some misconfigured firewalls block DNS on UDP responses over
512 bytes. Some broken firewalls block EDNS. Some nameservers don't
respond to EDNS. Some devices may block or drop fragmented responses.
Some of these may cause timing problems. After multiple timeouts, it may
use a non-DNSSEC query. Or maybe there was a SERVFAIL from a EDNS query
(due to broken name server) or maybe something in the middle removed the
RRSIG records. Or maybe it was a real attempt of poisoning or the zone
really was temporarily broken (but probably not). (Disclosure: I worked
for the owner of that zone.)

Post by Matthias Scheler
Any idea what is going wrong here? 2001:8b0::2021 is one of the recursive
resolves provided by my ISP.

Maybe test it with

dig @2001:8b0::2021 +short rs.dns-oarc.net txt

See https://www.dns-oarc.net/oarc/services/replysizetest

For example, one of my ISP's resolvers results in:

"68.238.96.37 DNS reply size limit is at least 490"
"68.238.96.37 lacks EDNS, defaults to 512"

(I do not use them!)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Jeremy C. Reed
Some broken firewalls block EDNS. Some nameservers don't
respond to EDNS. Some devices may block or drop fragmented responses.

I hope that none of this is the case in for setup. I've turned off intrusions
detection on the router (Cisco 877W) and my ISP is a strong believer in not
messing about with peoples' IP traffic. I've contact their support and asked
whether they are aware of any DNSSEC problems on that name server.

Post by Jeremy C. Reed

Post by Matthias Scheler
Any idea what is going wrong here? 2001:8b0::2021 is one of the recursive
resolves provided by my ISP.

Maybe test it with
See https://www.dns-oarc.net/oarc/services/replysizetest
"68.238.96.37 DNS reply size limit is at least 490"
"68.238.96.37 lacks EDNS, defaults to 512"

This is what I get:

***@colwyn:~>host -t txt rs.dns-oarc.net. 2001:8b0::2021
Using domain server:
Name: 2001:8b0::2021
Address: 2001:8b0::2021#53
Aliases:

rs.dns-oarc.net is an alias for rst.x4091.rs.dns-oarc.net.
rst.x4091.rs.dns-oarc.net is an alias for rst.x4049.x4091.rs.dns-oarc.net.
rst.x4049.x4091.rs.dns-oarc.net is an alias for rst.x4055.x4049.x4091.rs.dns-oarc.net.
rst.x4055.x4049.x4091.rs.dns-oarc.net descriptive text "2001:8b0:0:53::5a9b:3520 DNS reply size limit is at least 4091"
rst.x4055.x4049.x4091.rs.dns-oarc.net descriptive text "2001:8b0:0:53::5a9b:3520 sent EDNS buffer size 4096"
rst.x4055.x4049.x4091.rs.dns-oarc.net descriptive text "Tested at 2011-01-22 14:42:40 UTC"

Kind regards

[Geert Hendrickx]

Post by Matthias Scheler
Any idea what is going wrong here? 2001:8b0::2021 is one of the recursive
resolves provided by my ISP.

Does the upstream recursive resolver have DNSSEC enabled? ie. does it pass
signatures when you query with +DO?

Try `dig +dnssec dlv.isc.org @2001:8b0::2021`, it should return both A and
RRSIG records.

If not, that resolver is not DNSSEC-aware and you'll have to use another as
forwarder (or no forwarders at all).


Geert

[Matthias Scheler]

Post by Jeremy C. Reed
RRSIG records.

It does like it is DNSSEC aware:

; <<>> DiG 9.7.2-P3 <<>> +dnssec dlv.isc.org. @2001:8b0::2021
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 729
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dlv.isc.org. IN A

;; ANSWER SECTION:
dlv.isc.org. 273 IN A 149.20.16.8
dlv.isc.org. 273 IN RRSIG A 5 3 300 20110221131503 20110122131503 64263 dlv.isc.org. g+BO93pWK7/rLzP46SonntLC98TuFhueBIYZAgnMUajhB3yRPh2tQ+4i ItXZigDk+KbQzNeQQcE0Uw+5tI80TKjuDsG7jukhb+TTBvEBFSmUJesI 7uPgmO9PSr+bmgutTmoJyFP/lrbcryrkei41ku7AHYfS9ZYJTm5nLHcA x/I=

;; AUTHORITY SECTION:
dlv.isc.org. 3573 IN NS dlv.sfba.sns-pb.isc.org.
dlv.isc.org. 3573 IN NS ns2.isc.ultradns.net.
dlv.isc.org. 3573 IN NS ns.isc.afilias-nst.info.
dlv.isc.org. 3573 IN NS ns1.isc.ultradns.net.
dlv.isc.org. 3573 IN NS dlv.ams.sns-pb.isc.org.
dlv.isc.org. 3573 IN NS dlv.ord.sns-pb.isc.org.
dlv.isc.org. 3573 IN RRSIG NS 5 3 3600 20110221131503 20110122131503 64263 dlv.isc.org. XUVdz9A6QKnj9MVRqQXsmETENAXB0Na2syFmeOyuez4BV4+pOdPVEJWD EQeGiWqZemblQSRND/juA4bqOQcZMON61AIub7/6fl0UmR769qdyFvRL r4v4gAcTPRrh3aoOhsRUZSGdIH4zCzD960DG4I/r3MYf8p36xHFBrnSD Mgk=

;; Query time: 19 msec
;; SERVER: 2001:8b0::2021#53(2001:8b0::2021)
;; WHEN: Sat Jan 22 21:57:22 2011
;; MSG SIZE rcvd: 561

Kind Regards

[Jeremy C. Reed]

Post by Jeremy C. Reed
For some reason, a query for dlv.isc.org's SOA got a response that was
not signed. Some misconfigured firewalls block DNS on UDP responses over
512 bytes. Some broken firewalls block EDNS. Some nameservers don't
respond to EDNS.

Sorry I didn't mean to say "misconfigured". See RFC 1035 and RFC 2671
and others.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jonathan A. Kollasch]

Post by Jeremy C. Reed

Post by Matthias Scheler
dlv.isc.org SOA: got insecure response; parent indicates it should be
secure

For some reason, a query for dlv.isc.org's SOA got a response that was
not signed. Some misconfigured firewalls block DNS on UDP responses over
512 bytes. Some broken firewalls block EDNS. Some nameservers don't
respond to EDNS. Some devices may block or drop fragmented responses.

This includes our version of pf(4). It drops all(?) IPv6 fragments.

Jonathan Kollasch

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Jonathan A. Kollasch

Post by Jeremy C. Reed
Some devices may block or drop fragmented responses.

This includes our version of pf(4). It drops all(?) IPv6 fragments.

I thought v6 didn't even _support_ fragmentation.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by der Mouse

Post by Jonathan A. Kollasch

Post by Jeremy C. Reed
Some devices may block or drop fragmented responses.

This includes our version of pf(4). It drops all(?) IPv6 fragments.

I thought v6 didn't even _support_ fragmentation.

IPv6 routers don't do fragmentation, but the source host can if
a local application needs to send a big packet.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Post by der Mouse

Post by Jonathan A. Kollasch

Post by Jeremy C. Reed
Some devices may block or drop fragmented responses.

This includes our version of pf(4). It drops all(?) IPv6 fragments.

I thought v6 didn't even _support_ fragmentation.

No *router* fragmentation. End systems can fragment all they want.

gert