"broken trust chain" for non-existing AAAA records
lst_hoe02 at kwsoft.de
lst_hoe02 at kwsoft.de
Fri Nov 19 22:39:14 UTC 2010
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>
More information about the bind-users
mailing list