idnits 2.17.1 draft-msullivan-dnsop-generic-naming-schemes-00.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 21. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 86 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (April 2006) is 6584 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: 'Section 4' is mentioned on line 608, but not defined == Unused Reference: 'RFC 1033' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'RFC 1034' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 933, but no explicit reference was found in the text == Unused Reference: 'RFC 1123' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFC 1178' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'RFC 1183' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'RFC 1535' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'RFC 1536' is defined on line 953, but no explicit reference was found in the text == Unused Reference: 'RFC 1537' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'RFC 1912' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC 2821' is defined on line 965, but no explicit reference was found in the text == Unused Reference: 'RFC 3912' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'RFC 4084' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'BOG' is defined on line 975, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Downref: Normative reference to an Informational RFC: RFC 1178 ** Downref: Normative reference to an Experimental RFC: RFC 1183 ** Downref: Normative reference to an Informational RFC: RFC 1535 ** Downref: Normative reference to an Informational RFC: RFC 1536 ** Obsolete normative reference: RFC 1537 (Obsoleted by RFC 1912) ** Downref: Normative reference to an Informational RFC: RFC 1912 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) -- Possible downref: Non-RFC (?) normative reference: ref. 'BOG' Summary: 17 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name Working Group Matthew Sullivan 3 Request for Comments: DRAFT Spam and Open Relay Blocking System 4 Luis Munoz 5 CANTV 6 Expires: October 2006 April 2006 7 Document: draft-msullivan-dnsop-generic-naming-schemes-00.txt 9 Suggested Generic DNS Naming Schemes 10 for Large Networks and Unassigned hosts. 12 Status of this Memo 14 This memo provides information for the Internet community. This memo 15 does not specify an Internet standard of any kind. Distribution of 16 this memo is unlimited. 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This memo describes basic DNS configurations and details suggestions 42 for a common naming scheme for records that are automatically 43 generated and therefore likely generic in nature. This memo will re- 44 iterate issues highlighted in a number of other RFCs such as RFC 45 1912. 47 RFC DRAFT October 2005 49 Notation 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119. 55 TABLE OF CONTENTS 57 MEMO STATUS .................................................. 1 59 ABSTRACT ..................................................... 1 61 NOTATION ..................................................... 2 63 TABLE OF CONTENTS ............................................ 2 65 1. INTRODUCTION ................................................. 2 67 2. BACKGROUND ................................................. 3 69 3. GENERIC RECORDS .............................................. 4 71 4. Allocation Type Assignment Indicators ......................... 5 72 4.1. Static address ranges .................................... 5 73 4.2. Dynamic Address Ranges ................................... 6 74 4.3. Unassigned Address Ranges ................................ 7 76 5. Transport Type Assignment Indicators .......................... 7 77 5.1. DSL link transport indicators ............................ 8 78 5.2. Dial-Up transport indicators ............................. 8 79 5.3. Cable modem terminated link indicators ................... 9 80 5.4. Mobile device (GPRS, WiFi etc) ........................... 9 81 5.5. Address ranges assigned to multi purpose links ........... 10 82 5.6. Address ranges assigned to leased lines and ATM links .... 11 84 6. Customer Type Assignment Indicators ........................... 12 85 6.1. Address ranges assigned to business customers ............ 12 86 6.2. Address ranges assigned to residential customers ......... 12 87 6.3. Address ranges assigned to co-location customers ......... 13 88 6.4. Address ranges assigned to shared server customers ....... 13 90 7. Server/Machine Type Assignment Indicators ..................... 14 91 7.1. Address ranges assigned to mail servers .................. 14 92 7.1.1. Assignments for incoming mail servers ................ 14 93 7.1.2. Assignments for incoming and outgoing mail servers ... 15 94 7.1.3. Assignments for outgoing mail servers ................ 15 95 7.2. Address ranges assigned for web servers .................. 16 96 7.3. Address ranges assigned for DNS servers .................. 16 98 RFC DRAFT October 2005 100 7.4. Address ranges assigned for core infrastructure .......... 17 101 7.5. Address ranges assigned for multi-purpose hosts .......... 17 103 8. Language Issues in Naming Schemes ............................ 18 105 9. Miscellaneous Items with Respect to Naming Schemes ........... 18 107 10. DNS Requirements ............................................. 19 109 11. Security Considerations ...................................... 19 111 12. Acknowledgements ............................................. 19 113 13. References ................................................... 19 115 Copyright and Disclaimer ..................................... 20 117 Author's Address ............................................. 21 119 1. Introduction 121 All Internet connected hosts should have a host name which will 122 identify its IP address as well as an entry in the IN-ADDR.ARPA. 123 domain indicating its host name. 125 For large IP address lists it can be impractical to give each host 126 and individual host name and record that host name for both A DNS RRs 127 and PTR DNS RRs. To make the task of providing individual records 128 for net blocks simpler, various facilities are available to generate 129 zone files. Large zone files can be very impractical to manipulate 130 so some DNS servers allow for a keyword to format and generate mass 131 zone data internally within the running server. 133 Unfortunately, the use of these generated records has resulted in a 134 significant difficulty for remote networks to identify the 135 perpetrators of varying forms of network abuse. 137 This memo will not provide syntactical detail of the commands or 138 scripts used. It will however, suggest a common naming scheme for 139 use in automatically generated zones where zones cannot be crafted 140 with the actual host names of the machines. 142 2. Background 144 The need for a common format is becoming more and more apparent in 145 the fight against abuse. The abuse across the Internet began in the 146 early days of the Network and took many forms, from hacking and 148 RFC DRAFT October 2005 150 cracking, to abusing open SMTP relays and proxy servers for the 151 propagation of spam. 153 Those who have taken it upon themselves to attempt to stop this abuse 154 of resources, and those who are tasked with investigating the source 155 of the abuse, seem to come up against a number of issues relating to 156 the identification of the source of the abuse. 158 The identification of the source of abuse is a problem for many 159 reasons, first the IP address to host mapping often will give no 160 indication of the appropriate services the host does provide. It 161 gives no clue as to whether the abuse attempt on one IP address in a 162 network followed by a second is the same host attempting the same 163 abuse or whether there are multiple hosts involved. The host mapping 164 will often either not exist or, refer to a non-existent host name 165 with little or no indication of the person responsible or 166 organisation for abuse issues arising from the host. 168 Clear identification and records for a host and network would resolve 169 most of issues relating to the identification of abusing or abused 170 hosts. Identification that includes reasonable information as to the 171 purpose or configuration of the host will also allow other networks 172 to configure access, thereby limiting abuse, using these 173 identification records. 175 3. Generic Records 177 Generic records are the most basic form of host names and are used in 178 large networks where the administrators of those networks have 179 classes of hosts all similar in type. The administrators of the 180 records often will not have access to the configuration of the hosts 181 as they will typically be 'customer' machines. 183 Generic records are typically seen as records configured like the 184 following example: 186 $ORIGIN 0.0.10.IN-ADDR.ARPA. 187 0 IN PTR 0.0.0.10.example.com. 188 1 IN PTR 1.0.0.10.example.com. 189 . 190 . 191 254 IN PTR 254.0.0.10.example.com. 192 255 IN PTR 255.0.0.10.example.com. 194 Typically these hosts offer no information about their purpose, nor 195 whether they are actually allocated. For that reason where access is 196 restricted in any way it is expected that hosts in this networks will 197 be granted no special privilege, and in many cases may be denied 199 RFC DRAFT October 2005 201 access. 203 4. Allocation Type Assignment Indicators 205 The following sub-sections gives suggested naming schemes for generic 206 static, dynamic and unassigned address blocks. The naming schemes 207 are not mandatory, but are strongly recommended for the sake of 208 consistency. 210 Regardless of the nature of the address block, the names configured 211 in the DNS IN-ADDR.ARPA zone SHOULD contain the domain name of the 212 organization responsible for the operation of the hosts at its 213 rightmost position. 215 4.1. Static Address Ranges 217 In static host allocations, the IP addresses have been assigned to an 218 individual host in a persistent matter. This can be by manually 219 configuring the host's network interface(s) with a non-volatile 220 configuration, or by the use of host configuration protocols such as 221 DHCP in a manner that guarentees that the same host will always 222 receive the sane IP address. It should be noted that to be 223 considered static the interface MUST be configured to the same 224 address every time it is connected to the Internet. 226 DNS RRs for statically configured hosts SHOULD echo the fully 227 qualified real name(s) of the host. Where this is not possible and 228 subnet delegation, as described in RFC 2317 is not possible generic 229 records MUST be used. To comply with RFC 1912 all PTR DNS RRs MUST 230 have corresponding A RRs. The format of the PTR records SHOULD 231 indicate that the hosts are statically allocated their addresses. 232 The suggested format for the records is as follows: 234 $ORIGIN 0.0.10.IN-ADDR.ARPA. 235 0 IN PTR 0.0.0.10.static.example.com. 236 1 IN PTR 1.0.0.10.static.example.com. 237 . 238 . 239 254 IN PTR 254.0.0.10.static.example.com. 240 255 IN PTR 255.0.0.10.static.example.com. 242 Where the DNS resolution provider is concerned with respect to 243 resources, and/or the provider is using additional information 244 convention, the word 'static' MAY be abbreviated to 'sta', for 245 example: 247 $ORIGIN 0.0.10.IN-ADDR.ARPA. 248 0 IN PTR 0.0.0.10.sta.example.com. 250 RFC DRAFT October 2005 252 1 IN PTR 1.0.0.10.sta.example.com. 253 . 254 . 255 254 IN PTR 254.0.0.10.sta.example.com. 256 255 IN PTR 255.0.0.10.sta.example.com. 258 The static identifier MUST be presented as the identifier nearest the 259 sub domain or domain name where used. 261 The static identifier MUST only be used when the organization 262 responsible for the operation IN-ADDR.ARPA. zone able to accurately 263 map an IP address to the host that this address was assigned to at 264 any given date and time. 266 4.2. Dynamic Address Ranges 268 In dynamic host allocations, the hosts addresses are configured at 269 runtime and may change at any predetermined interval. This type of 270 allocation is typically acheived by configuring the host's network 271 interface(s) through protocols like DHCP. PPP up links whether dial 272 up, PPP over Ethernet or PPP over ATM typically will not know either 273 one of the endpoints and MUST be considered as dynamically allocated. 275 DNS RRs for dynamically configured hosts SHOULD NOT echo the fully 276 qualified real name(s) of the host as the information is likely to 277 change without warning. Generic records MUST be used for dynamically 278 allocated networks. To comply with RFC 1912 all PTR DNS RRs MUST 279 have corresponding A RRs. The format of the PTR records SHOULD 280 indicate that the hosts are dynamically allocated their addresses. 281 The suggested format for the records is as follows: 283 $ORIGIN 0.0.10.IN-ADDR.ARPA. 284 0 IN PTR 0.0.0.10.dynamic.example.com. 285 1 IN PTR 1.0.0.10.dynamic.example.com. 286 . 287 . 288 254 IN PTR 254.0.0.10.dynamic.example.com. 289 255 IN PTR 255.0.0.10.dynamic.example.com. 291 Where the DNS resolution provider is concerned with respect to 292 resources, and/or the provider is using additional information 293 convention, the word 'dynamic' MAY be abbreviated to 'dyn', for 294 example: 296 $ORIGIN 0.0.10.IN-ADDR.ARPA. 297 0 IN PTR 0.0.0.10.dyn.example.com. 298 1 IN PTR 1.0.0.10.dyn.example.com. 299 . 301 RFC DRAFT October 2005 303 . 304 254 IN PTR 254.0.0.10.dyn.example.com. 305 255 IN PTR 255.0.0.10.dyn.example.com. 307 The dynamic identifier MUST be presented as the identifier nearest 308 the sub domain or domain name where used. 310 4.3. Unassigned Address Ranges 312 Unassigned address ranges are where the address range is allocated to 313 an organisation and the addresses have no hosts using them, nor are 314 any hosts expected to use them in the immediate future. 316 Note: Ranges configured for hosts but as yet with no hosts connected 317 MUST NOT be considered 'Unassigned'. 319 Unassigned ranges MUST be configured for DNS by EITHER having no PTR 320 records for the range OR by using the keyword 'unassigned' in host 321 names specified in the IN-ADDR.ARPA. domain. For example: 323 $ORIGIN 0.0.10.IN-ADDR.ARPA. 324 0 IN PTR 0.0.0.10.unassigned.example.com. 325 1 IN PTR 1.0.0.10.unassigned.example.com. 326 . 327 . 328 254 IN PTR 254.0.0.10.unassigned.example.com. 329 255 IN PTR 255.0.0.10.unassigned.example.com. 331 Unlike other types of PTR record it is acceptable though not advised 332 to use the same host name in every PTR record, for example: 334 $ORIGIN 0.0.10.IN-ADDR.ARPA. 335 0 IN PTR unassigned.example.com. 336 1 IN PTR unassigned.example.com. 337 . 338 . 339 254 IN PTR unassigned.example.com. 340 255 IN PTR unassigned.example.com. 342 5. Transport Type Assignment Indicators 344 The following sub-sections suggest and recommend naming conventions 345 for the more common type of transport type indicators. These are not 346 mandatory indicators, however it is recommended that if transport 347 type indicators are to be used the following indicators SHOULD be 348 used for consistency. 350 RFC DRAFT October 2005 352 Allocations type assignment indicators [Section 4] MUST be configured 353 whenever Transport type indicators are used. 355 5.1. DSL Transport Indicators 357 DSL transport indicators for address ranges are where the address 358 range is solely used for DSL end points regardless of static 359 assignment or customer type. DSL transport is identified by the use 360 of the 'dsl' indicator in host names specified in the IN-ADDR.ARPA. 361 domain. For example: 363 $ORIGIN 0.0.10.IN-ADDR.ARPA. 364 0 IN PTR 0.0.0.10.dsl.dyn.example.com. 365 1 IN PTR 1.0.0.10.dsl.dyn.example.com. 366 . 367 . 368 254 IN PTR 254.0.0.10.dsl.sta.example.com. 369 255 IN PTR 255.0.0.10.dsl.sta.example.com. 371 Where more specific DSL Transport type indicators are required the 372 'dsl' identifier SHOULD be prefixed with a type abbreviation. Valid 373 type abbreviations are as follows: 375 $ORIGIN 0.0.10.IN-ADDR.ARPA. 376 0 IN PTR 0.0.0.10.adsl.dyn.example.com. 377 ; ADSL and ADSL2 378 1 IN PTR 0.0.0.10.sdsl.dyn.example.com. 379 ; Symmetric DSL 380 . 381 . 382 254 IN PTR 0.0.0.10.shdsl.sta.example.com. 383 ; Symmetric High speed DSL 384 255 IN PTR 0.0.0.10.a2dsl.sta.example.com. 385 ; ADSL2 387 5.2. Dial-Up Transport Indicators 389 Dial-Up transport indicators for address ranges are applicable when 390 the range is solely used for end points that have to dial access 391 numbers via PSTN. 393 Dial-up transport is identified by the use of the 'dial' indicator in 394 host names specified in the IN-ADDR.ARPA. domain. For example: 396 $ORIGIN 0.0.10.IN-ADDR.ARPA. 397 0 IN PTR 0.0.0.10.dial.dyn.example.com. 398 1 IN PTR 1.0.0.10.dial.dyn.example.com. 400 RFC DRAFT October 2005 402 . 403 . 404 254 IN PTR 254.0.0.10.dial.sta.example.com. 405 255 IN PTR 255.0.0.10.dial.sta.example.com. 407 Where most specific Dial-Up Transport type indicators are required 408 the 'dial' identifier SHOULD be replaced with a more specific 409 indicator such as: 411 $ORIGIN 0.0.10.IN-ADDR.ARPA. 412 0 IN PTR 0.0.0.10.isdn.dyn.example.com. 413 ; ISDN connections 414 1 IN PTR 1.0.0.10.dov.dyn.example.com. 415 ; Digital Over Voice ISDN 416 . 417 . 418 254 IN PTR 254.0.0.10.modem.sta.example.com. 419 ; Standard Analog Modem 420 255 IN PTR 255.0.0.10.modem.dyn.example.com. 421 ; Standard Analog Modem 423 5.3. Cable Modem Transport Indicators 425 Cable modem transport indicators for address ranges are appropriate 426 when the range is solely used for end points that are terminated at 427 cable modems. 429 Cable transport type is identified by the use of the 'cable' 430 indicator in host names specified in the IN-ADDR.ARPA. domain. For 431 example: 433 $ORIGIN 0.0.10.IN-ADDR.ARPA. 434 0 IN PTR 0.0.0.10.cable.dyn.example.com. 435 1 IN PTR 1.0.0.10.cable.dyn.example.com. 436 . 437 . 438 254 IN PTR 254.0.0.10.cable.sta.example.com. 439 255 IN PTR 255.0.0.10.cable.sta.example.com. 441 5.4. Mobile Device Indicators 443 Mobile device indicators are provided for address ranges where the 444 range is used for transport types associated with mobile devices, for 445 example, laptop computers with wireless network interfaces, mobile 446 phones, etc. Where the provider does not wish to distinguish the 447 type of connected device, the provider SHOULD use the 'wireless' 449 RFC DRAFT October 2005 451 token, for example: 453 $ORIGIN 0.0.10.IN-ADDR.ARPA. 454 0 IN PTR 0.0.0.10.wireless.dyn.example.com. 455 1 IN PTR 1.0.0.10.wireless.dyn.example.com. 456 . 457 . 458 254 IN PTR 254.0.0.10.wireless.sta.example.com. 459 255 IN PTR 255.0.0.10.wireless.sta.example.com. 461 For networks where the provider wishes to identify the connecting 462 host more accurately, the following tokens SHOULD be used: 464 $ORIGIN 0.0.10.IN-ADDR.ARPA. 465 0 IN PTR 0.0.wifi.dyn.example.com. ; WiFi Devices 466 1 IN PTR 0.1.gprs.dyn.example.com. ; GPRS devices 467 . 468 . 469 254 IN PTR 0.254.cdma.dyn.example.com. ; CDMA devices 470 255 IN PTR 0.255.bt.dyn.example.com. ; Bluetooth 472 This list is expandable and care should be exercised when choosing 473 tokens that are not explicitly specified. 475 5.5. Multi-Purpose Transport Indicators 477 Multi-purpose transport indicators are provided for address ranges 478 that are used for multiple transport types. For example, a service 479 which provides ADSL connectivity with backup dial up would be better 480 identified as a multi type, or by the primary (in this case ADSL) 481 indicator. 483 Multiple transport type addresses are identified by the use of the 484 'multi' indicator in host names specified in the IN-ADDR.ARPA. 485 domain. For example: 487 $ORIGIN 0.0.10.IN-ADDR.ARPA. 488 0 IN PTR 0.0.0.10.multi.dyn.example.com. 489 1 IN PTR 1.0.0.10.multi.dyn.example.com. 490 . 491 . 492 254 IN PTR 254.0.0.10.multi.sta.example.com. 493 255 IN PTR 255.0.0.10.multi.sta.example.com. 495 RFC DRAFT October 2005 497 5.6. Dedicated links 499 ATM and dedicated transport indicators for address ranges are where 500 the range is solely used for networks that are connected via ATM, 501 leased line or other types of dedicated connection. 503 Generally ATM and leased line links SHOULD have host names connected, 504 however where generic naming is required the following tokens SHOULD 505 be used: 507 $ORIGIN 0.0.10.IN-ADDR.ARPA. 508 0 IN PTR 0.0.0.10.atm.dyn.example.com. ; ATM 509 1 IN PTR 1.0.0.10.eth.dyn.example.com. ; Ethernet 510 2 IN PTR 2.0.0.10.ll.dyn.example.com. ; Leased Line 511 3 IN PTR 3.0.0.10.mwv.sta.example.com. ; Microwave 512 . 513 . 514 50 IN PTR 50.0.0.10.oc3.sta.example.com. ; OC3 515 51 IN PTR 51.0.0.10.e3.sta.example.com. ; E3 516 52 IN PTR 52.0.0.10.t1.sta.example.com. ; T1 (etc.) 517 . 518 . 519 253 IN PTR 253.0.0.10.giga.sta.example.com. ; Gigabit 520 254 IN PTR 254.0.0.10.fiber.sta.example.com. ; Fiber 521 255 IN PTR 255.0.0.10.laser.sta.example.com. ; LASER 523 As the types of transport described in this section are mostly fixed, 524 the use of the token 'dedicated' MAY be used where specific typing is 525 not desired. 527 The 'dedicated' token MUST NOT be used for networks where the 528 assignments are dynamic. The 'dedicated' token can be using in place 529 of the 'static' token described in 4.1. 531 The 'dedicated' token can be shortened to 'ded' for resource economy. 532 For example: 534 $ORIGIN 0.0.10.IN-ADDR.ARPA. 535 0 IN PTR 0.0.0.10.dedicated.example.com. 536 1 IN PTR 1.0.0.10.dedicated.example.com. 537 . 538 . 539 254 IN PTR 254.0.0.10.ded.example.com. 540 255 IN PTR 255.0.0.10.ded.example.com. 542 RFC DRAFT October 2005 544 6. Consumer Type Assignment Indicators 546 The following sub-sections suggest and recommend naming conventions 547 for the more common types of consumer transport type indicators. 548 These are not mandatory indicators, however it is recommended that if 549 consumer type indicators are to be used the following indicators 550 SHOULD be used for consistency. 552 Allocations type assignment indicators [Section 4] MUST be configured 553 whenever consumer type indicators are used, and the addresses are 554 assigned dynamically. 556 6.1. Business Customers Addresses 558 Business consumer indicators for address ranges are where the range 559 is solely used for networks that are connected to business customers. 561 Generally business consumers SHOULD have host names of machines 562 connected, however where generic naming is required the following 563 tokens SHOULD be used: 565 $ORIGIN 0.0.10.IN-ADDR.ARPA. 566 0 IN PTR 0.0.0.10.biz.dyn.example.com. 567 1 IN PTR 1.0.0.10.biz.dyn.example.com. 568 . 569 . 570 254 IN PTR 254.0.0.10.biz.sta.example.com. 571 255 IN PTR 255.0.0.10.biz.sta.example.com. 573 6.2. Residential Customer Addresses 575 Residential consumer indicators for address ranges are where the 576 range is solely used for networks that are connected to residential 577 customers, including residential networks at educational 578 institutions. 580 Generally, residential consumers will not have host names of machines 581 connected, however the IN-ADDR.ARPA. zone MUST have records 582 identifying the connectivity provider. Generic naming SHOULD use the 583 'client' or 'res' token. For educational institutes it is common to 584 use the token 'resnet', this token is also acceptable. 586 An allocation type assignment tokens [Section 4] MUST be used with 587 the residential customer type indicator, for example: 589 $ORIGIN 0.0.10.IN-ADDR.ARPA. 590 0 IN PTR 0.0.0.10.res.dyn.example.com. 592 RFC DRAFT October 2005 594 1 IN PTR 1.0.0.10.client.dyn.example.com. 595 . 596 . 597 254 IN PTR 254.0.0.10.client.sta.example.com. 598 255 IN PTR 255.0.0.10.res.sta.example.com. 600 6.3. Co-Location Customers and Address Ranges 602 Co-location customers are those providing their own dedicated 603 hardware which is located within a providers network. Co-location 604 customers SHOULD have their own records, however where the provider 605 decides not to provide specific host name support within the IN- 606 ADDR.ARPA. domain the 'colo' assignment token MUST be used. 608 An allocations type assignment token [Section 4] is not expected to 609 be used for co-location servers when assigned static addresses. For 610 example: 612 $ORIGIN 0.0.10.IN-ADDR.ARPA. 613 0 IN PTR 0.0.0.10.colo.example.com. 614 1 IN PTR 1.0.0.10.colo.example.com. 615 . 616 . 617 254 IN PTR 254.0.0.10.colo.example.com. 618 255 IN PTR 255.0.0.10.colo.example.com. 620 In the unusual configuration that co-location ranges are assigned 621 dynamically the 'dyn' allocation type token MUST be used. For 622 example: 624 $ORIGIN 0.0.10.IN-ADDR.ARPA. 625 0 IN PTR 0.0.0.10.colo.dyn.example.com. 626 1 IN PTR 1.0.0.10.colo.dyn.example.com. 627 . 628 . 629 254 IN PTR 254.0.0.10.colo.dyn.example.com. 630 255 IN PTR 255.0.0.10.colo.dyn.example.com. 632 6.4. Shared Server Addresses 634 Shared server addresses are used for a providers' address range where 635 the servers house multiple consumers and where a single address may 636 have a number of customers assigned. Shared server addresses SHOULD 637 have the host name of the machine in the IN-ADDR.ARPA. domain. Where 638 the service provider chooses not to use the host name or customer 639 supplied host name of the machine in the IN-ADDR.ARPA. domain, 641 RFC DRAFT October 2005 643 generic records MUST be used. A generic record for a shared server 644 SHOULD include the 'shared' token, but MAY replace it with a token 645 identifying the service provided [See Section 7], for example: 647 $ORIGIN 0.0.10.IN-ADDR.ARPA. 648 0 IN PTR 0.0.0.10.shared.example.com. 649 1 IN PTR 1.0.0.10.shared.example.com. 650 . 651 . 652 254 IN PTR 254.0.0.10.shared.example.com. 653 255 IN PTR 255.0.0.10.shared.example.com. 655 As with co-location ranges, is it unusual for shared server addresses 656 to be assigned dynamically, so the 'dyn' allocation type token MUST 657 be used where the addresses are not assigned statically. 659 7. Server Type Assignment Indicators 661 Server type assignment indicators are used where servers are to be 662 identified by remote servers and services for a specific type of 663 traffic. Use of these indicators should be used carefully as DNS 664 provides the WKS RR type, the assignment indicators should still be 665 used in conjunction with the WKS RR type as there is no current 666 method to map IP addresses to services. 668 Server type indicators should not normally be used in generic records 669 as generic records are used where it is impractical to set individual 670 customer host names. Server type indicators for generic records are 671 provided for large organisations where there is a large cluster of 672 machines with the same purpose. 674 Unlike with other generic indicators the server type indicator MUST 675 prefix the host name in the DNS RR. 677 7.1. Mail Server Indicators 679 Often in large networks, the purpose of mail servers is not to send 680 and receive mail, but send mail or receive mail. For that reason the 681 identifiers have been split into three main tokens, one for general 682 mail servers, one for incoming only mail servers and one for outgoing 683 only mail servers. 685 7.1.1. Incoming Mail servers 687 Incoming mail servers MUST HAVE both a DNS RR of type A and a DNS RR 688 of type PTR, both DNS RRs MUST be complementary. The DNS RRs SHOULD 689 match the host name of the server so that the host name presented in 691 RFC DRAFT October 2005 693 the mail server's response to the HELO or EHLO commands matches the 694 host name in the A and PTR records. In large networks it is often 695 desirable to use a generic name to identify the host without tying 696 public records to specific hardware. This is particularly important 697 when using load balancers and similar hardware. Suggested tokens for 698 use as the incoming MX host names is the token 'mx' which would 699 normally prefix a number identifying the pool member. The 'mx' token 700 SHOULD be the first characters of the host name, for example: 702 $ORIGIN 0.0.10.IN-ADDR.ARPA. 703 0 IN PTR mx0.example.com. 704 1 IN PTR mx1.example.com. 705 . 706 . 707 254 IN PTR mx254.example.com. 708 255 IN PTR mx255.example.com. 710 7.1.2. Incoming and Outgoing Mail servers 712 Incoming and outgoing mail servers MUST HAVE both a DNS RR of type A 713 and a DNS RR of type PTR, both DNS RRs MUST be complementary. The 714 DNS RRs SHOULD match the host name of the server so that the host 715 name presented by the mail server's response to the HELO or EHLO 716 commands matches the host name in the A and PTR records. 718 Normally servers will not have generic host names when they are both 719 incoming and outgoing servers, however in the event that this 720 configuration is required, the 'mail' token should be used to prefix 721 host name in the PTR record. For example: 723 $ORIGIN 0.0.10.IN-ADDR.ARPA. 724 0 IN PTR mail0.example.com. 725 1 IN PTR mail1.example.com. 726 . 727 . 728 254 IN PTR mail254.example.com. 729 255 IN PTR mail255.example.com. 731 7.1.3. Outgoing Mail servers 733 Outgoing mail servers MUST HAVE both a DNS RR of type A and a DNS RR 734 of type PTR, both DNS RRs MUST be complementary. The DNS RRs SHOULD 735 match the host name of the server so that the host name presented in 736 the mail server's response to the HELO or EHLO commands matches the 737 host name in the A and PTR records. It is often desirable to use a 738 generic name to identify the host without tying public records to 740 RFC DRAFT October 2005 742 specific hardware. Suggested tokens for use as the outgoing mail 743 servers is the token 'mail' or 'smtp' which would normally prefix a 744 number identifying the pool member. The 'mail' or 'smtp' token 745 SHOULD be the first characters of the host name, for example: 747 $ORIGIN 0.0.10.IN-ADDR.ARPA. 748 0 IN PTR mail0.example.com. 749 1 IN PTR mail1.example.com. 750 . 751 . 752 254 IN PTR smtp254.example.com. 753 255 IN PTR smtp255.example.com. 755 7.2. Web Servers 757 Web servers SHOULD be identifiable with DNS RRs of type PTR. For 758 that reason when deploying clusters of web servers for the same 759 sites, they SHOULD be identified with the prefix token of 'www' 760 whenever generic host names are used, for example: 762 $ORIGIN 0.0.10.IN-ADDR.ARPA. 763 0 IN PTR www0.example.com. 764 1 IN PTR www1.example.com. 765 . 766 . 767 254 IN PTR www254.example.com. 768 255 IN PTR www255.example.com. 770 7.3. DNS Servers 772 DNS server SHOULD be identifiable with DNS RRs of type PTR. It is 773 relatively unusual for large clusters of DNS servers to be deployed, 774 further it is not advised to deploy clusters of DNS servers on the 775 same IP ranges except in special configurations. DNS servers are 776 usually identified in NS and A RRs with the 'ns' token prefixed to a 777 numeric value, therefore the same token SHOULD be used for the DNS 778 RRs of type PTR, for example: 780 $ORIGIN 0.0.10.IN-ADDR.ARPA. 781 0 IN PTR ns0.example.com. 782 1 IN PTR ns1.example.com. 783 . 784 . 785 254 IN PTR ns254.example.com. 786 255 IN PTR ns255.example.com. 788 RFC DRAFT October 2005 790 7.4. Core Infrastructure 792 Core infrastructure SHOULD NOT be named in a generic fashion, each 793 name SHOULD be used as a unique identifier for the piece of 794 equipment. The non generic names of the devices does not have to 795 indicate any meaningful information to third parties. Core 796 infrastructure SHOULD use the token 'core' to identify it as a core 797 device, for example: 799 $ORIGIN 0.0.10.IN-ADDR.ARPA. 800 0 IN PTR 801 fastethernet3-1.dkn4-core.canberra.example.com. 802 1 IN PTR gigabitethernet3-0.dkn- 803 core1.canberra.example.com. 804 . 805 . 806 54 IN PTR pos4-1.ken-core4.sydney.example.com. 807 55 IN PTR 808 10gigabitethernet2-2.core02.sydney.example.com. 809 . 810 . 811 254 IN PTR i-2-0.dal-core01.example.com. 812 255 IN PTR i-10-0.chi-core01.example.com. 814 7.5. Multi-Purpose Hosts 816 Multi-purpose servers SHOULD be identifiable with DNS RRs of type 817 PTR. Multi-purpose servers are not servers defined in 6.4. of this 818 document, but are servers where multiple public services are 819 deployed. Where the operator does not wish to identify a local 820 service, for any reason, and chooses to use a generic name for the 821 DNS RRs the server SHOULD be identified by the token 'srv'. For 822 example: 824 $ORIGIN 0.0.10.IN-ADDR.ARPA. 825 0 IN PTR 10.0.0.0.srv.example.com. 826 1 IN PTR 10.0.0.1.srv.example.com. 827 . 828 . 829 254 IN PTR 10.0.0.254.srv.example.com. 830 255 IN PTR 10.0.0.255.srv.example.com. 832 If the 'srv' token is used for dynamically allocated hosts the 'srv' 833 token MUST suffix a 'dyn' token as described in Section 4.2 of this 834 document. 836 RFC DRAFT October 2005 838 8. Language Issues in Naming Schemes 840 The author of this document notes, and acknowledges, that there are 841 some truly beautiful languages around the world, however the naming 842 scheme proposes English tokens as the majority population of the 843 Internet speaks English when communicating with persons of another 844 country, as English is almost a common language. 846 9. Miscellaneous Items with Respect to Naming Schemes 848 The author also notes that the naming scheme proposed is not 849 comprehensive with respect to devices, and suggests that sensible 850 choices should be made when introducing new tokens to your networks. 851 Particular care should be taken with respect to how others may wish 852 to automate access based upon the device type and use, this is 853 particularly important when considering connections to other 854 organisation's mail servers and other public services. 856 Care and consideration should be taken before assigning vendor names 857 to devices, for example when choosing names for devices and questions 858 like; could the device be replaced in the future by another vendors 859 product? 861 When using IP addresses in host names, their numbers SHOULD be 862 separated by '.'s (dots) rather than any meta character such as a '-' 863 (dash) and expressed in decimal. Host names SHOULD NOT use the '_' 864 (underscore) character, host names for hosts with any form of SMTP 865 mail service MUST NOT use the '_' (underscore) character. It is 866 preferable to use the IP address in reverse format in the same way 867 the the IN-ADDR.ARPA. domain is defined. 869 Data repetition MUST be avoided, as MUST redundant (and incorrect) 870 references to the fact that the DNS RR is a PTR, reverse DNS, part of 871 the IN-ADDR.ARPA zone. For example, do not use the tokens 'ptr', 872 'rev', 'in-addr', 'in-addr.arpa' just to indicate the record is 873 within the IN-ADDR.ARPA. domain. Examples of data repetitions would 874 be: 10gigabitethernet2-2.syd-core02.sydney.example.com ('syd' makes 875 'sydney' redundant). 877 Where Location specific data and tokens describe in Sections 4 and 6 878 are used the location data MUST prefix the tokens from Sections 4 879 and/or 6, for example: 881 $ORIGIN 0.0.10.IN-ADDR.ARPA. 882 0 IN PTR 10.0.0.0.syd.dyn.example.com. 883 1 IN PTR 10.0.0.1.syd.res.dyn.example.com. 884 . 885 . 887 RFC DRAFT October 2005 889 254 IN PTR 10.0.0.254.ny.bus.sta.example.com. 890 255 IN PTR 10.0.0.255.paris.res.sta.example.com. 892 10. DNS Requirements 894 The DNS service and naming schemes MUST conform to other current RFCs 895 and BCPs. 897 All DNS RRs of type PTR MUST have a corresponding DNS RR of type A. 899 Generic naming schemes across multiple networks SHOULD NOT be used 900 unless the network is dynamically allocated. Generic records SHOULD 901 be used where networks are dynamically allocated. 903 11. Security Considerations 905 This RFC does not define any new services or protocols. The authors 906 of this memo acknowledge that it includes recomendations for the 907 adoption of a publicly accesible naming scheme that provides 908 information about network allocations and for services provided at 909 different network hosts. 911 This information is at least partialy available in many ways such as 912 existing naming schemes, the Internet's routing table and WHOIS (RFC 913 3912) information. Additionally, current network threat models make 914 the scanning of large network allocations a non-issue for an 915 attacker. Further, mail and DNS servers are easily identified by 916 other methods. 918 12. Acknowledgements 920 Steven Champeon 922 Luis Munoz 924 13. References 926 [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC 927 1033, USC/Information Sciences Institute, November 1987. 929 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 930 STD 13, RFC 1034, USC/Information Sciences Institute, 931 November 1987. 933 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 934 Specification", STD 13, RFC 1035, USC/Information Sciences 935 Institute, November 1987. 937 RFC DRAFT October 2005 939 [RFC 1123] Braden, R., "Requirements for Internet Hosts -- 940 Application and Support", STD 3, RFC 1123, IETF, October 941 1989. 943 [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC 944 1178, Integrated Systems Group/NIST, August 1990. 946 [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart, 947 "New DNS RR Definitions", RFC 1183, October 1990. 949 [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction 950 With Widely Deployed DNS Software", RFC 1535, ACES 951 Research Inc., October 1993. 953 [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 954 Miller, "Common DNS Implementation Errors and Suggested 955 Fixes", RFC 1536, USC/Information Sciences Institute, USC, 956 October 1993. 958 [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors", 959 RFC 1537, CWI, October 1993. 961 [RFC 1912] Barr, D., "Common DNS Operational and Configuration 962 Errors", 963 RFC 1912, The Pennsylvania State University, February 1996 965 [RFC 2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 966 AT&T Laboratories, April 2001. 968 [RFC 3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 969 VeriSign, Inc., September 2004. 971 [RFC 4084] Klensin, J., "Terminology for Describing Internet 972 Connectivity", 973 RFC 4084,, May 2005. 975 [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND", 976 Vixie Enterprises, July 1994. 978 Copyright and Disclaimer 980 Copyright (C) The Internet Society (2006). 982 This document is subject to the rights, licenses and restrictions 983 contained in BCP 78, and except as set forth therein, the authors 984 retain all their rights. 986 This document and the information contained herein are provided on an 988 RFC DRAFT October 2005 990 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 991 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 992 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 993 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 994 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 995 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 997 Author's Address: 999 Matthew Sullivan 1000 Spam and Open Relay Blocking System 1001 Po Box 5150 1002 Bruce, ACT 2617 1003 Australia 1005 Email: matthew@sorbs.net 1007 Luis Munoz 1008 Av. Libertador 1009 Centro Nacional de Telecomunicaciones 1010 Edif. NEA, Piso 14 1011 Caracas - Venezuela, 1010 1013 Email: lem@sorbs.net