[DNSOP] Re: DELEXT: Proposed Delegation Type Ranges
Roy Arends <[email protected]>
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
> On 21 Aug 2026, at 19:12, Michael Richardson <[email protected]> wrote: > > > Roy Arends <[email protected]> wrote: >> Range 2: NS-Preserving Delegation Types > >> A Delegation Type in this range does not alter the inclusion of the NS >> RRset in a referral. When a delegation contains Delegation Types from >> this range, and none from Range 1, an authoritative server MUST include >> the NS RRset in the referral, together with the Delegation Type >> RRsets. If a delegation also contains Delegation Types from Range 1, >> the Range 1 rule takes precedence: the authoritative server MUST NOT >> include the NS RRset in the referral. > > I'm surprised by the precedence, but I can mostly see why. > If we were allocating DS today (without DELEG existing), would DS come from > this range then? That is correct. >> Range 3: On-Demand Delegation Types >> Delegation Types in this range are not included in referrals. An >> authoritative server MUST NOT include Delegation Types from this range >> in a referral. Delegation Types in this range MUST be explicitly >> queried. > > Can you give us an example? A Range 3 example could be a Delegation Type carrying information that is useful in the context of a delegation, but is not needed to perform ordinary resolution or validation and therefore would be wasteful to include in every referral. One plausible hypothetical example is delegation contact or error reporting records: DOMAINADMIN: provides a URI or other information identifying where operational information about the delegation can be obtained. DERROR: provides a path to report errors about resolving or validating this domain. A resolver doesn’t need this to follow the delegation, so there is no reason to send it with every referral. An operator, diagnostic tool, or other interested client could explicitly query it. Take these with a grain of salt, as these are mere examples, but you get the gist. Roy > Have we special cased this before? No. But we have dismissed ideas in the past since they’d require records to be present at the delegation point in the delegating zone. > >> Subsequently, the DELEXT draft will read: > >> Decimal Hex Registration Procedures Note > >> 61440- 0xF000- Expert Review or NS-Omitting delegation TYPEs >> 61567 0xF07F Standards Action > >> 61568- 0xF080- Expert Review or NS-Preserving delegation TYPEs >> 61695 0xF0FF Standards Action > >> 61696- 0xF100- Expert Review or On-Demand delegation TYPEs >> 61935 0xF1EF Standards Action > >> 61936- 0xF1F0- Private Use Private delegation TYPEs >> 61951 0xF1FF > > Total cost seems to be 512 values from our 64K total. > That seems fine, even if we never use Range 3. Ack. Roy > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > ** My working hours and your working hours may be different. ** > ** Please do not feel obligated to reply outside your normal working hours ** > > > > _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]