DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Casey Deccio]

On Wed, Jun 2, 2010 at 7:44 AM, Chris Thompson <cet1 at cam.ac.uk> wrote:

> On Jun 2 2010, Matthew Seaman wrote:
>
>  I'm DNSSEC enabling the .ip6.arpa zone for my IPv6 allocation and
>> registering it with dlv.isc.org.  Using bind-9.7.0-p2 dnssec tools.
>>
>> Everything seems to be working well, but when I test using the Sandia
>> Labs dnsviz.net tool I get inconsistent results.
>>
>> My mail, etc. server on 2001:8b0:151:1:e2cb:4eff:fe26:6481 appears as
>> 'bogus'
>>
>>
>> http://dnsviz.net/d/1.8.4.6.6.2.e.f.f.f.e.4.b.c.2.e.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/
>>
>> Yet my personal laptop on 2001:8b0:151:1:fa1e:dfff:feda:c0bb is all good:
>>
>>
>> http://dnsviz.net/d/b.b.0.c.a.d.e.f.f.f.f.d.e.1.a.f.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/
>>
>> What am I doing wrong?
>>
>
> Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
> records in an RRset, as your first case has? (On the other hand it
> handles multiple A records in forward zones OK.)
>
>
This has been fixed.  The problem had to do with establishing a canonical
ordering of RRs within an RRset for the purposes of verifying an RRSIG.
dnspython's default comparison operators don't follow canonical ordering
from RFC 4034, so I had to make some provisions to order properly.  This
didn't affect A RRsets with multiple RRs because the order of A-type rdata
was the same using both orderings.

Thanks for bringing this to my attention.

Regards,
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100602/3d692ba1/attachment.html>