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: ma...@isc.org _______________________________________________ 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
