Dear Team,



Can anyone please tell me why TYPE50 RR is showing in response coming from
.in domain????????

Output is attached for reference.





C:\Users\kansal>dig nknsec.in +dnssec +trace @149.20.64.20

;; global options:  printcmd

.                       451843  IN      NS      b.root-servers.net.

.                       451843  IN      NS      f.root-servers.net.

.                       451843  IN      RRSIG   NS 8 0 518400 20120212000000
20120204230000 51201 .
HxV0KOMboM702IIzHBF5rgISK4amxurIuyQ7evdSNHhEGpMYiz09GJjo
U/PWAjW/JUBexYx7Gu20AlNTHMY8/kYaLdHSd1TdWjCh2cTaL2F7GJKg
eGS8xSiwBQsRcMjI0TIds4Lk8m53sFToQYBp6OecYr/7m8RuQMuo3MDB EX
;; Received 605 bytes from 149.20.64.20#53(149.20.64.20) in 748 ms



in.                     172800  IN      NS      a0.in.afilias-nst.info.

in.                     172800  IN      NS      b2.in.afilias-nst.org.

in.                     86400   IN      DS      64788 7 1
82E4E46622B646086C1051A6093DEB897BD1C022

in.                     86400   IN      DS      64788 7 2
4021B67522D8935C8D8D7CE32900ACB382F55E3D1A8DE920233CBE70 A13DA85B

in.                     86400   IN      RRSIG   DS 8 1 86400 20120213000000
20120205230000 51201 .
ayli/LYjwoPZQK8A59cah2CuvE80dFaDXiYQCL2KEVlnxpPzuxadkczy
TUwybD+NitZ5r2otsTrkoTAWzr4kufzHdz499Nh9k+76fnfnF/icL72v
Smj3FttpGvFBd1lU2XE6eQmBXNNfkV8b+tfhOoTzQcfDXH2+TzWMs8C3 Zc
;; Received 835 bytes from 192.33.4.12#53(c.root-servers.net) in 336 ms



nknsec.in.              86400   IN      NS      ns3.nknsec.in.

nknsec.in.              86400   IN      NS      ns1.nknsec.in.

9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN TYPE50 \# 39
0101000104D399EAAB144F26941DE035CEBAF0F6DDC54DA445170C24
0587000722000000000290

9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN RRSIG TYPE50 7 2 86400
20120227182528 20120206172528 19608 in.
axGEetFJzkQxkUNbIV5E/zpOSVWA3TamU+9ozZoxTQ0llVC6D4mtnhjd
Q0RqRjUkeNo9N6aESH57IkN8gQxraJHAXznczRu2OqeGtIwqzHO1olfU
l4XzVGnCsuSV3AQnssRi7kaojBu8I11Rmwm6HdLxevXem2SstAD2vXmA Ce


9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN TYPE50 \# 38
0101000104D399EAAB144EEB5EBF7C06544FB1EC09F565D89CF15393
68CF0006400000000002

9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN RRSIG TYPE50 7 2 86400
20120225164542 20120204154542 19608 in.
RHCtdth93BOuuTNMUOU6u/Y/EsYKo1LpZ9vfF+f8C6VcQ+ajkr8zqi3C
g8gA2kqho6QY55FE4PeLcfo5yFPkO/S+dK+5mRB5zenw6/HL4QllyyLc
viwW1tJ+nNF4M7vTemPILLAQvWOl1j3McdJAvgoiFfNn4JRii91RxNxL GU
;; Received 609 bytes from 220.226.100.30#53(a1.in.afilias-nst.in) in 82 ms













Thanks n Regards,
GAURAV KANSAL
9910118448
VoIP - 6259
Operation And Routing Unit
NIC , NEW DELHI



Please don't print this e-mail until & unless you really need, it will save
Trees on Planet Earth.
IPv4 is Over,

Are your ready for new Network.

Because your version of DIG does not understand NSEC3 records.

http://tools.ietf.org/html/rfc5155

AlanC
--
alan*******| 1.919.355.8851

Thanks Alan.
I got it.

But why I am getting two NSEC3 records for .in domain?????????? Shouldn't I
get one NSEC3 RR only????

9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN TYPE50 \# 39
0101000104D399EAAB144F26941DE035CEBAF0F6DDC54DA445170C24
0587000722000000000290
9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN RRSIG TYPE50 7 2 86400
20120227172834 20120206162834 19608 in.
UXEUDIFav8JWIzpA+Wm42o8iQQ4PE0e2kCIXJQOZ2Y6VCarzzQ3t1pZ+
Pg5IU1/knZ5QHHkAR9Uz4JIB44FSOv/FjuhPf2UrvkiODIGuQnxsIc/S
zVCuGCS91irQmF1JtEHgFmA/TCycl3uidbyHCwQyowHL6y+R3ZGm+2qs 9i
9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN TYPE50 \# 38
0101000104D399EAAB144EEB5EBF7C06544FB1EC09F565D89CF15393
68CF0006400000000002
9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN RRSIG TYPE50 7 2 86400
20120225164542 20120204154542 19608 in.
RHCtdth93BOuuTNMUOU6u/Y/EsYKo1LpZ9vfF+f8C6VcQ+ajkr8zqi3C
g8gA2kqho6QY55FE4PeLcfo5yFPkO/S+dK+5mRB5zenw6/HL4QllyyLc
viwW1tJ+nNF4M7vTemPILLAQvWOl1j3McdJAvgoiFfNn4JRii91RxNxL GU

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 *******.
;; 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Ó99EAAB, 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Ó99EAAB, 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.

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*******

Because that is what is required.  We are sending the proof thay that a DS
record does not exist at the delegation point.

7.2.4.  No Data Responses, QTYPE is DS

   If there is an NSEC3 RR that matches QNAME, the server MUST return it
   in the response.  The bits corresponding with DS and CNAME MUST NOT
   be set in the Type Bit Maps field of this NSEC3 RR.

   If no NSEC3 RR matches QNAME, the server MUST return a closest
   provable encloser proof for QNAME.  The NSEC3 RR that covers the
   "next closer" name MUST have the Opt-Out bit set (note that this is
   true by definition -- if the Opt-Out bit is not set, something has
   gone wrong).

   If a server is authoritative for both sides of a zone cut at QNAME,
   the server MUST return the proof from the parent side of the zone
   cut.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******