Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can someone please explain, in simple language, the meaning of opt-out flag in the NSEC3 RR. I did read RFC 5155 and understand nothing.

share|improve this question
up vote 3 down vote accepted

NSEC3 records can be created in one of two different ways: for all delegations, or just for secure delegations. The opt-out flag tells you which method is in use. The reason for the flag is to allow very large zones primarily made up of delegations (i.e. TLDs) to not have to generate NSEC3 records and their corresponding RRSIG records for every single delegation. This is important a TLDs like .com with ~100,000,000 delegations; signing every single delegation would make an extremely massive zone file!

There is no difference between secure delegations when the opt-out bit is set or not.

For insecure delegations without the opt-out bit set, you get the delegating NS records plus the NSEC3 and RRSIG for that delegation. Here is an example for, which is an insecure delegation (no DS record provided) in the .gov zone, which does not use the opt-out bit:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9019
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags:; udp: 1472
;         IN  A

;; AUTHORITY SECTION:      86400   IN  NS      86400   IN  NS 86400 IN NSEC3 1 0 8 4C44934802D3 56K48N2V1IV9H7F4HJ05N62QI9C29JV2 NS 86400 IN RRSIG NSEC3 7 2 86400 20120516040019 20120511040019 35464 gov. OlOx3rG7ShAptVt1XTqcXLOtInxEqyfg1b6+vBlWiqSBZ8pkfk/IOFOm 49lbKkrjY2ibw98GaMdjUYCUUDKOX+eTe+HTfxginIfJ3FWOxB+TPFn1 /UEu4QAgEkWdgpT6NbCge9vWnhSxTCYNxTolVuhWq+sp59zodbAMERVi rIdFyoNpX1zijU1tjm9j8a+jFeN7tjf2fgzJQPpk/qNMgmgfp2GerPUX 5kVkhjoXPgRkLmy2W5PwbgWP4zOTRFuLxz0PsRfoqLUHYYEXPMQ0jimW ESl1LDRnHjdQDTD1qYPBCiVNxufaewZMGhTwP901CH3FLr6Gku7ptYkD 5ukEFQ==

If we calculate the NSEC3 hash given a salt of 4C44934802D3 and 8 extra iterations, it is an exact match due to the fact that an NSEC3 records is generated for every delegation:

$ -i 8 -s 4C44934802D3

For insecure delegations with the opt-out bit set, you will not get an NSEC3 record which provides a list of resource record types available for that domain. Instead you get a "closest encloser proof," as described in section 7.2.1 of RFC 5155:

This example is an insecure delegation within the .com zone, which uses the opt-out flag:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48336
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 6
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags: do; udp: 512
;         IN  A

;; AUTHORITY SECTION:      172800  IN  NS      172800  IN  NS      172800  IN  NS      172800  IN  NS      172800  IN  NS 86400 IN NSEC3 1 1 0 - CK0RFQAOES8CTVNVNH4G6Q85NOQAQ8I9 NS SOA RRSIG DNSKEY NSEC3PARAM 86400 IN RRSIG NSEC3 8 2 86400 20120515041703 20120508030703 23339 com. RiL6MRN/fPVBjpyANDKurwSgdwgkdsRdB4ADWK7YTJeY2KNnBpjOX+FT +2a/XZR2ylP+G47L8k+DrJCHuAkr1wOYcOj7goiqErDwu+Cm5HZosAL2 EyRqNOHHgTDXlG6PGgyEe2DO0jWgmkyYX7+o0jpYP0m6QNDaRuf166np nkA= 86400 IN NSEC3 1 1 0 - GPLVOUV0V27L8DPOOBNLQU1VHFRMMPUT NS DS RRSIG 86400 IN RRSIG NSEC3 8 2 86400 20120518085726 20120511074726 23339 com. VmtH/BYw8H98FJM7YLxLIG0cfReERp5eNh3+bCu7EfWgSuWXn6OXdd4b rIMloxDXe9v/fdyd7RqwDiNLMPMhp8wRJOhKcqT0MczHFEUzy0SnXM3d SABY5d1AJr8YJNL+ZOgbiT445gn7HBET3OL+G5MfZPti+yhBnUvGlPYx UQ8=

The first NSEC3 record is for the com domain itself (it's pretty easy to spot given that it has SOA, DNSKEY, and NSEC3PARAM in the list of RR types. It is the closest provable encloser.

The second NSEC3 record is to "cover" This is to prove that an NSEC3 record for does not exist, as it is not a secure delegation.

Here are the calculated hashes for comparison:

$ com

Unless you are running a TLD zone or other zone with a huge number of delegations, it is not necessary to use the opt-out flag.

share|improve this answer
I hoped it would be simple, though I finally managed to go through it. :) Thanks. What I understand now is that NS records which have no corresponding DS records, treated like they don't exist by NSEC3. I.E. when I see opt-out NSEC3, I can still expect NS records, am I getting it right ? – Sandman4 May 13 '12 at 9:58
Yes, the NSEC3 records returned for an insecure delegation in an opt-out zone is very similar to the NSEC3 records you get for an NXDOMAIN response, the only difference is that an NXDOMAIN would also return the NSEC3 record for the wildcard as well. – Cakemox May 13 '12 at 10:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.