"broken trust chain" for non-existing AAAA records

[lst_hoe02 at kwsoft.de]

Zitat von Mark Andrews <marka at isc.org>:

>
> In message <20101118131400.37717e5p5tardzm0 at webmail.kwsoft.de>,  
> lst_hoe02 at kwsof
> t.de writes:
>> 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:
> .			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=
> net.			9027	IN	NSEC	nf. NS RRSIG NSEC

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

Many Thanks

Andreas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6046 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20101119/6e05e4f3/attachment.bin>