idnits 2.17.1 draft-koch-dns-glue-clarifications-03.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 547. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 19, 2007) is 6004 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) == Unused Reference: 'I-D.ietf-dnsext-axfr-clarify' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dnsop-respsize' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC1207' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC1386' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC1537' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'RFC1637' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC2065' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC2672' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC2845' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC2931' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC3363' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC3364' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC3375' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC3658' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC3731' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC3732' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC3845' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC4183' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC4697' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC4871' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC4931' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC4932' is defined on line 471, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-dnsext-axfr-clarify-05 == Outdated reference: A later version (-15) exists of draft-ietf-dnsop-respsize-07 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-respsize (ref. 'I-D.ietf-dnsop-respsize') -- Possible downref: Normative reference to a draft: ref. 'I-D.minda-dnsop-using-in-bailiwick-nameservers' ** Obsolete normative reference: RFC 973 (Obsoleted by RFC 1034, RFC 1035) ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Downref: Normative reference to an Informational RFC: RFC 1207 ** Obsolete normative reference: RFC 1386 (Obsoleted by RFC 1480) ** Obsolete normative reference: RFC 1537 (Obsoleted by RFC 1912) ** Obsolete normative reference: RFC 1637 (Obsoleted by RFC 1706) ** Downref: Normative reference to an Informational RFC: RFC 1713 ** Downref: Normative reference to an Informational RFC: RFC 1912 ** Obsolete normative reference: RFC 2010 (Obsoleted by RFC 2870) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Historic RFC: RFC 2874 ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Downref: Normative reference to an Informational RFC: RFC 3363 ** Downref: Normative reference to an Informational RFC: RFC 3364 ** Downref: Normative reference to an Informational RFC: RFC 3375 ** Obsolete normative reference: RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3731 (Obsoleted by RFC 4931) ** Obsolete normative reference: RFC 3732 (Obsoleted by RFC 4932) ** Downref: Normative reference to an Informational RFC: RFC 3833 ** Obsolete normative reference: RFC 3845 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Downref: Normative reference to an Informational RFC: RFC 4183 ** Downref: Normative reference to an Informational RFC: RFC 4472 ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 4931 (Obsoleted by RFC 5731) ** Obsolete normative reference: RFC 4932 (Obsoleted by RFC 5732) Summary: 31 errors (**), 0 flaws (~~), 32 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Koch 3 Internet-Draft DENIC eG 4 Expires: May 22, 2008 November 19, 2007 6 DNS Glue RR Survey and Terminology Clarification 7 draft-koch-dns-glue-clarifications-03 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 22, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document presents a survey of the use of the term "glue record" 41 in DNS related RFCs and proposes a terminology for the various glue 42 policies seen in different TLDs. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 47 2. RFC Survey . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . 3 49 4. Name Server Naming Strategies . . . . . . . . . . . . 4 50 5. Glue Policies . . . . . . . . . . . . . . . . . . . . 4 51 6. Open Issues . . . . . . . . . . . . . . . . . . . . . 5 52 6.1. Root Server "Glue" in the Root Zone File . . . . . . . 6 53 6.2. Using Glue records in responses . . . . . . . . . . . 6 54 6.3. Glue RRs for multihomed name servers . . . . . . . . . 7 55 6.4. Grandchild Glue . . . . . . . . . . . . . . . . . . . 7 56 7. DNSSEC Considerations . . . . . . . . . . . . . . . . 8 57 8. IPv6 Considerations . . . . . . . . . . . . . . . . . 8 58 9. Security Considerations . . . . . . . . . . . . . . . 8 59 10. IANA Considerations . . . . . . . . . . . . . . . . . 8 60 11. References . . . . . . . . . . . . . . . . . . . . . . 8 61 Appendix A. Document Revision History . . . . . . . . . . . . . . 11 62 A.1. Changes from -02 to -03 . . . . . . . . . . . . . . . 11 63 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 11 64 A.3. Changes from -00 to -01 . . . . . . . . . . . . . . . 12 65 Author's Address . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . 13 68 1. Introduction 70 When delegating zones from a TLD or other DNS zone, some additional 71 information is needed when resolving a name server's (as per an NS 72 RR) address would involve the particular name server itself. Such a 73 dependency on itself, direct or indirect, may effectively shadow a 74 part of a zone's NS RRSet, reducing redundancy, or even render the 75 zone completely unresolvable. This additional information is an 76 amendment to the delegation in the form of glue address records. In 77 the real life DNS multiple strategies to determine necessity or 78 acceptance of glue records co-exist. This document lists a subset of 79 those approaches. 81 This document also tries to clarify when and where to call an address 82 record "glue record". 84 Comments should be directed at the author. 86 Domain names and IP addresses herein are for explanatory purposes 87 only and should not be expected to lead to useful information in real 88 life [RFC2606],[RFC3330]). 90 2. RFC Survey 92 To find out more about early motivations and strategies for DNS glue 93 records, all existing RFCs were automatically searched for the term 94 "glue" (case insensitive, no word boundaries) and those matching were 95 inspected on a case by case basis. Whenever the term was used in a 96 DNS context, the RFC was added to the list which can be found in the 97 References section. It turned out that, while all early RFCs are 98 consistent in using "glue" only for type A address records for NS RR 99 targets, they apply slightly different logic as to when a glue A RR 100 should be present. 102 3. Terms 104 When the term "glue record" was introduced in [RFC0973], it was meant 105 to denominate both data origin and purpose. Data origin is related 106 to the zone, although the glue records do not belong to the 107 authoritative zone data. The purpose is constrained to providing 108 address information for name servers mentioned in NS RRs, which would 109 otherwise not be resolvable. Glue records are address information 110 accompanying a delegation (in the delegating zone). 112 There is sometimes confusion when data in a DNS response is also 113 called "glue" data, e.g. [RFC2010] starts speaking of "fetching" 114 glue. In a DNS response packet (answer or referral) the address 115 information for name servers is carried in the additional section. 116 This address information might have originated from glue records but 117 might also come from cached or authoritative data. DNS data in 118 response packets should only be called "glue data" when it is certain 119 and needs to be emphasized that it originates from glue records. 121 [RFC4472] introduces the concept of 'critical' and 'courtesy' 122 additional data. 124 4. Name Server Naming Strategies 126 The DNS refers to name servers by their name in NS resource records. 127 The servers' names can have different relations to the zone delegated 128 to them. The following categories will use the example of the zone 129 "del.example" being delegated from the "example" TLD zone. 131 in domain A name server can be within the delegated domain, which 132 includes the name of the delegated domain itself, e.g., 133 "del.example", "dns.del.example", or "dns.sub.del.example". In 134 all but the first case the name might be part of a subzone of 135 "del.example". This naming scheme is sometimes also called "in- 136 bailiwick". 138 sibling domain A name server's name can be within the delegating but 139 outside the delegated domain, e.g., "dns.other.example". There 140 are two sub-cases here, depending on the treatment of the 141 "other.example" domain: 143 authoritative in sibling When the name server's name is within 144 the parent domain, but in a separate zone, this is a sibling 145 zone of the delegated zone. 147 authoritative in parent A name server's name may also appear 148 authoritative in the parent zone. 150 unrelated A name server's name may not share its parent with the 151 delegated domain, e.g., "dns.example.org". 153 {To be elaborated further.} 155 5. Glue Policies 157 In the DNS tree different policies are applied with respect to 158 registering glue with the delegating zone. "Registering" in this 159 case means that the respective glue information is accepted, 160 requested or required and then attached to the zone data so that it 161 is available at all authoritative servers, i.e. the glue travels with 162 the zone data by AXFR, IXFR or other means. However, it does not 163 make the glue data part of the zone's authoritative data. 165 This is a list of existing glue policies: 167 "never" or "null": Glue RRs are never registered. This currently 168 applies to larger parts of the IN-ADDR.ARPA reverse tree. 170 "narrow": Glue RRs are registered if and only if the name server 171 resides within or below the delegated (child) zone (that is, 172 within the delegated domain). This was suggested by [RFC1034]. 174 "wide": Glue RRs are registered if and only if the name server 175 resides below the delegating (parent) zone. There is no need to 176 register glue RRs if the name server's name belongs into the 177 parent zone. This was suggested by [RFC1033]. It is used for the 178 root zone. 180 "case by case": Glue RRs are registered following the "narrow" 181 policy except where there are (circular) dependencies that demand 182 additional glue RRs. 184 "mandatory": Glue RRs are always registered for all name servers. 185 This was suggested by [RFC0973]. 187 "other": Combinations of the above may exist, e.g. if a registry 188 runs multiple sibling domains and decides to register glue RRs 189 whenever a name server resides in or below one of the siblings. 190 This category would also include other policies like "random" or 191 "arbitrary". 193 Glue RRs are needed only in the delegating zone, regardless of glue 194 policy. See Section 6.1 for a discussion of root zone issues. 196 Various RFCs have identified extraneous glue RRs as sources of error 197 and confusion ([RFC1713], [RFC1912]). 199 6. Open Issues 201 Future versions of this document will expand on these topics: 203 o Software issues when following NS RRs 204 [I-D.minda-dnsop-using-in-bailiwick-nameservers] 206 o Mixed IPv4 and IPv6 environments, following the example of 207 [RFC4472]. 209 o TTL considerations: glue data vs. authoritative data as well as NS 210 RRSet TTLs vs A RRSet TTLs 212 6.1. Root Server "Glue" in the Root Zone File 214 As said before, Glue is meant to be present in the delegating zone 215 only. The only exception seems to be root zone which also contains 216 the address records for its authoritative name servers. However, 217 with the current setup the root servers also serve the ARPA domain 218 and with the root zone's "wide" glue policy this means that there 219 should be glue RRs for this particular set of nameservers, but only 220 in their capacity as ARPA TLD servers. [The position of the A RRs in 221 the root zone file (which has just editorial value) as well as their 222 TTLs suggest that historically there will have been a different 223 reason]. 225 Also, per operational practice, almost all root servers are 226 authoritative for the zone they reside in (even if that is not 227 officially delegated to all the 13 servers). So, they have the 228 authoritative data present and do not need to rely upon the data 229 transported with the root zone. 231 [To have a complete trust chain available at the root servers leading 232 to their own names, it would be useful to have them configured 233 authoritative for all intermediate zones. It has been suggested 234 before to move the root server's names to a distinct TLD. Another 235 option would be to move their names to e.g. ROOT-SERVERS.ARPA 236 instead.] 238 6.2. Using Glue records in responses 240 Some implementations use Glue information not only during additional 241 section processing, but also in the answer section of responses. 243 Given an excerpt of the "example" TLD zone file, 245 one.example. NS dns.one.example. 246 NS dns.two.example. 247 dns.one.example. A 192.0.2.53 249 what should a name server authoritative for the example TLD do when 250 asked for the A RR for dns.one.example? Some implementations will 251 put the A RR in the answer section of the response, others will 252 respond with a referral and only copy the glue A RR into the 253 additional section (the handling of dns.two.example's A RR is not 254 considered here). 256 Step 4 of the algorithm in 4.3.2 of [RFC1034] suggests that after 257 copying the NS RRs into the authority section (in step 3b) the cache 258 should be consulted and used to fill the answer section. Depending 259 on whether or not Glue data is considered to reside in the cache (it 260 is definitely not authoritative), one or the other response type will 261 be preferred. 263 With DNSSEC an A RRSet response originating from glue data will 264 always miss the appropriate signature, because neither does the 265 delegating zone sign the glue RRSet nor does a glue RRSIG (child's 266 signature covering the address RRSet) exist in that delegating zone. 268 [discuss levels of indirection and operational reasons that lead to 269 the "gluepot response"] 271 6.3. Glue RRs for multihomed name servers 273 Some name server names resolve to A or AAAA RRSets consisting of more 274 than one record, i.e. they have multiple addresses. It is 275 recommended that these RRSets be consistent between the child and the 276 parent. 278 Research is needed to evaluate the effective difference between 279 multiple names and multiple addresses for a name server. These 280 effects heavily depend on server selection algorithms in resolvers. 282 6.4. Grandchild Glue 284 When a name server resides within the delegated domain, the 285 delegation needs a glue record with both the "wide" and the "narrow" 286 glue policy. However, the server does not necessarily have its name 287 within the delegated zone since it may belong to a child or 288 grandchild zone of the delegated one. 290 This is a delegation in the example TLD: 292 one.example. NS one.example. 293 NS dns.one.example. 294 NS dns.deep.one.example. 296 Only the first name server is known to have its name in the delegated 297 zone, where the second and third could both be in separate zones. 298 NB: even dns.one.example. could be a zone delegated from one.example. 300 As a consequence, it cannot be concluded that any such name server is 301 able to authoritatively serve its own name, e.g., if it does not 302 serve the grandchild zone. 304 7. DNSSEC Considerations 306 DNSSEC signatures do not cover glue records [RFC3833], [RFC4033]. 308 Using the gluepot to fill the answer section is discouraged with 309 DNSSEC, see Section 6.2. 311 8. IPv6 Considerations 313 While this document makes no explicit statements about AAAA RRs, 314 similar logic applies except in cases where A and AAAA glue RR 315 interaction requires specific consideration (response packet size, 316 TTL consistency, namespace fragmentation). 318 The specification of the A6 RR [RFC2874] contains, in section 5.1.2, 319 a detailed discussion of glue issues due to the variable 320 representation of IPv6 addresses in A6. 322 9. Security Considerations 324 This section needs more work 326 10. IANA Considerations 328 This section needs more work 330 11. References 332 [I-D.ietf-dnsext-axfr-clarify] 333 Gustafsson, A., "DNS Zone Transfer Protocol 334 Clarifications", draft-ietf-dnsext-axfr-clarify-05 (work 335 in progress), December 2002. 337 [I-D.ietf-dnsop-respsize] 338 Vixie, P. and A. Kato, "DNS Referral Response Size 339 Issues", draft-ietf-dnsop-respsize-07 (work in progress), 340 February 2007. 342 [I-D.minda-dnsop-using-in-bailiwick-nameservers] 343 Minda, M., "Using In-Bailiwick Namesevers in .ARPA", 344 draft-minda-dnsop-using-in-bailiwick-nameservers-01 (work 345 in progress), July 2005. 347 [RFC0973] Mockapetris, P., "Domain system changes and observations", 348 RFC 973, January 1986. 350 [RFC1033] Lottor, M., "Domain administrators operations guide", 351 RFC 1033, November 1987. 353 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 354 STD 13, RFC 1034, November 1987. 356 [RFC1035] Mockapetris, P., "Domain names - implementation and 357 specification", STD 13, RFC 1035, November 1987. 359 [RFC1207] Malkin, G., Marine, A., and J. Reynolds, "FYI on Questions 360 and Answers: Answers to commonly asked "experienced 361 Internet user" questions", RFC 1207, February 1991. 363 [RFC1386] Cooper, A. and J. Postel, "The US Domain", RFC 1386, 364 December 1992. 366 [RFC1537] Beertema, P., "Common DNS Data File Configuration Errors", 367 RFC 1537, October 1993. 369 [RFC1637] Manning, B. and R. Colella, "DNS NSAP Resource Records", 370 RFC 1637, June 1994. 372 [RFC1713] Romao, A., "Tools for DNS debugging", RFC 1713, 373 November 1994. 375 [RFC1912] Barr, D., "Common DNS Operational and Configuration 376 Errors", RFC 1912, February 1996. 378 [RFC2010] Manning, B. and P. Vixie, "Operational Criteria for Root 379 Name Servers", RFC 2010, October 1996. 381 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 382 Extensions", RFC 2065, January 1997. 384 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 385 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 386 RFC 2136, April 1997. 388 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 389 Specification", RFC 2181, July 1997. 391 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 392 RFC 2535, March 1999. 394 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 395 Names", BCP 32, RFC 2606, June 1999. 397 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 398 RFC 2672, August 1999. 400 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 401 Wellington, "Secret Key Transaction Authentication for DNS 402 (TSIG)", RFC 2845, May 2000. 404 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 405 IPv6 Address Aggregation and Renumbering", RFC 2874, 406 July 2000. 408 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 409 SIG(0)s)", RFC 2931, September 2000. 411 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 412 September 2002. 414 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 415 Hain, "Representing Internet Protocol version 6 (IPv6) 416 Addresses in the Domain Name System (DNS)", RFC 3363, 417 August 2002. 419 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 420 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 421 August 2002. 423 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol 424 Requirements", RFC 3375, September 2002. 426 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 427 (RR)", RFC 3658, December 2003. 429 [RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 430 Domain Name Mapping", RFC 3731, March 2004. 432 [RFC3732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 433 Host Mapping", RFC 3732, March 2004. 435 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 436 Name System (DNS)", RFC 3833, August 2004. 438 [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) 439 RDATA Format", RFC 3845, August 2004. 441 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 443 Rose, "DNS Security Introduction and Requirements", 444 RFC 4033, March 2005. 446 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 447 Rose, "Resource Records for the DNS Security Extensions", 448 RFC 4034, March 2005. 450 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 451 Rose, "Protocol Modifications for the DNS Security 452 Extensions", RFC 4035, March 2005. 454 [RFC4183] Warnicke, E., "A Suggested Scheme for DNS Resolution of 455 Networks and Gateways", RFC 4183, September 2005. 457 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 458 Considerations and Issues with IPv6 DNS", RFC 4472, 459 April 2006. 461 [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution 462 Misbehavior", BCP 123, RFC 4697, October 2006. 464 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 465 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 466 Signatures", RFC 4871, May 2007. 468 [RFC4931] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 469 Domain Name Mapping", RFC 4931, May 2007. 471 [RFC4932] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 472 Host Mapping", RFC 4932, May 2007. 474 Appendix A. Document Revision History 476 This section is to be removed should the draft be published. 478 A.1. Changes from -02 to -03 480 Added text about name server naming 482 Maintenance of references, minor edits 484 A.2. Changes from -01 to -02 486 Added text about grandchild glue 488 Maintenance of references, minor edits 490 A.3. Changes from -00 to -01 492 Mentioned RFC survey 494 Added text about root server glue 496 New text for using glue in responses 498 Author's Address 500 Peter Koch 501 DENIC eG 502 Wiesenhuettenplatz 26 503 Frankfurt 60329 504 DE 506 Phone: +49 69 27235 0 507 Email: pk@DENIC.DE 509 Full Copyright Statement 511 Copyright (C) The IETF Trust (2007). 513 This document is subject to the rights, licenses and restrictions 514 contained in BCP 78, and except as set forth therein, the authors 515 retain all their rights. 517 This document and the information contained herein are provided on an 518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 520 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 521 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 522 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 525 Intellectual Property 527 The IETF takes no position regarding the validity or scope of any 528 Intellectual Property Rights or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; nor does it represent that it has 532 made any independent effort to identify any such rights. Information 533 on the procedures with respect to rights in RFC documents can be 534 found in BCP 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an 538 attempt made to obtain a general license or permission for the use of 539 such proprietary rights by implementers or users of this 540 specification can be obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights that may cover technology that may be required to implement 546 this standard. Please address the information to the IETF at 547 ietf-ipr@ietf.org. 549 Acknowledgment 551 Funding for the RFC Editor function is provided by the IETF 552 Administrative Support Activity (IASA).