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

2010-06-02 Thread Matthew Seaman
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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

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

2010-06-02 Thread Chris Thompson
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

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

2010-06-02 Thread Casey Deccio
On Wed, Jun 2, 2010 at 8:40 AM, Paul Vixie vi...@isc.org wrote: Chris Thompson c...@cam.ac.uk writes: 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.) to

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

2010-06-02 Thread Casey Deccio
On Wed, Jun 2, 2010 at 7:44 AM, Chris Thompson c...@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

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

2010-06-02 Thread Matthew Seaman
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2010 18:49:44, Casey Deccio wrote: 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

Re: dnssec dlv

2010-05-21 Thread itservices88
I heard that root zone will be signed (or is already signed), so what changes would be required with respect to the current additions of adding dlv.isc.org as trust anchor and its associated trusted key ? Do we need to keep the isc dlv ? or add a new key for the root ? Thanks -dani On Thu, May

Re: dnssec dlv

2010-05-21 Thread Chris Thompson
On May 21 2010, itservices88 wrote: I heard that root zone will be signed (or is already signed), It's in DURZ mode. Read all about it at http://www.root-dnssec.org/ so what changes would be required with respect to the current

Re: dnssec dlv

2010-05-21 Thread itservices88
Thanks for details. -dani On Fri, May 21, 2010 at 9:04 AM, Chris Thompson c...@cam.ac.uk wrote: On May 21 2010, itservices88 wrote: I heard that root zone will be signed (or is already signed), It's in DURZ mode. Read all about it at http://www.root-dnssec.org/

Re: dnssec dlv

2010-05-21 Thread Mark Andrews
In message aanlktik1cd0xkearue2brdkxpnb6cvyz4zn-qvuv9...@mail.gmail.com, itse rvices88 writes: I heard that root zone will be signed (or is already signed), so what changes would be required with respect to the current additions of adding dlv.isc.org as trust anchor and its associated

dnssec dlv

2010-05-20 Thread itservices88
Hi, Whenever i enable: dnssec-lookaside . trust-anchor DLV.ISC.ORG; in the named.conf, restart bind, the dns resolution stops. One the same FC12 machine, dig using an outside dns server has no issues resolving with +dnssec option. I am using bind 9.6.2 that came with FC12. Any thoughts ?

Re: dnssec dlv

2010-05-20 Thread Mark Andrews
In message aanlktikyznh9_cgpb2efye_-yuu4n3bs75fwzp-jz...@mail.gmail.com, itse rvices88 writes: Hi, Whenever i enable: dnssec-lookaside . trust-anchor DLV.ISC.ORG; in the named.conf, restart bind, the dns resolution stops. One the same FC12 machine, dig using an outside dns server has

Re: dnssec dlv

2010-05-20 Thread itservices88
I missed the trusted key .. Thanks Here is the other output # dig +cd +dnssec dlv.isc.org dnskey @localhost ; DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 +cd +dnssec dlv.isc.orgdnskey @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 63788 ;;