RFC 4471

Derivation of DNS Name Predecessor and Successor

πŸ“… published September 2006, from ietf

RFC 4471: Derivation of DNS Name Predecessor and Successor πŸ’–

okay bestie, let's get into this one πŸŽ€ It's RFC 4471, called Derivation of DNS Name Predecessor and Successor. It came out of the Network Working Group, written by G. Sisson and B. Laurie, both from Nominet. It's in the Experimental category and it's dated September 2006. The title block doesn't list any RFCs it obsoletes or updates, so it stands on its own πŸ¦‹

Status of This Memo πŸ“œ

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. πŸ’…

Copyright (C) The Internet Society (2006).

Abstract ✨

okay so this doc describes two methods for working out the canonically-ordered predecessor and successor of a DNS name 🧚 These methods can be used for dynamic NSEC resource record synthesis. That's what lets security-aware name servers give authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. Main character energy, honestly πŸ‘‘

Table of Contents 🌸

   1. Introduction ....................................................2
   2. Notational Conventions ..........................................3
   3. Derivations .....................................................3
      3.1. Absolute Method ............................................3
           3.1.1. Derivation of DNS Name Predecessor ..................3
           3.1.2. Derivation of DNS Name Successor ....................4
      3.2. Modified Method ............................................4
           3.2.1. Derivation of DNS Name Predecessor ..................5
           3.2.2. Derivation of DNS Name Successor ....................6
   4. Notes ...........................................................6
      4.1. Test for Existence .........................................6
      4.2. Case Considerations ........................................7
      4.3. Choice of Range ............................................7
      4.4. Wild Card Considerations ...................................8
      4.5. Possible Modifications .....................................8
           4.5.1. Restriction of Effective Maximum DNS Name Length ....8
           4.5.2. Use of Modified Method with Zones Containing

                  SRV RRs .............................................8
   5. Examples ........................................................9
      5.1. Examples of Immediate Predecessors Using Absolute Method ..10
      5.2. Examples of Immediate Successors Using Absolute Method ....14
      5.3. Examples of Predecessors Using Modified Method ............19
      5.4. Examples of Successors Using Modified Method ..............20
   6. Security Considerations ........................................21
   7. Acknowledgements ...............................................21
   8. References .....................................................21
      8.1. Normative References ......................................21
      8.2. Informative References ....................................22

1. Introduction 🌷

okay so one of the proposals for avoiding the exposure of zone information while DNSSEC is being deployed is dynamic NSEC resource record (RR) synthesis πŸ” It's described in [DNSSEC-TRANS] and [RFC4470]. The idea is generating NSEC RRs that just span the query name for non-existent owner names. To make that work, the DNS names that would occur just before and just after a given query name have to be calculated in real time, because keeping a list of every possible owner name in a zone would be impracticable 😭

Section 6.1 of [RFC4034] defines canonical DNS name order. This document doesn't amend or modify that definition. BUT the derivation of an immediate predecessor and successor is, although trivial, kinda non-obvious πŸ™ˆ So several methods are described here to help implementors, and as a reference for other interested folks.

This document describes two methods:

  1. An "absolute method", which returns the immediate predecessor or successor of a domain name such that no valid DNS name could exist between that DNS name and the predecessor or successor. πŸ“
  2. A "modified method", which returns a predecessor and successor that are more economical in size and computation. This method is restricted to use with zones consisting exclusively of owner names that contain no more than one label more than the owner name of the apex, where the longest possible owner name (i.e., one with a maximum length left-most label) would not exceed the maximum DNS name length. This is, however, the type of zone for which the technique of online signing is most likely to be used. ✨

2. Notational Conventions πŸŽ€

The following notational conventions are used in this document for economy of expression. Lowkey a cute little cheat sheet:

  • N: An unspecified DNS name.
  • P(N): Immediate predecessor to N (absolute method).
  • S(N): Immediate successor to N (absolute method).
  • P'(N): Predecessor to N (modified method).
  • S'(N): Successor to N (modified method).

3.2.2. Derivation of DNS Name Successor ✨

okay so bestie, here's how we derive S'(N) πŸ’…

  1. If N is two or more labels longer than the owner name of the apex, keep yeeting the least significant (left-most) label until N is only one label longer than the owner name of the apex. Then move on to the next step. 🫢
  2. If the least significant (left-most) label of N is one or more octets shorter than the maximum label length, tack an octet of the minimum sort value onto that label. If not, just move on to the next step. 🌸
  3. Find the least significant (right-most) octet inside the least significant (left-most) label whose value is still less than the maximum sort value (e.g., 0xff). Bump it up by one, skipping any values that match uppercase US-ASCII letters πŸ™ˆ, then chop off any octets sitting to its right. If every octet in the label is already the maximum sort value, move on to the next step. πŸ”₯
  4. Remove the least significant (left-most) label. ✨ (This only happens when the least significant label is at the maximum label length and is made up entirely of octets with the maximum sort value. It has wrapped around to the owner name of the zone apex, so it's giving full circle πŸŒˆπŸ’€)

4. Notes ✨

4.1. Test for Existence πŸ”

Before you use the result of P(N) or P'(N) as the owner name of an NSEC RR in a DNS response, a name server should test whether that name exists 🧐. If it does, you can either use a standard non-synthesised NSEC RR, or the synthesised NSEC RR should reflect the RRset types that exist at the NSEC RR's owner name in the Type Bit Map field, as specified by Section 4.1.2 of [RFC4034] πŸŽ€. Implementors will likely find it simpler to use a non-synthesised NSEC RR, honestly the easy-mode choice πŸ’–. For further details, see Section 2 of [RFC4470].

4.2. Case Considerations πŸ”€

Section 3.5 of [RFC1034] says that "while upper and lower case letters are allowed in names, no significance is attached to the case". Then Section 6.1 of [RFC4034] adds that when working out canonical DNS name order, "uppercase US-ASCII letters are treated as if they were lowercase US-ASCII letters" 🧁. So the values that match uppercase US-ASCII letters have to be skipped when you decrement and increment octets in the derivations from Section 3. Main character skip energy πŸ‘‘

Here's some illustrative pseudo-code (it's not a rule, just a vibe check) πŸ¦‹:

Decrement the value of an octet:

      if (octet == '[')       // '[' is just after uppercase 'Z'
              octet = '@';    // '@' is just prior to uppercase 'A'
      else
              octet--;

Increment the value of an octet:

      if (octet == '@')       // '@' is just prior to uppercase 'A'
              octet = '[';    // '[' is just after uppercase 'Z'
      else
              octet++;

4.3. Choice of Range 🌷

[RFC2181] clears things up by saying that "any binary string whatever can be used as the label of any resource record" πŸ’œ. So the minimum sort value can be 0x00 and the maximum sort value can be 0xff, and then the range of possible values is any DNS name whose octets are anything except the ones matching uppercase US-ASCII letters. Wild and free πŸ¦„

That said, if every owner name in a zone is in the letter-digit-hyphen (LDH) format from [RFC1034], it might be a good idea to narrow the range down to DNS names with only LDH values. This does a few things:

  1. it makes the output of tools such as dig' and nslookup' less subject to confusion πŸ€“,
  2. it minimises the impact that NSEC RRs with DNS names containing non-LDH values (or non-printable values) might have on faulty DNS resolver implementations 🫣, and
  3. it stops results that are wildcard DNS names from being possible (see Section 4.4) πŸ™…β€β™€οΈ.

To get this, use a minimum sort value of 0x1f (US-ASCII character -') and a maximum sort value of 0x7a (US-ASCII character lowercase z'), then skip non-LDH, non-lowercase values when you increment or decrement octets. Clean girl aesthetic 🧼✨

4.4. Wild Card Considerations πŸƒ

Neither derivation rules out the chance that the result is a DNS name containing a wildcard label, meaning a label with one single octet whose value is 0x2a (US-ASCII character `*'). If you want to dodge wildcard DNS names, you can add extra tests. Or, if you restrict the octet values to letter-digit-hyphen (LDH) characters (see Section 4.3), those names just won't show up πŸ™…β€β™€οΈ.

Also, it's super unlikely that a wildcard DNS name shows up by accident. Even if one ends up as the owner name of an NSEC RR, or in its RDATA, it's just treated as a literal DNS name with no special meaning πŸ’…πŸŒΈ.

4.5. Possible Modifications πŸ› οΈ

4.5.1. Restriction of Effective Maximum DNS Name Length πŸ“

[RFC1034] says that "the total number of octets that represent a name (i.e., the sum of all label octets and label lengths) is limited to 255", and that count includes the null (zero-length) label for the root 🌍. When you're deriving predecessors and successors during NSEC RR synthesis, you can effectively cap the maximum DNS name length at the length of the longest DNS name in the zone. This keeps responses with synthesised NSEC RRs smaller πŸŽ€. But especially with the modified method, it might add some extra computational complexity 🀯.

Heads up though: this change reveals info about the longest name in the zone πŸ‘€. And when the zone's contents change, like during dynamic updates and zone transfers, you have to make sure the effective maximum DNS name length still matches the new contents. Don't be sloppy about it, bestie πŸ’–.

4.5.2. Use of Modified Method with Zones Containing SRV RRs 🧚

Normally, you can't use the modified method in zones that contain Service Record (SRV) RRs [RFC2782], because SRV RRs have owner names with multiple labels πŸ™ƒ. But you can still make SRV RRs work with a few techniques. There are at least four possible ways to do it 🌈:

  1. Use conventional NSEC RRs for the part of the zone holding first-level labels that begin with the underscore (_') character. For generating these NSEC RRs, you can assume the existence of (possibly fictional) owner names 9{63}' and `a', which give you a lower and upper bound for this region. Then every query where the QNAME doesn't exist but has a first-level label starting with an underscore can be handled with the normal DNSSEC protocol πŸ’–.

This approach makes it possible to enumerate every DNS name in the zone with a first-level label starting with an underscore, including all SRV RRs. But the zone admin may care about that less than about the overhead of the absolute method or the variants of the modified method below πŸ€·β€β™€οΈ.

  1. The absolute method could be used to synthesise NSEC RRs for all queries where the QNAME has a leading underscore. But this brings back the absolute method's susceptibility to denial of service activity 😭, since an attacker could send queries for an effectively inexhaustible supply of domain names that begin with a leading underscore 🚨.
  2. A variant of the modified method could be used to synthesise NSEC RRs for all queries where the QNAME has a leading underscore. This variant assumes that all predecessors and successors to such queries may consist of two labels rather than only one 🧩. It adds a little extra complexity, but it doesn't take on the full increase in response size and computational complexity of the absolute method 🌸.
  3. Finally, you could use a variant of the modified method that assumes all owner names in the zone consist of one or two labels 🫠. However, this cancels out much of the reduction in response size from the modified method, and it may end up nearly as computationally complex as the absolute method πŸ’€.

5. Examples πŸ“

In the following examples, things are set up like this πŸŽ€:

  • the owner name of the zone apex is "example.com.",
  • the range of octet values is 0x00 - 0xff excluding values corresponding to uppercase US-ASCII letters, and
  • non-printable octet values are expressed as three-digit decimal numbers preceded by a backslash (as specified in Section 5.1 of [RFC1035]) πŸ”’.

5.1. Examples of Immediate Predecessors Using Absolute Method πŸ¦‹

okay so let's look at some real examples of how the immediate predecessor comes out using the absolute method πŸ’… first up is a typical case ✨

P(foo.example.com.) =

           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255.\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255.\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255.fon\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255.example.com.

or, in alternate notation:

           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.

where {n} represents the number of repetitions of an octet πŸ”’

Next up: the least significant (left-most) label is just a single octet of the minimum sort value 🫢

P(\000.foo.example.com.) = foo.example.com.

Same vibe, but now the least significant (right-most) octet of the left-most label is the minimum sort value πŸ’œ

P(foo\000.example.com.) =

           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255.\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255.\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255.\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255.foo.example.com.

or, in alternate notation:

           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.

where {n} represents the number of repetitions of an octet πŸ”’

Now the tricky one πŸ™ˆ this DNS name has an octet that has to be decremented by skipping over the values for US-ASCII uppercase letters, so it's not just a simple step down πŸ’€

P(fo\[.example.com.) =

           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255.\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255.\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255.fo\@\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255.example.com.

or, in alternate notation:

           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.

where {n} represents the number of repetitions of an octet πŸ”’

Last one, and it's a big moment πŸ‘‘ this DNS name is the owner name of the zone apex, so it wraps around to the DNS name with the maximum possible sort order in the zone 😭🌈

P(example.com.) =

           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255.\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255.\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255.\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255\255\255\255\255\255\255\255\255\255\255\255
           \255.example.com.

or, in alternate notation:

           \255{49}.\255{63}.\255{63}.\255{63}.example.com.

where {n} represents the number of repetitions of an octet πŸ”’

5.2. Examples of Immediate Successors Using Absolute Method ✨

Okay, first up is the typical case, which is honestly the easiest one πŸ’–

S(foo.example.com.) = \000.foo.example.com.

Next, a DNS name that is one octet short of the maximum DNS name length πŸŽ€

N =  fooooooooooooooooooooooooooooooooooooooooooooooo
     .ooooooooooooooooooooooooooooooooooooooooooooooo
     oooooooooooooooo.ooooooooooooooooooooooooooooooo
     oooooooooooooooooooooooooooooooo.ooooooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.

Or, in alternate notation:

     fo{47}.o{63}.o{63}.o{63}.example.com.
S(N) =

     fooooooooooooooooooooooooooooooooooooooooooooooo
     \000.ooooooooooooooooooooooooooooooooooooooooooo
     oooooooooooooooooooo.ooooooooooooooooooooooooooo
     oooooooooooooooooooooooooooooooooooo.ooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     oooo.example.com.

Or, in alternate notation:

     fo{47}\000.o{63}.o{63}.o{63}.example.com.

Now the DNS name that is the maximum DNS name length πŸ¦‹

N  = fooooooooooooooooooooooooooooooooooooooooooooooo
     o.oooooooooooooooooooooooooooooooooooooooooooooo
     ooooooooooooooooo.oooooooooooooooooooooooooooooo
     ooooooooooooooooooooooooooooooooo.oooooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     o.example.com.

Or, in alternate notation:

     fo{48}.o{63}.o{63}.o{63}.example.com.
S(N) =

     fooooooooooooooooooooooooooooooooooooooooooooooo
     p.oooooooooooooooooooooooooooooooooooooooooooooo
     ooooooooooooooooo.oooooooooooooooooooooooooooooo
     ooooooooooooooooooooooooooooooooo.oooooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     o.example.com.

Or, in alternate notation:

     fo{47}p.o{63}.o{63}.o{63}.example.com.

Next up is the maximum DNS name length where the least significant (left-most) label has the maximum sort value. This one is giving maximum drama πŸ’…

N =  \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255.ooooooooooooooooooooooooooooooooooooooooooo
     oooooooooooooooooooo.ooooooooooooooooooooooooooo
     oooooooooooooooooooooooooooooooooooo.ooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     oooo.example.com.

Or, in alternate notation:

     \255{49}.o{63}.o{63}.o{63}.example.com.
S(N) =

     oooooooooooooooooooooooooooooooooooooooooooooooo
     oooooooooooooop.oooooooooooooooooooooooooooooooo
     ooooooooooooooooooooooooooooooo.oooooooooooooooo
     ooooooooooooooooooooooooooooooooooooooooooooooo.
     example.com.

Or, in alternate notation:

     o{62}p.o{63}.o{63}.example.com.

Next, the maximum DNS name length where the eight least significant (right-most) octets of the least significant (left-most) label have the maximum sort value. Iconic energy 🌈

N  = foooooooooooooooooooooooooooooooooooooooo\255
     \255\255\255\255\255\255\255.ooooooooooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooo.ooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     oooooooooooo.ooooooooooooooooooooooooooooooooooo
     oooooooooooooooooooooooooooo.example.com.

Or, in alternate notation:

     fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
S(N) =

     fooooooooooooooooooooooooooooooooooooooop.oooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     ooooooooo.oooooooooooooooooooooooooooooooooooooo
     ooooooooooooooooooooooooo.oooooooooooooooooooooo
     ooooooooooooooooooooooooooooooooooooooooo.example.com.

Or, in alternate notation:

     fo{39}p.o{63}.o{63}.o{63}.example.com.

Here's one where the maximum DNS name length is reached and an octet has to be incremented by skipping the values that correspond to US-ASCII uppercase letters. Plot twist, but make it cute πŸ™ˆ

N  = fooooooooooooooooooooooooooooooooooooooooooooooo
     \@.ooooooooooooooooooooooooooooooooooooooooooooo
     oooooooooooooooooo.ooooooooooooooooooooooooooooo
     oooooooooooooooooooooooooooooooooo.ooooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     oo.example.com.

Or, in alternate notation:

     fo{47}\@.o{63}.o{63}.o{63}.example.com.
S(N) =

     fooooooooooooooooooooooooooooooooooooooooooooooo
     \[.ooooooooooooooooooooooooooooooooooooooooooooo
     oooooooooooooooooo.ooooooooooooooooooooooooooooo
     oooooooooooooooooooooooooooooooooo.ooooooooooooo
     oooooooooooooooooooooooooooooooooooooooooooooooo
     oo.example.com.

Or, in alternate notation:

     fo{47}\[.o{63}.o{63}.o{63}.example.com.

And finally, the DNS name that has the maximum possible sort order in the zone, so it wraps around to the owner name of the zone apex. This is the full-circle moment πŸ”„πŸ‘‘

N  = \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255.\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255.\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255.\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255.example.com.

Or, in alternate notation:

     \255{49}.\255{63}.\255{63}.\255{63}.example.com.
S(N) = example.com.

5.3. Examples of Predecessors Using Modified Method 🧚

Here's the typical case for the modified method 🌸

P'(foo.example.com.) =

     fon\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255.example.com.

Or, in alternate notation:

     fon\255{60}.example.com.

Next, a DNS name that contains more labels than the DNS names in the zone do πŸ“

P'(bar.foo.example.com.) = foo.example.com.

Here's the case where the least significant (right-most) octet of the least significant (left-most) label has the minimum sort value πŸ’œ

P'(foo\000.example.com.) = foo.example.com.

And the case where the least significant (left-most) label has the minimum sort value 🫢

P'(\000.example.com.) = example.com.

Last one: the DNS name is the owner name of the zone apex, so it wraps around to the DNS name with the maximum possible sort order in the zone πŸŒ€

P'(example.com.) =

     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255.example.com.

Or, in alternate notation:

     \255{63}.example.com.

5.4. Examples of Successors Using Modified Method πŸ’…

Typical case, bestie πŸ’–

S'(foo.example.com.) = foo\000.example.com.

Here's a DNS name that contains more labels than the DNS names in the zone do ✨

S'(bar.foo.example.com.) = foo\000.example.com.

And the case where the least significant (left-most) label has the maximum sort value, so it wraps around to the owner name of the zone apex. It's giving full circle again πŸ”

N  = \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255.example.com.

Or, in alternate notation:

     \255{63}.example.com.
S'(N) = example.com.

6. Security Considerations πŸ”’

Okay, real talk, this part matters πŸ₯Ί Some predecessors and successors need more conditions tested than others do. That means a denial-of-service attack can get stronger if the attacker sends queries that force more conditions to be tested. The modified method tests fewer conditions than the absolute method does, so it's a little less exposed to this problem.

7. Acknowledgements 🫢

The authors wanna give a big thank you to Sam Weiler, Olaf Kolkman, Olafur Gudmundsson, and Niall O'Reilly for reviewing and giving input πŸ’œ

8. References πŸ“š

8.1. Normative References

  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
  • [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

8.2. Informative References

  • [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, April 2006.
  • [DNSSEC-TRANS] Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC Transition Mechanisms", Work in Progress, February 2005.

Authors' Addresses πŸŽ€

Geoffrey Sisson
Nominet
Sandford Gate
Sandy Lane West
Oxford
OX4 6LB
GB

Phone: +44 1865 332211
EMail: geoff@nominet.org.uk


Ben Laurie
Nominet
17 Perryn Road
London
W3 7LR
GB

Phone: +44 20 8735 0686
EMail: ben@algroup.co.uk

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property πŸ’…

okay so the IETF is not taking a side on whether any patents or other IP rights might apply to the tech in this doc, or how far any license might stretch 🫢 It also isn't claiming it did its own hunt for those rights ✨ If you want the rules on rights in RFC docs, check out BCP 78 and BCP 79 πŸ’–

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be made available, or the result of trying to get a general license or permission for implementers or users to use those proprietary rights can all be found in the IETF online IPR repository at http://www.ietf.org/ipr 🧚

and the IETF invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that may cover tech needed to implement this standard πŸ“¬ send that info to the IETF at ietf-ipr@ietf.org 🌸

Acknowledgement πŸŽ€

funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) πŸ’œ

πŸ“¦ where this page comes from