Re: "broken trust chain" for non-existing AAAA records

[lst_hoe02]

Zitat von Mark Andrews <ma...@isc.org>:

t.de writes:

In message <20101118131400.37717e5p5tard...@webmail.kwsoft.de>, lst_ho...@kwsof

We are using Bind 9.7 at the border to resolve DNS queries for a small
LAN. After moving forward in using IPv6 we discovered many "broken
trust chain" errors in the bind log for non existing AAAA records. One
example is

Nov 18 01:18:21 firewall named[27580]: error (broken trust chain)
resolving 'smtp.g.comcast.net/AAAA/IN': 76.96.53.47#53
Nov 18 01:18:21 firewall named[27580]: error (broken trust chain)
resolving 'smtp.g.comcast.net/AAAA/IN': 68.87.66.201#53
Nov 18 01:18:29 firewall named[27580]: error (broken trust chain)
resolving 'smtp.g.comcast.net/AAAA/IN': 76.96.53.47#53
Nov 18 01:18:29 firewall named[27580]: error (broken trust chain)
resolving 'smtp.g.comcast.net/AAAA/IN': 76.96.53.47#53

From what i can see there is no DNSSEC for comcast.net so this should
not happen and the A record just resolve fine. Any comment if this
should worry me?

A broken chain of trust can be *anywhere* in the trust chain.

Yes, but the A records resolve without hassle, but also without DNSSEC.

Remember named has to prove that a answer should be insecure (not
signed) by looking for the absence of a DS RRset at a delegation
point above the name in question.

If validation is working correctly you should be able to get a
validated negative response for DS net.  Note the "ad" in the flags
below which indicates that named thinks the answer is secure.

So the non existant records (NSEC?) have an other trust chain as the A records?

Also please report the *exact* version in future.  There is more
than one BIND 9.7 version.  The latest is BIND 9.7.2-P2.

This is the version delivered by Ubunutu 10.04 LTS which report as 9.7.0-P1.

; <<>> DiG 9.6.0-APPLE-P2 <<>> ds net +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56977
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

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

;; AUTHORITY SECTION:

net.                    9027    IN      NSEC    nf. NS RRSIG NSEC

. 9027 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010111801 1800 900 604800 86400 . 9027 IN RRSIG SOA 8 0 86400 20101125000000 20101117230000 40288 . Pn3OPCeNSrFiCAyf306zvUyN8+0YbfpWP4YCzr67lexD9Kw/shkBgN2/ Cfy/t7ikHpR7+DFyNi21EkoN+12jsz/XMi5R2GgG3JZtVxtMJPpRQk0O q4KsIA/hdHD7jWsoXsM/6WY1jDWhvPpkIv3dtJ2H/fhUfOfjcX1miEYY BaY= net. 9027 IN RRSIG NSEC 8 1 86400 20101125000000 20101117230000 40288 . s4//hXJ69+BcKrB8ln03YGQNSVKCdGDALrhntcgnMU64ueFMTv4cFuzv jZWFdg+dgdQa59VLx2XCG0jMXzXKj27PGPAY1ARRRBxNA4yrJXeF8v8f Pwv3AmshHRufrbwbs8gZyP/WXqszXkrVVYRSMbcTKdkT62DkQNqMH7xP uV0=

Many Thanks

Andreas

That's the same i get but i wonder why our Bind resolver think there should be some chain.

smime.p7s
Description: S/MIME Cryptographic Signature

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