| | 532 | |
|---|
| | 533 | <section title="Responding to NSEC3 Queries"> |
|---|
| | 534 | |
|---|
| | 535 | <t> |
|---|
| | 536 | Since NSEC3 records do not correspond to names that exist within the |
|---|
| | 537 | zone, there is the potential for confusion when responding to queries |
|---|
| | 538 | that have the QTYPE set to NSEC3 (or ANY). In order to avoid creating |
|---|
| | 539 | an infinite recursion, there is only one consistent way to respond to |
|---|
| | 540 | NSEC3 queries, and that is to act as if the NSEC3 record did not exist. |
|---|
| | 541 | </t> |
|---|
| | 542 | |
|---|
| | 543 | <t> |
|---|
| | 544 | So, if presented with a query where QTYPE is NSEC3 and QNAME is a name |
|---|
| | 545 | that exists in the zone with an RRTYPE other than NSEC3, then the |
|---|
| | 546 | responder should deny the existence of the NSEC3 RRSet and prove it |
|---|
| | 547 | with an NSEC3 record corresponding to the hash of the QNAME (which |
|---|
| | 548 | will, of course, exist), as usual. |
|---|
| | 549 | </t> |
|---|
| | 550 | |
|---|
| | 551 | <t> |
|---|
| | 552 | If the QTYPE is NSEC3 and QNAME is a name that only exists by virtue |
|---|
| | 553 | of an NSEC3 record at that name, then the response should be an |
|---|
| | 554 | NXDOMAIN with appropriate NSEC3 records as proof. |
|---|
| | 555 | </t> |
|---|
| | 556 | |
|---|
| | 557 | </section> |
|---|
| | 558 | |
|---|
