Unknown RR in .in domain

Chris Thompson cet1 at cam.ac.uk
Mon Feb 6 21:18:21 UTC 2012


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: cet1 at cam.ac.uk



More information about the bind-users mailing list