Re: Insecurity proof failed resolving newsletter.postbank.de - but why?

2014-01-20 Thread Casey Deccio 
On Mon, Jan 20, 2014 at 12:46 PM, Graham Clinch wrote:

> Thanks for the replies - and noticing the missing 'NS'!
>
> From my rather brain-busting afternoon reading, I believe this situation
> is covered by section 4.4 of RFC 6840, which requires a validator to ensure
> the NS type bit is set for an insecure delegation's NSEC(3) (or that it's
> covered by opt-out, but as Chris pointed out, that doesn't seem to be the
> case here).
>
I've left feedback for the dnsviz maintainer in the hopes that this case
> can be picked up in future.
>

Should be fixed now.  Not sure why I hadn't implemented that check before,
but I have now.

Casey
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Insecurity proof failed resolving newsletter.postbank.de - but why?

2014-01-20 Thread Mark Andrews 

In message , Tony 
Finch writes:
> Graham Clinch  wrote:
> >
> > I'm seeing a dnssec validation error that I can't pin down, for the domain:
> > newsletter.postbank.de.
> 
> Looks like a bug in BIND to me. It works out that there is no DS in the
> parent then gets muddled. I note that postbank.de is in the middle of a
> double-signature ZSK rollover. Dunno if that is relevant, but it is a bit
> unusual.

It looks like a missing NS bit in the NSEC3 record which causes the
isdelegation check to fail.  DNSSEC proves delegations exist, or
don't exist, as the case may be unless the delegation is in a optout
range.

; <<>> DiG 9.10.0a1 <<>> newsletter.postbank.de +dnssec ds
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28762
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;newsletter.postbank.de.IN  DS

;; AUTHORITY SECTION:
postbank.de.8981IN  SOA ns1.postbank.de. 
webmaster.postbank.de. 2010022883 86400 7200 604800 86400
postbank.de.8981IN  RRSIG   SOA 7 2 86400 20140125074615 
20140118074615 55913 postbank.de. 
MAyl9jCfxylOItqAJc/Pyb55D/KI8reTVkxLYJ2oecBzhNoKTiaYw7o9 
ceU7CSXRjIwWLe6DL2SKbHKrwe8G3lYHgoYOwmV62k+TgpM9Cvr8gyV/ 
LdheakhaDuWYmnehF5+Q1gDWQpNwoqpBLsZxQYC9B9Lg+Q2EYJflVRKf /8o=
postbank.de.8981IN  RRSIG   SOA 7 2 86400 20140126152235 
20140119152235 32699 postbank.de. 
KWYHjij78NobHPVWt4SpPQUWCR/uxTjQ9ZlAplju25xazg4aPcN5g5Qw 
wQDPXNLVSMRhb6YZdfffN877a7CBlWPlRC5s488wwqT94kUHyOdIT+Oi 
UqNACz6i5Tmv9bf6ViS97sjF3JoAg2Uc3nDHFojVojzC6C6MG8tqmy49 0Pg=
393dv6p4d1fhr0kisru6alkuv0vq5th0.postbank.de. 8981 IN RRSIG NSEC3 7 3 86400 
20140128024505 20140121024505 55913 postbank.de. 
fsi6k+JrX3ohDihsO0XG9Upl7UOs7ceMLAv3UBqgf/u7KCJiA/rp6kMO 
o9nqk0dJVPhcIKnB01aV+2/+MKsX0Df346CCVF11y2+mztL2Cem5K0dj 
vEnziZCYam34IhbKE+LuWTfPQFq4sUaMYDyXAsZi8anoMgwYtQTUdpRg Ego=
393dv6p4d1fhr0kisru6alkuv0vq5th0.postbank.de. 8981 IN RRSIG NSEC3 7 3 86400 
20140128024505 20140121024505 32699 postbank.de. 
cCDLXMaENZIu31d1Qb4CStZAKxwtRScfyBAGoJ5LQ4mlAjNnnlhqyxNv 
ig+dnMWa24qL9TLoeBMr25cpcXrHi/+SkSJkQvpuzMf5lVFWekVPPOx1 
ZcCPui+etUdrIRcB49a1ksT71STTQUI0noXKH6gZ/k5AisRoN/I/Z+TB ku4=
393dv6p4d1fhr0kisru6alkuv0vq5th0.postbank.de. 8981 IN NSEC3 1 0 1 
D252CA1843C35103 393DV6P4D1FHR0KISRU6ALKUV0VQ5TH1 

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 21 14:20:11 EST 2014
;; MSG SIZE  rcvd: 864

 
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
> newsletter.postbank.de DS: in authvalidated
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
> newsletter.postbank.de DS: resuming nsecvalidate
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
> newsletter.postbank.de DS: looking for relevant NSEC3
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
> newsletter.postbank.de DS: looking for relevant NSEC3
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
> newsletter.postbank.de DS: NSEC3 proves name exists (owner) data=0
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
> newsletter.postbank.de DS: nonexistence proof(s) found
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80b044860(newsletter.postbank.de/DS): received validation completion event
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validator @0x8071e8300: 
> dns_validator_destroy
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80b044860(newsletter.postbank.de/DS): nonexistence validation OK
> 
> ... right ...
> 
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80b044860(newsletter.postbank.de/DS): clone_results
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80b044860(newsletter.postbank.de/DS): done
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80b044860(newsletter.postbank.de/DS): stopeverything
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80b044860(newsletter.postbank.de/DS): cancelqueries
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80b044860(newsletter.postbank.de/DS): sendevents
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80ac04000(postbank.de/DNSKEY): doshutdown
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80ac04000(postbank.de/DNSKEY): stopeverything
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80ac04000(postbank.de/DNSKEY): cancelqueries
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80ac04000(postbank.de/DNSKEY): unlink
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
> 0x80ac04000(postbank.de/DNSKEY): destroy
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: 
> newsletter.postbank.de A: in dsfetched2: ncache nxrrset
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: 
> newsletter.postbank.de A: resuming proveunsecure
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: val

Re: Insecurity proof failed resolving newsletter.postbank.de - but why?

2014-01-20 Thread Graham Clinch 

Hi List (& Chris & Tony),


What *does* matter is that the NSEC3 "proves" that there are no NS
records as well (as no DS ones) for newsletter.postbank.de (despite
the fact that the NS records are included in the referral). Note the
absence of opt-out in the NSEC3.


Thanks for the replies - and noticing the missing 'NS'!

From my rather brain-busting afternoon reading, I believe this 
situation is covered by section 4.4 of RFC 6840, which requires a 
validator to ensure the NS type bit is set for an insecure delegation's 
NSEC(3) (or that it's covered by opt-out, but as Chris pointed out, that 
doesn't seem to be the case here).


I've left feedback for the dnsviz maintainer in the hopes that this case 
can be picked up in future.


Graham

--
Graham Clinch
Systems Programmer,
Lancaster University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Insecurity proof failed resolving newsletter.postbank.de - but why?

2014-01-20 Thread Chris Thompson 

On Jan 20 2014, Graham Clinch wrote:

I'm seeing a dnssec validation error that I can't pin down, for the 
domain: newsletter.postbank.de.


Neither of http://dnsviz.net/ and 
http://dnssec-debugger.verisignlabs.com/ report finding a problem, but 
two (ubuntu packaged) versions of bind report a failure validating the 
delegation as intentionally insecure.


I've tried versions:

BIND 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1
[...] 

and

BIND 9.8.1-P1 built with '--prefix=/usr' '--mandir=/usr/share/man'

[...]

I can reproduce the effect with BIND 9.9.4, 9.9.4-P2, 9.9,5b1.

I think the problem is as follows. The nameservers for postbank.de
generate a referral for newsletter.postbank.de which includes a
"minimally enclosing" NSEC3 like this:

o27g5ei98muhh7iemoihmbn83qndjsv1.postbank.de. 3600 IN NSEC3 1 0 1 \
 8BB5BA1AF57572EE O27G5EI98MUHH7IEMOIHMBN83QNDJSV2

The salt is generated dynamically (different each time) and doesn't
match postbank.de's NSEC3PARAM, but that shouldn't matter. What
*does* matter is that the NSEC3 "proves" that there are no NS
records as well (as no DS ones) for newsletter.postbank.de
(despite the fact that the NS records are included in the referral).
Note the absence of opt-out in the NSEC3.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Insecurity proof failed resolving newsletter.postbank.de - but why?

2014-01-20 Thread Tony Finch 
Graham Clinch  wrote:
>
> I'm seeing a dnssec validation error that I can't pin down, for the domain:
> newsletter.postbank.de.

Looks like a bug in BIND to me. It works out that there is no DS in the
parent then gets muddled. I note that postbank.de is in the middle of a
double-signature ZSK rollover. Dunno if that is relevant, but it is a bit
unusual.

20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
newsletter.postbank.de DS: in authvalidated
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
newsletter.postbank.de DS: resuming nsecvalidate
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
newsletter.postbank.de DS: looking for relevant NSEC3
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
newsletter.postbank.de DS: looking for relevant NSEC3
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
newsletter.postbank.de DS: NSEC3 proves name exists (owner) data=0
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: 
newsletter.postbank.de DS: nonexistence proof(s) found
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): received validation completion event
20-Jan-2014 12:18:51.415 dnssec: debug 3: validator @0x8071e8300: 
dns_validator_destroy
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): nonexistence validation OK

... right ...

20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): clone_results
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): done
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): stopeverything
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): cancelqueries
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): sendevents
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80ac04000(postbank.de/DNSKEY): doshutdown
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80ac04000(postbank.de/DNSKEY): stopeverything
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80ac04000(postbank.de/DNSKEY): cancelqueries
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80ac04000(postbank.de/DNSKEY): unlink
20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 
0x80ac04000(postbank.de/DNSKEY): destroy
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: 
newsletter.postbank.de A: in dsfetched2: ncache nxrrset
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: 
newsletter.postbank.de A: resuming proveunsecure
20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: 
newsletter.postbank.de A: insecurity proof failed

... what? ...

20-Jan-2014 12:18:51.416 resolver: debug 3: fetch 0x801859ff0 (fctx 
0x80b044860(newsletter.postbank.de/DS)): destroyfetch
20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 
0x80b044860(newsletter.postbank.de/DS): shutdown
20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 
0x80b044430(newsletter.postbank.de/A): received validation completion event
20-Jan-2014 12:18:51.416 dnssec: debug 3: validator @0x80bb74500: 
dns_validator_destroy
20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 
0x80b044430(newsletter.postbank.de/A): validation failed
20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 
0x80b044430(newsletter.postbank.de/A): add_bad
20-Jan-2014 12:18:51.416 lame-servers: info: error (insecurity proof failed) 
resolving 'newsletter.postbank.de/A/IN': 195.140.184.21#53

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Insecurity proof failed resolving newsletter.postbank.de - but why?

2014-01-20 Thread Graham Clinch 

Hi List,

I'm seeing a dnssec validation error that I can't pin down, for the 
domain: newsletter.postbank.de.


Neither of http://dnsviz.net/ and 
http://dnssec-debugger.verisignlabs.com/ report finding a problem, but 
two (ubuntu packaged) versions of bind report a failure validating the 
delegation as intentionally insecure.


I've tried versions:

BIND 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 
(Extended Support Version)  built with '--prefix=/usr' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' 
'--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' 
'--enable-largefile' '--with-libtool' '--enable-shared' 
'--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' 
'--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' 
'--enable-filter-' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'

using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
using libxml2 version: 2.9.1

and

BIND 9.8.1-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--sysconfdir=/etc/bind' 
'--localstatedir=/var' '--enable-threads' '--enable-largefile' 
'--with-libtool' '--enable-shared' '--enable-static' 
'--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' 
'--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing 
-DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2'

using OpenSSL version: OpenSSL 1.0.1 14 Mar 2012
using libxml2 version: 2.7.8


Running with -g 2 (on v9.9.3), I see:

==

20-Jan-2014 11:58:43.779 createfetch: newsletter.postbank.de SOA
20-Jan-2014 11:58:43.780 createfetch: . NS
20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 
0x7ff58b51f010 .
20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 
0x7ff58b520010 a.root-servers.net
20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 
0x7ff58b520010 b.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 c.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 d.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 e.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 f.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 g.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 h.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 i.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 j.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 k.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 l.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 m.root-servers.net

20-Jan-2014 11:58:43.819 createfetch: . DNSKEY
20-Jan-2014 11:58:43.881 createfetch: ns1.ecircle.de A
20-Jan-2014 11:58:43.882 createfetch: ns1.ecircle.de 
20-Jan-2014 11:58:43.882 createfetch: ns2.ecircle.de A
20-Jan-2014 11:58:43.882 createfetch: ns2.ecircle.de 
20-Jan-2014 11:58:43.905 createfetch: ns3.ecircle.com A
20-Jan-2014 11:58:43.905 createfetch: ns3.ecircle.com 
20-Jan-2014 11:58:43.938 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.939 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.943 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.974 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com

20-Jan-2014 11:58:43.974 createfetch: de DS
20-Jan-2014 11:58:44.120 createfetch: postbank.de DS
20-Jan-2014 11:58:44.244 createfetch: de DNSKEY
20-Jan-2014 11:58:44.270 createfetch: newsletter.postbank.de DS
20-Jan-2014 11:58:44.307 createfetch: postbank.de DNSKEY
20-Jan-2014 11:58:44.341 error (insecurity proof failed) resolving 
'newsletter.postbank.de/SOA/IN': 2a01:4f8:140:3482::3#53
20-Jan-2014 11:58:44.373 validating @0x7ff57c017bf0: 
newsletter.postbank.de SOA: got insecure response; parent indicates it 
should be secure
20-Jan-2014 11:58:44.373 error (insecurity proof failed) resolving 
'newsletter.postbank.de/SOA/IN': 195.140.184.21#53
20-Jan-2014 11:58:44.409 validating @0x7ff57c007f00: 
newsletter.postbank.de SOA: got insecure response; parent indicates it 
should be secure
20-Jan-2014 11:58:44.409 error (insecurity proof failed) resolving 
'newsletter.postbank.de/SOA/IN': 46.4.73.157#53
20-Jan-2014 11:58:44.410 client ::1#55009 (newsletter.postbank.de): 
query failed (SERVFAIL) for newsletter.postbank.de/IN/SOA at query.c:7406
20-Jan-2014 11:58:44.410 fetch completed at resolver.c:3044 for 
newsletter.postbank.de/SOA in 0.629817: failure/insecurity proof failed 
[domain:newsletter.postbank.de,referr