On Feb 6 2012, Gaurav kansal wrote:
Thanks Alan.
I got it.
But why I am getting two NSEC3 records for .in domain?? Shouldn't I
get one NSEC3 RR only
Because the in servers are denying the existence of a signed delegation
for nknsec.in, while (because the zone uses opt-out) allowing the
possibility that there is an unsigned one - which of course there is.
(This makes the DNSSEC records in the authority section of the referral
response look rather like those for a NXDOMAIN one.)
Picking an authoritative server for in at random:
$ dig +dnssec +norec +multi nknsec.in @c0.in.afilias-nst.info.
[...]
;; QUESTION SECTION:
;nknsec.in. IN A
;; AUTHORITY SECTION:
nknsec.in. 86400 IN NS ns1.nknsec.in.
nknsec.in. 86400 IN NS ns3.nknsec.in.
9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN NSEC3 1 1 1 D399EAAB (
9SJ987F06N7BLS7MRN2KR9252S6281C7
NS SOA RRSIG DNSKEY NSEC3PARAM )
9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN RRSIG NSEC3 7 2 86400 (
20120227205111 20120206195111 19608 in.
LU3eRPCkAGVTAaSsCmg99OYtfrl6vxWu2d0p9LEp9Pw/
H9LxAGy1owSx9a0FXOjL+iNb7QOQntdAcqcscgDeBLdS
1i2XcMxOhyR5DvZ8BluYOCLEgM14yGBnmy23JB1CTtUo
DAGceFp9CijygorEIZbA6EYum3IRkk38o0EMLiA= )
9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN NSEC3 1 1 1 D399EAAB (
9RLLTFRS0PA4VCFC17QMBM4SU59P6Q6F
A RRSIG )
9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN RRSIG NSEC3 7 2 86400 (
20120225164542 20120204154542 19608 in.
RHCtdth93BOuuTNMUOU6u/Y/EsYKo1LpZ9vfF+f8C6Vc
Q+ajkr8zqi3Cg8gA2kqho6QY55FE4PeLcfo5yFPkO/S+
dK+5mRB5zenw6/HL4QllyyLcviwW1tJ+nNF4M7vTemPI
LLAQvWOl1j3McdJAvgoiFfNn4JRii91RxNxLGUI= )
The first NSEC3 record validates facts about the name in:
$ nsec3hash D399EAAB 1 1 in
9SF2FOMUOR72M596CCSODG86639E6ODR (salt=D399EAAB, hash=1, iterations=1)
[Note the match to the start of the NSEC3 range]
The second NSEC3 record validates facts (the non-existence for DNSSEC
purposes, in fact) about the name nknsec.in:
$ nsec3hash D399EAAB 1 1 nknsec.in
9QUOB43RU88DVJLS8B6SB52OQVD8BH80 (salt=D399EAAB, hash=1, iterations=1)
[That hash value is in the range 9QQEME... - 9RLLTF... of the NSEC3]
Read RFC 5155 section 7.2 in all its horrid detail, especially
understanding the whole business of closest encounters, if
you want to know more.
As Alan said, you will never, *ever* get anywhere trying to analyse
DNSSEC problems with (quite seriously) out-of-date tools. Also if
you see strange things in dig +trace output, concentrate on the
specific iterative stage it was working through at the time - in
your example, the response of the authoritative in servers.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
