Unknown RR in .in domain

[Mark Andrews]

In message <001301cce503$0716a950$1543fbf0$@nic.in>, Gaurav kansal writes:
> 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 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 at isc.org