idnits 2.17.1 draft-ietf-dnsext-dns-name-p-s-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 989. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2005) is 6760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DNS' is mentioned on line 376, but not defined == Unused Reference: 'I-D.ietf-dnsext-dnssec-trans' is defined on line 882, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-dnsext-dnssec-online-signing-01 == Outdated reference: A later version (-06) exists of draft-ietf-dnsext-dnssec-trans-02 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group G. Sisson 3 Internet-Draft B. Laurie 4 Expires: March 5, 2006 Nominet 5 September 2005 7 Derivation of DNS Name Predecessor and Successor 8 draft-ietf-dnsext-dns-name-p-s-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 5, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes two methods for deriving the canonically- 42 ordered predecessor and successor of a DNS name. These methods may 43 be used for dynamic NSEC resource record synthesis, enabling 44 security-aware name servers to provide authenticated denial of 45 existence without disclosing other owner names in a DNSSEC-secured 46 zone. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 52 3. Derivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Absolute Method . . . . . . . . . . . . . . . . . . . . . 4 54 3.1.1. Derivation of DNS Name Predecessor . . . . . . . . . . 4 55 3.1.2. Derivation of DNS Name Successor . . . . . . . . . . . 5 56 3.2. Modified Method . . . . . . . . . . . . . . . . . . . . . 5 57 3.2.1. Derivation of DNS Name Predecessor . . . . . . . . . . 6 58 3.2.2. Derivation of DNS Name Successor . . . . . . . . . . . 6 59 4. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Test for Existence . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Case Considerations . . . . . . . . . . . . . . . . . . . 7 62 4.3. Choice of Range . . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Wild Card Considerations . . . . . . . . . . . . . . . . . 8 64 4.5. Possible Modifications . . . . . . . . . . . . . . . . . . 9 65 4.5.1. Restriction of Effective Maximum DNS Name Length . . . 9 66 4.5.2. Use of Modified Method With Zones Containing 67 SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Examples of Immediate Predecessors Using Absolute 70 Method . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.2. Examples of Immediate Successors Using Absolute Method . . 14 72 5.3. Examples of Predecessors Using Modified Method . . . . . . 20 73 5.4. Examples of Successors Using Modified Method . . . . . . . 21 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 80 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 23 81 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 23 82 A.2. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 24 83 A.3. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 24 84 A.4. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 24 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 86 Intellectual Property and Copyright Statements . . . . . . . . . . 26 88 1. Introduction 90 One of the proposals for avoiding the exposure of zone information 91 during the deployment DNSSEC is dynamic NSEC resource record (RR) 92 synthesis. This technique is described in [I-D.ietf-dnsext-dnssec- 93 trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the 94 generation of NSEC RRs that just span the query name for non-existent 95 owner names. In order to do this, the DNS names which would occur 96 just prior to and just following a given query name must be 97 calculated in real time, as maintaining a list of all possible owner 98 names that might occur in a zone would be impracticable. 100 Section 6.1 of [RFC4034] defines canonical DNS name order. This 101 document does not amend or modify this definition. However, the 102 derivation of immediate predecessor and successor, while trivial, is 103 non-obvious. Accordingly, several methods are described here as an 104 aid to implementors and a reference to other interested parties. 106 This document describes two methods: 108 1. An ``absolute method'', which returns the immediate predecessor 109 or successor of a domain name such that no valid DNS name could 110 exist between that DNS name and the predecessor or successor. 112 2. A ``modified method'', which returns a predecessor and successor 113 which are more economical in size and computation. This method 114 is restricted to use with zones consisting exclusively of owner 115 names that contain no more than one label more than the owner 116 name of the apex, where the longest possible owner name (i.e. one 117 with a maximum length left-most label) would not exceed the 118 maximum DNS name length. This is, however, the type of zone for 119 which the technique of online signing is most likely to be used. 121 2. Notational Conventions 123 The following notational conventions are used in this document for 124 economy of expression: 126 N: An unspecified DNS name. 128 P(N): Immediate predecessor to N (absolute method). 130 S(N): Immediate successor to N (absolute method). 132 P'(N): Predecessor to N (modified method). 134 S'(N): Successor to N (modified method). 136 3. Derivations 138 These derivations assume that all uppercase US-ASCII letters in N 139 have already been replaced by their corresponding lowercase 140 equivalents. Unless otherwise specified, processing stops after the 141 first step in which a condition is met. 143 The derivations make reference to maximum label length and maximum 144 DNS name length; these are defined in Section 3.1 of [RFC1034] to be 145 63 and 255 octets respectively. 147 3.1. Absolute Method 149 3.1.1. Derivation of DNS Name Predecessor 151 To derive P(N): 153 1. If N is the same as the owner name of the zone apex, prepend N 154 repeatedly with labels of the maximum length possible consisting 155 of octets of the maximum sort value (e.g. 0xff) until N is the 156 maximum length possible; otherwise continue to the next step. 158 2. If the least significant (left-most) label of N consists of a 159 single octet of the minimum sort value (e.g. 0x00), remove that 160 label; otherwise continue to the next step. (If this condition 161 is met, P(N) is the owner name of the apex.) 163 3. If the least significant (right-most) octet in the least 164 significant (left-most) label of N is the minimum sort value, 165 remove the least significant octet and continue with step 5. 167 4. Decrement the value of the least significant (right-most) octet 168 of the least significant (left-most) label, skipping any values 169 that correspond to uppercase US-ASCII letters, and then append 170 the least significant (left-most) label with as many octets as 171 possible of the maximum sort value. Continue to the next step. 173 5. Prepend N repeatedly with labels of as long a length as possible 174 consisting of octets of the maximum sort value until N is the 175 maximum length possible. 177 3.1.2. Derivation of DNS Name Successor 179 To derive S(N): 181 1. If N is two or more octets shorter than the maximum DNS name 182 length, prepend N with a label containing a single octet of the 183 minimum sort value (e.g. 0x00); otherwise continue to the next 184 step. 186 2. If N is one octet shorter than the maximum DNS name length and 187 the least significant (left-most) label is one or more octets 188 shorter than the maximum label length, append an octet of the 189 minimum sort value to the least significant label; otherwise 190 continue to the next step. 192 3. Increment the value of the least significant (right-most) octet 193 in the least significant (left-most) label that is less than the 194 maximum sort value (e.g. 0xff), skipping any values that 195 correspond to uppercase US-ASCII letters, and then remove any 196 octets to the right of that one. If all octets in the label are 197 the maximum sort value, then continue to the next step. 199 4. Remove the least significant (left-most) label. Unless N is the 200 same as the owner name of the zone apex (this will occur only if 201 N is the maximum possible name in canonical DNS name order, and 202 thus has wrapped to the owner name of zone apex), repeat starting 203 at step 2. 205 3.2. Modified Method 207 This method is for use with zones consisting only of single-label 208 owner names where an owner name consisting of label of maximum length 209 would not result in a DNS name which exceeded the maximum DNS name 210 length. This method is computationally simpler and returns values 211 which are more economical in size than the absolute method. It 212 differs from the absolute method detailed above in the following 213 ways: 215 1. Step 1 of the derivation P(N) has been omitted as the existence 216 of the owner name of the zone apex never requires denial. 218 2. A new step 1 has been introduced which removes unnecessary 219 labels. 221 3. Step 4 of the derivation P(N) has been omitted as it is only 222 necessary for zones containing owner names consisting of more 223 than one label. This omission generally results in a significant 224 reduction of the length of derived predecessors. 226 4. Step 1 of the derivation S(N) had been omitted as it is only 227 necessary for zones containing owner names consisting of more 228 than one label. This omission results in a tiny reduction of the 229 length of derived successors, and maintains consistency with the 230 modification of step 4 of the derivation P(N) described above. 232 5. Steps 2 and 4 of the derivation S(N) have been modified to 233 eliminate checks for maximum DNS name length, as it is an 234 assumption of this method that no DNS name in the zone can exceed 235 the maximum DNS name length. 237 3.2.1. Derivation of DNS Name Predecessor 239 To derive P'(N): 241 1. If N has more labels than the number of labels in the owner name 242 of the apex + 1, repeatedly remove the least significant (left- 243 most) label until N has no more labels than the number of labels 244 in the owner name of the apex + 1; otherwise continue to next 245 step. 247 2. If the least significant (left-most) label of N consists of a 248 single octet of the minimum sort value (e.g. 0x00), remove that 249 label; otherwise continue to the next step. (If this condition 250 is met, P'(N) is the owner name of the apex.) 252 3. If the least significant (right-most) octet in the least 253 significant (left-most) label of N is the minimum sort value, 254 remove the least significant octet. 256 4. Decrement the value of the least significant (right-most) octet, 257 skipping any values which correspond to uppercase US-ASCII 258 letters, and then append the label with as many octets as 259 possible of the maximum sort value. 261 3.2.2. Derivation of DNS Name Successor 263 To derive S'(N): 265 1. If N has more labels than the number of labels in the owner name 266 of the apex + 1, repeatedly remove the least significant (left- 267 most) label until N has no more labels than the number of labels 268 in the owner name of the apex + 1. Continue to next step. 270 2. If the least significant (left-most) label of N is one or more 271 octets shorter than the maximum label length, append an octet of 272 the minimum sort value to the least significant label; otherwise 273 continue to the next step. 275 3. Increment the value of the least significant (right-most) octet 276 in the least significant (left-most) label that is less than the 277 maximum sort value (e.g. 0xff), skipping any values which 278 correspond to uppercase US-ASCII letters, and then remove any 279 octets to the right of that one. If all octets in the label are 280 the maximum sort value, then continue to the next step. 282 4. Remove the least significant (left-most) label. (This will occur 283 only if the least significant label is the maximum label length 284 and consists entirely of octets of the maximum sort value, and 285 thus has wrapped to the owner name of the zone apex.) 287 4. Notes 289 4.1. Test for Existence 291 Before using the result of P(N) or P'(N) as the owner name of an NSEC 292 RR in a DNS response, a name server should test to see whether the 293 name exists. If it does, either a standard non-synthesised NSEC RR 294 should be used, or the synthesised NSEC RR should reflect the RRset 295 types that exist at the NSEC RR's owner name in the Type Bit Map 296 field as specified by Section 4.1.2 of [RFC4034]. Implementors will 297 likely find it simpler to use a non-synthesised NSEC RR. For further 298 details see Section 2 of [I-D.ietf-dnsext-dnssec-online-signing]. 300 4.2. Case Considerations 302 Section 3.5 of [RFC1034] specifies that "while upper and lower case 303 letters are allowed in [DNS] names, no significance is attached to 304 the case". Additionally, Section 6.1 of [RFC4034] states that when 305 determining canonical DNS name order, "uppercase US-ASCII letters are 306 treated as if they were lowercase US-ASCII letters". Consequently, 307 values corresponding to US-ASCII uppercase letters must be skipped 308 when decrementing and incrementing octets in the derivations 309 described in Section 3. 311 The following pseudo-code is illustrative: 313 Decrement the value of an octet: 315 if (octet == '[') // '[' is just after uppercase 'Z' 316 octet = '@'; // '@' is just prior to uppercase 'A' 317 else 318 octet--; 320 Increment the value of an octet: 322 if (octet == '@') // '@' is just prior to uppercase 'A' 323 octet = '['; // '[' is just after uppercase 'Z' 324 else 325 octet++; 327 4.3. Choice of Range 329 [RFC2181] makes the clarification that "any binary string whatever 330 can be used as the label of any resource record". Consequently the 331 minimum sort value may be set as 0x00 and the maximum sort value as 332 0xff, and the range of possible values will be any DNS name which 333 contains octets of any value other than those corresponding to 334 uppercase US-ASCII letters. 336 However, if all owner names in a zone are in the letter-digit-hyphen, 337 or LDH, format specified in [RFC1034], it may be desirable to 338 restrict the range of possible values to DNS names containing only 339 LDH values. This has the effect of: 341 1. making the output of tools such as `dig' and `nslookup' less 342 subject to confusion; 344 2. minimising the impact that NSEC RRs containing DNS names with 345 non-LDH values (or non-printable values) might have on faulty DNS 346 resolver implementations; and 348 3. preventing the possibility of results which are wildcard DNS 349 names (see Section 4.4). 351 This may be accomplished by using a minimum sort value of 0x1f (US- 352 ASCII character `-') and a maximum sort value of 0x7a (US-ASCII 353 character lowercase `z'), and then skipping non-LDH, non-lowercase 354 values when incrementing or decrementing octets. 356 4.4. Wild Card Considerations 358 Neither derivation avoids the possibility that the result may be a 359 DNS name containing a wildcard label, i.e. a label containing a 360 single octet with the value 0x2a (US-ASCII character `*'). With 361 additional tests, wildcard DNS names may be explicitly avoided; 362 alternatively, if the range of octet values can be restricted to 363 those corresponding to letter-digit-hyphen, or LDH, characters (see 364 Section 4.3), such DNS names will not occur. 366 Note that it is improbable that a result which is a wildcard DNS name 367 will occur unintentionally; even if one does occur either as the 368 owner name of, or in the RDATA of an NSEC RR, it is treated as a 369 literal DNS name with no special meaning. 371 4.5. Possible Modifications 373 4.5.1. Restriction of Effective Maximum DNS Name Length 375 [RFC1034] specifies that "the total number of octets that represent a 376 [DNS] name (i.e., the sum of all label octets and label lengths) is 377 limited to 255", including the null (zero-length) label which 378 represents the root. For the purpose of deriving predecessors and 379 successors during NSEC RR synthesis, the maximum DNS name length may 380 be effectively restricted to the length of the longest DNS name in 381 the zone. This will minimise the size of responses containing 382 synthesised NSEC RRs but, especially in the case of the modified 383 method, may result in some additional computational complexity. 385 Note that this modification will have the effect of revealing 386 information about the longest name in the zone. Moreover, when the 387 contents of the zone changes, e.g. during dynamic updates and zone 388 transfers, care must be taken to ensure that the effective maximum 389 DNS name length agrees with the new contents. 391 4.5.2. Use of Modified Method With Zones Containing SRV RRs 393 Normally the modified method cannot be used in zones that contain 394 SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple 395 labels. However the use of SRV RRs can be accommodated by various 396 techniques. There are at least four possible ways to do this: 398 1. Use conventional NSEC RRs for the region of the zone that 399 contains first-level labels beginning with the underscore (`_') 400 character. For the purposes of generating these NSEC RRs, the 401 existence of (possibly fictional) ownernames `9{63}' and `a' 402 could be assumed, providing a lower and upper bound for this 403 region. Then all queries where the QNAME doesn't exist but 404 contains a first-level label beginning with an underscore could 405 be handled using the normal DNSSEC protocol. 407 This approach would make it possible to enumerate all DNS names 408 in the zone containing a first-level label beginning with 409 underscore, including all SRV RRs, but this may be of less a 410 concern to the zone administrator than incurring the overhead of 411 the absolute method or of the following variants of the modified 412 method. 414 2. The absolute method could be used for synthesising NSEC RRs for 415 all queries where the QNAME contains a leading underscore. 417 However this re-introduces the susceptibility of the absolute 418 method to denial of service activity, as an attacker could send 419 queries for an effectively inexhaustible supply of domain names 420 beginning with a leading underscore. 422 3. A variant of the modified method could be used for synthesising 423 NSEC RRs for all queries where the QNAME contains a leading 424 underscore. This variant would assume that all predecessors and 425 successors to queries where the QNAME contains a leading 426 underscore may consist of two labels rather than only one. This 427 introduces a little additional complexity without incurring the 428 full increase in response size and computational complexity as 429 the absolute method. 431 4. Finally, a variant the modified method which assumes that all 432 owner names in the zone consist of one or two labels could be 433 used. However this negates much of the reduction in response 434 size of the modified method and may be nearly as computationally 435 complex as the absolute method. 437 5. Examples 439 In the following examples: 441 the owner name of the zone apex is "example.com."; 443 the range of octet values is 0x00 - 0xff excluding values 444 corresponding to uppercase US-ASCII letters; and 446 non-printable octet values are expressed as three-digit decimal 447 numbers preceded by a backslash (as specified in Section 5.1 of 448 [RFC1035]). 450 5.1. Examples of Immediate Predecessors Using Absolute Method 452 Example of typical case: 454 P(foo.example.com.) = 456 \255\255\255\255\255\255\255\255\255\255\255\255 457 \255\255\255\255\255\255\255\255\255\255\255\255 458 \255\255\255\255\255\255\255\255\255\255\255\255 459 \255\255\255\255\255\255\255\255\255\255\255\255 460 \255.\255\255\255\255\255\255\255\255\255\255 461 \255\255\255\255\255\255\255\255\255\255\255\255 462 \255\255\255\255\255\255\255\255\255\255\255\255 463 \255\255\255\255\255\255\255\255\255\255\255\255 464 \255\255\255\255\255\255\255\255\255\255\255\255 465 \255\255\255\255\255.\255\255\255\255\255\255 466 \255\255\255\255\255\255\255\255\255\255\255\255 467 \255\255\255\255\255\255\255\255\255\255\255\255 468 \255\255\255\255\255\255\255\255\255\255\255\255 469 \255\255\255\255\255\255\255\255\255\255\255\255 470 \255\255\255\255\255\255\255\255\255.fon\255\255 471 \255\255\255\255\255\255\255\255\255\255\255\255 472 \255\255\255\255\255\255\255\255\255\255\255\255 473 \255\255\255\255\255\255\255\255\255\255\255\255 474 \255\255\255\255\255\255\255\255\255\255\255\255 475 \255\255\255\255\255\255\255\255\255\255.example.com. 477 or, in alternate notation: 479 \255{49}.\255{63}.\255{63}.fon\255{60}.example.com. 481 where {n} represents the number of repetitions of an octet. 483 Example where least significant (left-most) label of DNS name 484 consists of a single octet of the minimum sort value: 486 P(\000.foo.example.com.) = foo.example.com. 488 Example where least significant (right-most) octet of least 489 significant (left-most) label has the minimum sort value: 491 P(foo\000.example.com.) = 493 \255\255\255\255\255\255\255\255\255\255\255\255 494 \255\255\255\255\255\255\255\255\255\255\255\255 495 \255\255\255\255\255\255\255\255\255\255\255\255 496 \255\255\255\255\255\255\255\255\255.\255\255 497 \255\255\255\255\255\255\255\255\255\255\255\255 498 \255\255\255\255\255\255\255\255\255\255\255\255 499 \255\255\255\255\255\255\255\255\255\255\255\255 500 \255\255\255\255\255\255\255\255\255\255\255\255 501 \255\255\255\255\255\255\255\255\255\255\255\255 502 \255.\255\255\255\255\255\255\255\255\255\255 503 \255\255\255\255\255\255\255\255\255\255\255\255 504 \255\255\255\255\255\255\255\255\255\255\255\255 505 \255\255\255\255\255\255\255\255\255\255\255\255 506 \255\255\255\255\255\255\255\255\255\255\255\255 507 \255\255\255\255\255.\255\255\255\255\255\255 508 \255\255\255\255\255\255\255\255\255\255\255\255 509 \255\255\255\255\255\255\255\255\255\255\255\255 510 \255\255\255\255\255\255\255\255\255\255\255\255 511 \255\255\255\255\255\255\255\255\255\255\255\255 512 \255\255\255\255\255\255\255\255\255.foo.example.com. 514 or, in alternate notation: 516 \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com. 518 Example where DNS name contains an octet which must be decremented by 519 skipping values corresponding to US-ASCII uppercase letters: 521 P(fo\[.example.com.) = 523 \255\255\255\255\255\255\255\255\255\255\255\255 524 \255\255\255\255\255\255\255\255\255\255\255\255 525 \255\255\255\255\255\255\255\255\255\255\255\255 526 \255\255\255\255\255\255\255\255\255\255\255\255 527 \255.\255\255\255\255\255\255\255\255\255\255 528 \255\255\255\255\255\255\255\255\255\255\255\255 529 \255\255\255\255\255\255\255\255\255\255\255\255 530 \255\255\255\255\255\255\255\255\255\255\255\255 531 \255\255\255\255\255\255\255\255\255\255\255\255 532 \255\255\255\255\255.\255\255\255\255\255\255 533 \255\255\255\255\255\255\255\255\255\255\255\255 534 \255\255\255\255\255\255\255\255\255\255\255\255 535 \255\255\255\255\255\255\255\255\255\255\255\255 536 \255\255\255\255\255\255\255\255\255\255\255\255 537 \255\255\255\255\255\255\255\255\255.fo\@\255 538 \255\255\255\255\255\255\255\255\255\255\255\255 539 \255\255\255\255\255\255\255\255\255\255\255\255 540 \255\255\255\255\255\255\255\255\255\255\255\255 541 \255\255\255\255\255\255\255\255\255\255\255\255 542 \255\255\255\255\255\255\255\255\255\255\255.example.com. 544 or, in alternate notation: 546 \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com. 548 where {n} represents the number of repetitions of an octet. 550 Example where DNS name is the owner name of the zone apex, and 551 consequently wraps to the DNS name with the maximum possible sort 552 order in the zone: 554 P(example.com.) = 556 \255\255\255\255\255\255\255\255\255\255\255\255 557 \255\255\255\255\255\255\255\255\255\255\255\255 558 \255\255\255\255\255\255\255\255\255\255\255\255 559 \255\255\255\255\255\255\255\255\255\255\255\255 560 \255.\255\255\255\255\255\255\255\255\255\255 561 \255\255\255\255\255\255\255\255\255\255\255\255 562 \255\255\255\255\255\255\255\255\255\255\255\255 563 \255\255\255\255\255\255\255\255\255\255\255\255 564 \255\255\255\255\255\255\255\255\255\255\255\255 565 \255\255\255\255\255.\255\255\255\255\255\255 566 \255\255\255\255\255\255\255\255\255\255\255\255 567 \255\255\255\255\255\255\255\255\255\255\255\255 568 \255\255\255\255\255\255\255\255\255\255\255\255 569 \255\255\255\255\255\255\255\255\255\255\255\255 570 \255\255\255\255\255\255\255\255\255.\255\255 571 \255\255\255\255\255\255\255\255\255\255\255\255 572 \255\255\255\255\255\255\255\255\255\255\255\255 573 \255\255\255\255\255\255\255\255\255\255\255\255 574 \255\255\255\255\255\255\255\255\255\255\255\255 575 \255\255\255\255\255\255\255\255\255\255\255\255 576 \255.example.com. 578 or, in alternate notation: 580 \255{49}.\255{63}.\255{63}.\255{63}.example.com. 582 5.2. Examples of Immediate Successors Using Absolute Method 584 Example of typical case: 586 S(foo.example.com.) = \000.foo.example.com. 588 Example where DNS name is one octet short of the maximum DNS name 589 length: 591 N = fooooooooooooooooooooooooooooooooooooooooooooooo 592 .ooooooooooooooooooooooooooooooooooooooooooooooo 593 oooooooooooooooo.ooooooooooooooooooooooooooooooo 594 oooooooooooooooooooooooooooooooo.ooooooooooooooo 595 oooooooooooooooooooooooooooooooooooooooooooooooo.example.com. 597 or, in alternate notation: 599 fo{47}.o{63}.o{63}.o{63}.example.com. 601 S(N) = 603 fooooooooooooooooooooooooooooooooooooooooooooooo 604 \000.ooooooooooooooooooooooooooooooooooooooooooo 605 oooooooooooooooooooo.ooooooooooooooooooooooooooo 606 oooooooooooooooooooooooooooooooooooo.ooooooooooo 607 oooooooooooooooooooooooooooooooooooooooooooooooo 608 oooo.example.com. 610 or, in alternate notation: 612 fo{47}\000.o{63}.o{63}.o{63}.example.com. 614 Example where DNS name is the maximum DNS name length: 616 N = fooooooooooooooooooooooooooooooooooooooooooooooo 617 o.oooooooooooooooooooooooooooooooooooooooooooooo 618 ooooooooooooooooo.oooooooooooooooooooooooooooooo 619 ooooooooooooooooooooooooooooooooo.oooooooooooooo 620 oooooooooooooooooooooooooooooooooooooooooooooooo 621 o.example.com. 623 or, in alternate notation: 625 fo{48}.o{63}.o{63}.o{63}.example.com. 627 S(N) = 629 fooooooooooooooooooooooooooooooooooooooooooooooo 630 p.oooooooooooooooooooooooooooooooooooooooooooooo 631 ooooooooooooooooo.oooooooooooooooooooooooooooooo 632 ooooooooooooooooooooooooooooooooo.oooooooooooooo 633 oooooooooooooooooooooooooooooooooooooooooooooooo 634 o.example.com. 636 or, in alternate notation: 638 fo{47}p.o{63}.o{63}.o{63}.example.com. 640 Example where DNS name is the maximum DNS name length and the least 641 significant (left-most) label has the maximum sort value: 643 N = \255\255\255\255\255\255\255\255\255\255\255\255 644 \255\255\255\255\255\255\255\255\255\255\255\255 645 \255\255\255\255\255\255\255\255\255\255\255\255 646 \255\255\255\255\255\255\255\255\255\255\255\255 647 \255.ooooooooooooooooooooooooooooooooooooooooooo 648 oooooooooooooooooooo.ooooooooooooooooooooooooooo 649 oooooooooooooooooooooooooooooooooooo.ooooooooooo 650 oooooooooooooooooooooooooooooooooooooooooooooooo 651 oooo.example.com. 653 or, in alternate notation: 655 \255{49}.o{63}.o{63}.o{63}.example.com. 657 S(N) = 659 oooooooooooooooooooooooooooooooooooooooooooooooo 660 oooooooooooooop.oooooooooooooooooooooooooooooooo 661 ooooooooooooooooooooooooooooooo.oooooooooooooooo 662 ooooooooooooooooooooooooooooooooooooooooooooooo. 663 example.com. 665 or, in alternate notation: 667 o{62}p.o{63}.o{63}.example.com. 669 Example where DNS name is the maximum DNS name length and the eight 670 least significant (right-most) octets of the least significant (left- 671 most) label have the maximum sort value: 673 N = foooooooooooooooooooooooooooooooooooooooo\255 674 \255\255\255\255\255\255\255.ooooooooooooooooooo 675 oooooooooooooooooooooooooooooooooooooooooooo.ooo 676 oooooooooooooooooooooooooooooooooooooooooooooooo 677 oooooooooooo.ooooooooooooooooooooooooooooooooooo 678 oooooooooooooooooooooooooooo.example.com. 680 or, in alternate notation: 682 fo{40}\255{8}.o{63}.o{63}.o{63}.example.com. 684 S(N) = 686 fooooooooooooooooooooooooooooooooooooooop.oooooo 687 oooooooooooooooooooooooooooooooooooooooooooooooo 688 ooooooooo.oooooooooooooooooooooooooooooooooooooo 689 ooooooooooooooooooooooooo.oooooooooooooooooooooo 690 ooooooooooooooooooooooooooooooooooooooooo.example.com. 692 or, in alternate notation: 694 fo{39}p.o{63}.o{63}.o{63}.example.com. 696 Example where DNS name is the maximum DNS name length and contains an 697 octet which must be incremented by skipping values corresponding to 698 US-ASCII uppercase letters: 700 N = fooooooooooooooooooooooooooooooooooooooooooooooo 701 \@.ooooooooooooooooooooooooooooooooooooooooooooo 702 oooooooooooooooooo.ooooooooooooooooooooooooooooo 703 oooooooooooooooooooooooooooooooooo.ooooooooooooo 704 oooooooooooooooooooooooooooooooooooooooooooooooo 705 oo.example.com. 707 or, in alternate notation: 709 fo{47}\@.o{63}.o{63}.o{63}.example.com. 711 S(N) = 713 fooooooooooooooooooooooooooooooooooooooooooooooo 714 \[.ooooooooooooooooooooooooooooooooooooooooooooo 715 oooooooooooooooooo.ooooooooooooooooooooooooooooo 716 oooooooooooooooooooooooooooooooooo.ooooooooooooo 717 oooooooooooooooooooooooooooooooooooooooooooooooo 718 oo.example.com. 720 or, in alternate notation: 722 fo{47}\[.o{63}.o{63}.o{63}.example.com. 724 Example where DNS name has the maximum possible sort order in the 725 zone, and consequently wraps to the owner name of the zone apex: 727 N = \255\255\255\255\255\255\255\255\255\255\255\255 728 \255\255\255\255\255\255\255\255\255\255\255\255 729 \255\255\255\255\255\255\255\255\255\255\255\255 730 \255\255\255\255\255\255\255\255\255\255\255\255 731 \255.\255\255\255\255\255\255\255\255\255\255 732 \255\255\255\255\255\255\255\255\255\255\255\255 733 \255\255\255\255\255\255\255\255\255\255\255\255 734 \255\255\255\255\255\255\255\255\255\255\255\255 735 \255\255\255\255\255\255\255\255\255\255\255\255 736 \255\255\255\255\255.\255\255\255\255\255\255 737 \255\255\255\255\255\255\255\255\255\255\255\255 738 \255\255\255\255\255\255\255\255\255\255\255\255 739 \255\255\255\255\255\255\255\255\255\255\255\255 740 \255\255\255\255\255\255\255\255\255\255\255\255 741 \255\255\255\255\255\255\255\255\255.\255\255 742 \255\255\255\255\255\255\255\255\255\255\255\255 743 \255\255\255\255\255\255\255\255\255\255\255\255 744 \255\255\255\255\255\255\255\255\255\255\255\255 745 \255\255\255\255\255\255\255\255\255\255\255\255 746 \255\255\255\255\255\255\255\255\255\255\255\255 747 \255.example.com. 749 or, in alternate notation: 751 \255{49}.\255{63}.\255{63}.\255{63}.example.com. 753 S(N) = example.com. 755 5.3. Examples of Predecessors Using Modified Method 757 Example of typical case: 759 P'(foo.example.com.) = 761 fon\255\255\255\255\255\255\255\255\255\255\255 762 \255\255\255\255\255\255\255\255\255\255\255\255 763 \255\255\255\255\255\255\255\255\255\255\255\255 764 \255\255\255\255\255\255\255\255\255\255\255\255 765 \255\255\255\255\255\255\255\255\255\255\255\255 766 \255.example.com. 768 or, in alternate notation: 770 fon\255{60}.example.com. 772 Example where DNS name contains more labels than DNS names in the 773 zone: 775 P'(bar.foo.example.com.) = foo.example.com. 777 Example where least significant (right-most) octet of least 778 significant (left-most) label has the minimum sort value: 780 P'(foo\000.example.com.) = foo.example.com. 782 Example where least significant (left-most) label has the minimum 783 sort value: 785 P'(\000.example.com.) = example.com. 787 Example where DNS name is the owner name of the zone apex, and 788 consequently wraps to the DNS name with the maximum possible sort 789 order in the zone: 791 P'(example.com.) = 793 \255\255\255\255\255\255\255\255\255\255\255\255 794 \255\255\255\255\255\255\255\255\255\255\255\255 795 \255\255\255\255\255\255\255\255\255\255\255\255 796 \255\255\255\255\255\255\255\255\255\255\255\255 797 \255\255\255\255\255\255\255\255\255\255\255\255 798 \255\255\255.example.com. 800 or, in alternate notation: 802 \255{63}.example.com. 804 5.4. Examples of Successors Using Modified Method 806 Example of typical case: 808 S'(foo.example.com.) = foo\000.example.com. 810 Example where DNS name contains more labels than DNS names in the 811 zone: 813 S'(bar.foo.example.com.) = foo\000.example.com. 815 Example where least significant (left-most) label has the maximum 816 sort value, and consequently wraps to the owner name of the zone 817 apex: 819 N = \255\255\255\255\255\255\255\255\255\255\255\255 820 \255\255\255\255\255\255\255\255\255\255\255\255 821 \255\255\255\255\255\255\255\255\255\255\255\255 822 \255\255\255\255\255\255\255\255\255\255\255\255 823 \255\255\255\255\255\255\255\255\255\255\255\255 824 \255\255\255.example.com. 826 or, in alternate notation: 828 \255{63}.example.com. 830 S'(N) = example.com. 832 6. Security Considerations 834 The derivation of some predecessors/successors requires the testing 835 of more conditions than others. Consequently the effectiveness of a 836 denial-of-service attack may be enhanced by sending queries that 837 require more conditions to be tested. The modified method involves 838 the testing of fewer conditions than the absolute method and 839 consequently is somewhat less susceptible to this exposure. 841 7. IANA Considerations 843 This document has no IANA actions. 845 Note to RFC Editor: This section is included to make it clear during 846 pre-publication review that this document has no IANA actions. It 847 may therefore be removed should it be published as an RFC. 849 8. Acknowledgments 851 The authors would like to thank Sam Weiler, Olaf Kolkman, Olafur 852 Gudmundsson and Niall O'Reilly for their review and input. 854 9. References 855 9.1. Normative References 857 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 858 STD 13, RFC 1034, November 1987. 860 [RFC1035] Mockapetris, P., "Domain names - implementation and 861 specification", STD 13, RFC 1035, November 1987. 863 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 864 Specification", RFC 2181, July 1997. 866 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 867 specifying the location of services (DNS SRV)", RFC 2782, 868 February 2000. 870 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 871 Rose, "Resource Records for the DNS Security Extensions", 872 RFC 4034, March 2005. 874 9.2. Informative References 876 [I-D.ietf-dnsext-dnssec-online-signing] 877 Ihren, J. and S. Weiler, "Minimally Covering NSEC Records 878 and DNSSEC On-line Signing", 879 draft-ietf-dnsext-dnssec-online-signing-01 (work in 880 progress), May 2005. 882 [I-D.ietf-dnsext-dnssec-trans] 883 Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC 884 Transition Mechanisms", 885 draft-ietf-dnsext-dnssec-trans-02 (work in progress), 886 February 2005. 888 Appendix A. Change History 890 A.1. Changes from -00 to -01 892 o Added note advising testing for the pre-existence of owner names 893 prior to using synthesised NSEC RRs. 895 o Added explicit reference to [RFC1034] maximum label and DNS name 896 lengths. 898 o Made minor clarifications to derivations. 900 o Reorganised derivations section for clarity. 902 A.2. Changes from sisson-02 to ietf-00 904 o Added notes on use of SRV RRs with modified method. 906 o Changed reference from weiler-dnssec-online-signing to ietf- 907 dnsext-dnssec-online-signing. 909 o Changed reference from ietf-dnsext-dnssec-records to [RFC4034]. 911 o Miscellaneous minor changes to text. 913 A.3. Changes from sisson-01 to sisson-02 915 o Added modified version of derivation (with supporting examples). 917 o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N). 919 o Added clarification to derivations about when processing stops. 921 o Miscellaneous minor changes to text. 923 A.4. Changes from sisson-00 to sisson-01 925 o Split step 3 of derivation of DNS name predecessor into two 926 distinct steps for clarity. 928 o Added clarifying text and examples related to the requirement to 929 avoid uppercase characters when decrementing or incrementing 930 octets. 932 o Added optimisation using restriction of effective maximum DNS name 933 length. 935 o Changed examples to use decimal rather than octal notation as per 936 [RFC1035]. 938 o Corrected DNS name length of some examples. 940 o Added reference to weiler-dnssec-online-signing. 942 o Miscellaneous minor changes to text. 944 Authors' Addresses 946 Geoffrey Sisson 947 Nominet 948 Sandford Gate 949 Sandy Lane West 950 Oxford 951 OX4 6LB 952 GB 954 Phone: +44 1865 332339 955 Email: geoff@nominet.org.uk 957 Ben Laurie 958 Nominet 959 17 Perryn Road 960 London 961 W3 7LR 962 GB 964 Phone: +44 20 8735 0686 965 Email: ben@algroup.co.uk 967 Intellectual Property Statement 969 The IETF takes no position regarding the validity or scope of any 970 Intellectual Property Rights or other rights that might be claimed to 971 pertain to the implementation or use of the technology described in 972 this document or the extent to which any license under such rights 973 might or might not be available; nor does it represent that it has 974 made any independent effort to identify any such rights. Information 975 on the procedures with respect to rights in RFC documents can be 976 found in BCP 78 and BCP 79. 978 Copies of IPR disclosures made to the IETF Secretariat and any 979 assurances of licenses to be made available, or the result of an 980 attempt made to obtain a general license or permission for the use of 981 such proprietary rights by implementers or users of this 982 specification can be obtained from the IETF on-line IPR repository at 983 http://www.ietf.org/ipr. 985 The IETF invites any interested party to bring to its attention any 986 copyrights, patents or patent applications, or other proprietary 987 rights that may cover technology that may be required to implement 988 this standard. Please address the information to the IETF at 989 ietf-ipr@ietf.org. 991 Disclaimer of Validity 993 This document and the information contained herein are provided on an 994 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 995 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 996 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 997 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 998 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 999 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1001 Copyright Statement 1003 Copyright (C) The Internet Society (2005). This document is subject 1004 to the rights, licenses and restrictions contained in BCP 78, and 1005 except as set forth therein, the authors retain all their rights. 1007 Acknowledgment 1009 Funding for the RFC Editor function is currently provided by the 1010 Internet Society.