[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Domain Name Working Group                               Matthew Sullivan
Request for Comments: DRAFT          Spam and Open Relay Blocking System
                                                              Luis Munoz
                                                                   CANTV
Expires: October 2006                                         April 2006
Document: draft-msullivan-dnsop-generic-naming-schemes-00.txt


                  Suggested Generic DNS Naming Schemes
                for Large Networks and Unassigned hosts.


Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This memo describes basic DNS configurations and details suggestions
   for a common naming scheme for records that are automatically
   generated and therefore likely generic in nature.  This memo will re-
   iterate issues highlighted in a number of other RFCs such as RFC
   1912.





M. Sullivan                                                     [Page 1]

RFC DRAFT                                                   October 2005


Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

TABLE OF CONTENTS

      MEMO STATUS ..................................................  1

      ABSTRACT .....................................................  1

      NOTATION .....................................................  2

      TABLE OF CONTENTS ............................................  2

  1.  INTRODUCTION .................................................  2

  2.  BACKGROUND   .................................................  3

  3.  GENERIC RECORDS ..............................................  4

  4. Allocation Type Assignment Indicators .........................  5
    4.1.  Static address ranges ....................................  5
    4.2.  Dynamic Address Ranges ...................................  6
    4.3.  Unassigned Address Ranges ................................  7

  5. Transport Type Assignment Indicators ..........................  7
    5.1.  DSL link transport indicators ............................  8
    5.2.  Dial-Up transport indicators .............................  8
    5.3.  Cable modem terminated link indicators ...................  9
    5.4.  Mobile device (GPRS, WiFi etc) ...........................  9
    5.5.  Address ranges assigned to multi purpose links ........... 10
    5.6.  Address ranges assigned to leased lines and ATM links .... 11

  6. Customer Type Assignment Indicators ........................... 12
    6.1.  Address ranges assigned to business customers ............ 12
    6.2.  Address ranges assigned to residential customers ......... 12
    6.3.  Address ranges assigned to co-location customers ......... 13
    6.4.  Address ranges assigned to shared server customers ....... 13

  7. Server/Machine Type Assignment Indicators ..................... 14
    7.1.  Address ranges assigned to mail servers .................. 14
      7.1.1.  Assignments for incoming mail servers ................ 14
      7.1.2.  Assignments for incoming and outgoing mail servers ... 15
      7.1.3.  Assignments for outgoing mail servers ................ 15
    7.2.  Address ranges assigned for web servers .................. 16
    7.3.  Address ranges assigned for DNS servers .................. 16



M. Sullivan                                                     [Page 2]

RFC DRAFT                                                   October 2005


    7.4.  Address ranges assigned for core infrastructure .......... 17
    7.5.  Address ranges assigned for multi-purpose hosts .......... 17

  8.  Language Issues in Naming Schemes ............................ 18

  9.  Miscellaneous Items with Respect to Naming Schemes ........... 18

 10.  DNS Requirements ............................................. 19

 11.  Security Considerations ...................................... 19

 12.  Acknowledgements ............................................. 19

 13.  References ................................................... 19

      Copyright and Disclaimer ..................................... 20

      Author's Address ............................................. 21


1. Introduction

   All Internet connected hosts should have a host name which will
   identify its IP address as well as an entry in the IN-ADDR.ARPA.
   domain indicating its host name.

   For large IP address lists it can be impractical to give each host
   and individual host name and record that host name for both A DNS RRs
   and PTR DNS RRs.  To make the task of providing individual records
   for net blocks simpler, various facilities are available to generate
   zone files.  Large zone files can be very impractical to manipulate
   so some DNS servers allow for a keyword to format and generate mass
   zone data internally within the running server.

   Unfortunately, the use of these generated records has resulted in a
   significant difficulty for remote networks to identify the
   perpetrators of varying forms of network abuse.

   This memo will not provide syntactical detail of the commands or
   scripts used.  It will however, suggest a common naming scheme for
   use in automatically generated zones where zones cannot be crafted
   with the actual host names of the machines.

2. Background

   The need for a common format is becoming more and more apparent in
   the fight against abuse.  The abuse across the Internet began in the
   early days of the Network and took many forms, from hacking and



M. Sullivan                                                     [Page 3]

RFC DRAFT                                                   October 2005


   cracking, to abusing open SMTP relays and proxy servers for the
   propagation of spam.

   Those who have taken it upon themselves to attempt to stop this abuse
   of resources, and those who are tasked with investigating the source
   of the abuse, seem to come up against a number of issues relating to
   the identification of the source of the abuse.

   The identification of the source of abuse is a problem for many
   reasons, first the IP address to host mapping often will give no
   indication of the appropriate services the host does provide.  It
   gives no clue as to whether the abuse attempt on one IP address in a
   network followed by a second is the same host attempting the same
   abuse or whether there are multiple hosts involved.  The host mapping
   will often either not exist or, refer to a non-existent host name
   with little or no indication of the person responsible or
   organisation for abuse issues arising from the host.

   Clear identification and records for a host and network would resolve
   most of issues relating to the identification of abusing or abused
   hosts.  Identification that includes reasonable information as to the
   purpose or configuration of the host will also allow other networks
   to configure access, thereby limiting abuse, using these
   identification records.

3. Generic Records

   Generic records are the most basic form of host names and are used in
   large networks where the administrators of those networks have
   classes of hosts all similar in type.  The administrators of the
   records often will not have access to the configuration of the hosts
   as they will typically be 'customer' machines.

   Generic records are typically seen as records configured like the
   following example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.example.com.
          1       IN  PTR    1.0.0.10.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.example.com.
          255     IN  PTR    255.0.0.10.example.com.

   Typically these hosts offer no information about their purpose, nor
   whether they are actually allocated.  For that reason where access is
   restricted in any way it is expected that hosts in this networks will
   be granted no special privilege, and in many cases may be denied



M. Sullivan                                                     [Page 4]

RFC DRAFT                                                   October 2005


   access.

4. Allocation Type Assignment Indicators

   The following sub-sections gives suggested naming schemes for generic
   static, dynamic and unassigned address blocks.  The naming schemes
   are not mandatory, but are strongly recommended for the sake of
   consistency.

   Regardless of the nature of the address block, the names configured
   in the DNS IN-ADDR.ARPA zone SHOULD contain the domain name of the
   organization responsible for the operation of the hosts at its
   rightmost position.

4.1. Static Address Ranges

   In static host allocations, the IP addresses have been assigned to an
   individual host in a persistent matter. This can be by manually
   configuring the host's network interface(s) with a non-volatile
   configuration, or by the use of host configuration protocols such as
   DHCP in a manner that guarentees that the same host will always
   receive the sane IP address.  It should be noted that to be
   considered static the interface MUST be configured to the same
   address every time it is connected to the Internet.

   DNS RRs for statically configured hosts SHOULD echo the fully
   qualified real name(s) of the host.  Where this is not possible and
   subnet delegation, as described in RFC 2317 is not possible generic
   records MUST be used.  To comply with RFC 1912 all PTR DNS RRs MUST
   have corresponding A RRs.  The format of the PTR records SHOULD
   indicate that the hosts are statically allocated their addresses.
   The suggested format for the records is as follows:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.static.example.com.
          1       IN  PTR    1.0.0.10.static.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.static.example.com.
          255     IN  PTR    255.0.0.10.static.example.com.

   Where the DNS resolution provider is concerned with respect to
   resources, and/or the provider is using additional information
   convention, the word 'static' MAY be abbreviated to 'sta', for
   example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.sta.example.com.



M. Sullivan                                                     [Page 5]

RFC DRAFT                                                   October 2005


          1       IN  PTR    1.0.0.10.sta.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.sta.example.com.
          255     IN  PTR    255.0.0.10.sta.example.com.

   The static identifier MUST be presented as the identifier nearest the
   sub domain or domain name where used.

   The static identifier MUST only be used when the organization
   responsible for the operation IN-ADDR.ARPA. zone able to accurately
   map an IP address to the host that this address was assigned to at
   any given date and time.

4.2. Dynamic Address Ranges

   In dynamic host allocations, the hosts addresses are configured at
   runtime and may change at any predetermined interval.  This type of
   allocation is typically acheived by configuring the host's network
   interface(s) through protocols like DHCP.  PPP up links whether dial
   up, PPP over Ethernet or PPP over ATM typically will not know either
   one of the endpoints and MUST be considered as dynamically allocated.

   DNS RRs for dynamically configured hosts SHOULD NOT echo the fully
   qualified real name(s) of the host as the information is likely to
   change without warning.  Generic records MUST be used for dynamically
   allocated networks.  To comply with RFC 1912 all PTR DNS RRs MUST
   have corresponding A RRs.  The format of the PTR records SHOULD
   indicate that the hosts are dynamically allocated their addresses.
   The suggested format for the records is as follows:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.dynamic.example.com.
          1       IN  PTR    1.0.0.10.dynamic.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.dynamic.example.com.
          255     IN  PTR    255.0.0.10.dynamic.example.com.

   Where the DNS resolution provider is concerned with respect to
   resources, and/or the provider is using additional information
   convention, the word 'dynamic' MAY be abbreviated to 'dyn', for
   example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.dyn.example.com.
          1       IN  PTR    1.0.0.10.dyn.example.com.
          .



M. Sullivan                                                     [Page 6]

RFC DRAFT                                                   October 2005


          .
          254     IN  PTR    254.0.0.10.dyn.example.com.
          255     IN  PTR    255.0.0.10.dyn.example.com.

   The dynamic identifier MUST be presented as the identifier nearest
   the sub domain or domain name where used.

4.3. Unassigned Address Ranges

   Unassigned address ranges are where the address range is allocated to
   an organisation and the addresses have no hosts using them, nor are
   any hosts expected to use them in the immediate future.

   Note: Ranges configured for hosts but as yet with no hosts connected
   MUST NOT be considered 'Unassigned'.

   Unassigned ranges MUST be configured for DNS by EITHER having no PTR
   records for the range OR by using the keyword 'unassigned' in host
   names specified in the IN-ADDR.ARPA. domain.  For example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.unassigned.example.com.
          1       IN  PTR    1.0.0.10.unassigned.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.unassigned.example.com.
          255     IN  PTR    255.0.0.10.unassigned.example.com.

   Unlike other types of PTR record it is acceptable though not advised
   to use the same host name in every PTR record, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    unassigned.example.com.
          1       IN  PTR    unassigned.example.com.
          .
          .
          254     IN  PTR    unassigned.example.com.
          255     IN  PTR    unassigned.example.com.


5. Transport Type Assignment Indicators

   The following sub-sections suggest and recommend naming conventions
   for the more common type of transport type indicators.  These are not
   mandatory indicators, however it is recommended that if transport
   type indicators are to be used the following indicators SHOULD be
   used for consistency.




M. Sullivan                                                     [Page 7]

RFC DRAFT                                                   October 2005


   Allocations type assignment indicators [Section 4] MUST be configured
   whenever Transport type indicators are used.

5.1. DSL Transport Indicators

   DSL transport indicators for address ranges are where the address
   range is solely used for DSL end points regardless of static
   assignment or customer type.  DSL transport is identified by the use
   of the 'dsl' indicator in host names specified in the IN-ADDR.ARPA.
   domain.  For example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.dsl.dyn.example.com.
          1       IN  PTR    1.0.0.10.dsl.dyn.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.dsl.sta.example.com.
          255     IN  PTR    255.0.0.10.dsl.sta.example.com.

   Where more specific DSL Transport type indicators are required the
   'dsl' identifier SHOULD be prefixed with a type abbreviation.  Valid
   type abbreviations are as follows:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.adsl.dyn.example.com.
                                        ; ADSL and ADSL2
          1       IN  PTR    0.0.0.10.sdsl.dyn.example.com.
                                        ; Symmetric DSL
          .
          .
          254     IN  PTR    0.0.0.10.shdsl.sta.example.com.
                                        ; Symmetric High speed DSL
          255     IN  PTR    0.0.0.10.a2dsl.sta.example.com.
                                        ; ADSL2


5.2. Dial-Up Transport Indicators

   Dial-Up transport indicators for address ranges are applicable when
   the range is solely used for end points that have to dial access
   numbers via PSTN.

   Dial-up transport is identified by the use of the 'dial' indicator in
   host names specified in the IN-ADDR.ARPA. domain.  For example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.dial.dyn.example.com.
          1       IN  PTR    1.0.0.10.dial.dyn.example.com.



M. Sullivan                                                     [Page 8]

RFC DRAFT                                                   October 2005


          .
          .
          254     IN  PTR    254.0.0.10.dial.sta.example.com.
          255     IN  PTR    255.0.0.10.dial.sta.example.com.

   Where most specific Dial-Up Transport type indicators are required
   the 'dial' identifier SHOULD be replaced with a more specific
   indicator such as:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.isdn.dyn.example.com.
                                        ; ISDN connections
          1       IN  PTR    1.0.0.10.dov.dyn.example.com.
                                        ; Digital Over Voice ISDN
          .
          .
          254     IN  PTR    254.0.0.10.modem.sta.example.com.
                                        ; Standard Analog Modem
          255     IN  PTR    255.0.0.10.modem.dyn.example.com.
                                        ; Standard Analog Modem


5.3. Cable Modem Transport Indicators

   Cable modem transport indicators for address ranges are appropriate
   when the range is solely used for end points that are terminated at
   cable modems.

   Cable transport type is identified by the use of the 'cable'
   indicator in host names specified in the IN-ADDR.ARPA. domain.  For
   example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.cable.dyn.example.com.
          1       IN  PTR    1.0.0.10.cable.dyn.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.cable.sta.example.com.
          255     IN  PTR    255.0.0.10.cable.sta.example.com.


5.4. Mobile Device Indicators

   Mobile device indicators are provided for address ranges where the
   range is used for transport types associated with mobile devices, for
   example, laptop computers with wireless network interfaces, mobile
   phones, etc.  Where the provider does not wish to distinguish the
   type of connected device, the provider SHOULD use the 'wireless'



M. Sullivan                                                     [Page 9]

RFC DRAFT                                                   October 2005


   token, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.wireless.dyn.example.com.
          1       IN  PTR    1.0.0.10.wireless.dyn.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.wireless.sta.example.com.
          255     IN  PTR    255.0.0.10.wireless.sta.example.com.

   For networks where the provider wishes to identify the connecting
   host more accurately, the following tokens SHOULD be used:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.wifi.dyn.example.com. ; WiFi Devices
          1       IN  PTR    0.1.gprs.dyn.example.com. ; GPRS devices
          .
          .
          254     IN  PTR    0.254.cdma.dyn.example.com. ; CDMA devices
          255     IN  PTR    0.255.bt.dyn.example.com.   ; Bluetooth

   This list is expandable and care should be exercised when choosing
   tokens that are not explicitly specified.

5.5. Multi-Purpose Transport Indicators

   Multi-purpose transport indicators are provided for address ranges
   that are used for multiple transport types.  For example, a service
   which provides ADSL connectivity with backup dial up would be better
   identified as a multi type, or by the primary (in this case ADSL)
   indicator.

   Multiple transport type addresses are identified by the use of the
   'multi' indicator in host names specified in the IN-ADDR.ARPA.
   domain.  For example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.multi.dyn.example.com.
          1       IN  PTR    1.0.0.10.multi.dyn.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.multi.sta.example.com.
          255     IN  PTR    255.0.0.10.multi.sta.example.com.








M. Sullivan                                                    [Page 10]

RFC DRAFT                                                   October 2005


5.6. Dedicated links

   ATM and dedicated transport indicators for address ranges are where
   the range is solely used for networks that are connected via ATM,
   leased line or other types of dedicated connection.

   Generally ATM and leased line links SHOULD have host names connected,
   however where generic naming is required the following tokens SHOULD
   be used:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.atm.dyn.example.com. ; ATM
          1       IN  PTR    1.0.0.10.eth.dyn.example.com. ; Ethernet
          2       IN  PTR    2.0.0.10.ll.dyn.example.com.  ; Leased Line
          3       IN  PTR    3.0.0.10.mwv.sta.example.com. ; Microwave
          .
          .
          50      IN  PTR    50.0.0.10.oc3.sta.example.com. ; OC3
          51      IN  PTR    51.0.0.10.e3.sta.example.com.  ; E3
          52      IN  PTR    52.0.0.10.t1.sta.example.com.  ; T1 (etc.)
          .
          .
          253     IN  PTR    253.0.0.10.giga.sta.example.com.  ; Gigabit
          254     IN  PTR    254.0.0.10.fiber.sta.example.com. ; Fiber
          255     IN  PTR    255.0.0.10.laser.sta.example.com. ; LASER

   As the types of transport described in this section are mostly fixed,
   the use of the token 'dedicated' MAY be used where specific typing is
   not desired.

   The 'dedicated' token MUST NOT be used for networks where the
   assignments are dynamic.  The 'dedicated' token can be using in place
   of the 'static' token described in 4.1.

   The 'dedicated' token can be shortened to 'ded' for resource economy.
   For example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0       IN  PTR    0.0.0.10.dedicated.example.com.
          1       IN  PTR    1.0.0.10.dedicated.example.com.
          .
          .
          254     IN  PTR    254.0.0.10.ded.example.com.
          255     IN  PTR    255.0.0.10.ded.example.com.







M. Sullivan                                                    [Page 11]

RFC DRAFT                                                   October 2005


6. Consumer Type Assignment Indicators

   The following sub-sections suggest and recommend naming conventions
   for the more common types of consumer transport type indicators.
   These are not mandatory indicators, however it is recommended that if
   consumer type indicators are to be used the following indicators
   SHOULD be used for consistency.

   Allocations type assignment indicators [Section 4] MUST be configured
   whenever consumer type indicators are used, and the addresses are
   assigned dynamically.

6.1. Business Customers Addresses

   Business consumer indicators for address ranges are where the range
   is solely used for networks that are connected to business customers.

   Generally business consumers SHOULD have host names of machines
   connected, however where generic naming is required the following
   tokens SHOULD be used:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    0.0.0.10.biz.dyn.example.com.
          1        IN  PTR    1.0.0.10.biz.dyn.example.com.
          .
          .
          254      IN  PTR    254.0.0.10.biz.sta.example.com.
          255      IN  PTR    255.0.0.10.biz.sta.example.com.


6.2. Residential Customer Addresses

   Residential consumer indicators for address ranges are where the
   range is solely used for networks that are connected to residential
   customers, including residential networks at educational
   institutions.

   Generally, residential consumers will not have host names of machines
   connected, however the IN-ADDR.ARPA. zone MUST have records
   identifying the connectivity provider.  Generic naming SHOULD use the
   'client' or 'res' token.  For educational institutes it is common to
   use the token 'resnet', this token is also acceptable.

   An allocation type assignment tokens [Section 4] MUST be used with
   the residential customer type indicator, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    0.0.0.10.res.dyn.example.com.



M. Sullivan                                                    [Page 12]

RFC DRAFT                                                   October 2005


          1        IN  PTR    1.0.0.10.client.dyn.example.com.
          .
          .
          254      IN  PTR    254.0.0.10.client.sta.example.com.
          255      IN  PTR    255.0.0.10.res.sta.example.com.


6.3. Co-Location Customers and Address Ranges

   Co-location customers are those providing their own dedicated
   hardware which is located within a providers network.  Co-location
   customers SHOULD have their own records, however where the provider
   decides not to provide specific host name support within the IN-
   ADDR.ARPA. domain the 'colo' assignment token MUST be used.

   An allocations type assignment token [Section 4] is not expected to
   be used for co-location servers when assigned static addresses.  For
   example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    0.0.0.10.colo.example.com.
          1        IN  PTR    1.0.0.10.colo.example.com.
          .
          .
          254      IN  PTR    254.0.0.10.colo.example.com.
          255      IN  PTR    255.0.0.10.colo.example.com.

   In the unusual configuration that co-location ranges are assigned
   dynamically the 'dyn' allocation type token MUST be used.  For
   example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    0.0.0.10.colo.dyn.example.com.
          1        IN  PTR    1.0.0.10.colo.dyn.example.com.
          .
          .
          254      IN  PTR    254.0.0.10.colo.dyn.example.com.
          255      IN  PTR    255.0.0.10.colo.dyn.example.com.


6.4. Shared Server Addresses

   Shared server addresses are used for a providers' address range where
   the servers house multiple consumers and where a single address may
   have a number of customers assigned.  Shared server addresses SHOULD
   have the host name of the machine in the IN-ADDR.ARPA. domain.  Where
   the service provider chooses not to use the host name or customer
   supplied host name of the machine in the IN-ADDR.ARPA. domain,



M. Sullivan                                                    [Page 13]

RFC DRAFT                                                   October 2005


   generic records MUST be used.  A generic record for a shared server
   SHOULD include the 'shared' token, but MAY replace it with a token
   identifying the service provided [See Section 7], for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    0.0.0.10.shared.example.com.
          1        IN  PTR    1.0.0.10.shared.example.com.
          .
          .
          254      IN  PTR    254.0.0.10.shared.example.com.
          255      IN  PTR    255.0.0.10.shared.example.com.

   As with co-location ranges, is it unusual for shared server addresses
   to be assigned dynamically, so the 'dyn' allocation type token MUST
   be used where the addresses are not assigned statically.


7. Server Type Assignment Indicators

   Server type assignment indicators are used where servers are to be
   identified by remote servers and services for a specific type of
   traffic.  Use of these indicators should be used carefully as DNS
   provides the WKS RR type, the assignment indicators should still be
   used in conjunction with the WKS RR type as there is no current
   method to map IP addresses to services.

   Server type indicators should not normally be used in generic records
   as generic records are used where it is impractical to set individual
   customer host names.  Server type indicators for generic records are
   provided for large organisations where there is a large cluster of
   machines with the same purpose.

   Unlike with other generic indicators the server type indicator MUST
   prefix the host name in the DNS RR.

7.1. Mail Server Indicators

   Often in large networks, the purpose of mail servers is not to send
   and receive mail, but send mail or receive mail.  For that reason the
   identifiers have been split into three main tokens, one for general
   mail servers, one for incoming only mail servers and one for outgoing
   only mail servers.

7.1.1. Incoming Mail servers

   Incoming mail servers MUST HAVE both a DNS RR of type A and a DNS RR
   of type PTR, both DNS RRs MUST be complementary.  The DNS RRs SHOULD
   match the host name of the server so that the host name presented in



M. Sullivan                                                    [Page 14]

RFC DRAFT                                                   October 2005


   the mail server's response to the HELO or EHLO commands matches the
   host name in the A and PTR records.  In large networks it is often
   desirable to use a generic name to identify the host without tying
   public records to specific hardware.  This is particularly important
   when using load balancers and similar hardware.  Suggested tokens for
   use as the incoming MX host names is the token 'mx' which would
   normally prefix a number identifying the pool member.  The 'mx' token
   SHOULD be the first characters of the host name, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    mx0.example.com.
          1        IN  PTR    mx1.example.com.
          .
          .
          254      IN  PTR    mx254.example.com.
          255      IN  PTR    mx255.example.com.


7.1.2. Incoming and Outgoing Mail servers

   Incoming and outgoing mail servers MUST HAVE both a DNS RR of type A
   and a DNS RR of type PTR, both DNS RRs MUST be complementary.  The
   DNS RRs SHOULD match the host name of the server so that the host
   name presented by the mail server's response to the HELO or EHLO
   commands matches the host name in the A and PTR records.

   Normally servers will not have generic host names when they are both
   incoming and outgoing servers, however in the event that this
   configuration is required, the 'mail' token should be used to prefix
   host name in the PTR record.  For example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    mail0.example.com.
          1        IN  PTR    mail1.example.com.
          .
          .
          254      IN  PTR    mail254.example.com.
          255      IN  PTR    mail255.example.com.


7.1.3. Outgoing Mail servers

   Outgoing mail servers MUST HAVE both a DNS RR of type A and a DNS RR
   of type PTR, both DNS RRs MUST be complementary.  The DNS RRs SHOULD
   match the host name of the server so that the host name presented in
   the mail server's response to the HELO or EHLO commands matches the
   host name in the A and PTR records.  It is often desirable to use a
   generic name to identify the host without tying public records to



M. Sullivan                                                    [Page 15]

RFC DRAFT                                                   October 2005


   specific hardware.  Suggested tokens for use as the outgoing mail
   servers is the token 'mail' or 'smtp' which would normally prefix a
   number identifying the pool member.  The 'mail' or 'smtp' token
   SHOULD be the first characters of the host name, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    mail0.example.com.
          1        IN  PTR    mail1.example.com.
          .
          .
          254      IN  PTR    smtp254.example.com.
          255      IN  PTR    smtp255.example.com.


7.2. Web Servers

   Web servers SHOULD be identifiable with DNS RRs of type PTR.  For
   that reason when deploying clusters of web servers for the same
   sites, they SHOULD be identified with the prefix token of 'www'
   whenever generic host names are used, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    www0.example.com.
          1        IN  PTR    www1.example.com.
          .
          .
          254      IN  PTR    www254.example.com.
          255      IN  PTR    www255.example.com.


7.3. DNS Servers

   DNS server SHOULD be identifiable with DNS RRs of type PTR.  It is
   relatively unusual for large clusters of DNS servers to be deployed,
   further it is not advised to deploy clusters of DNS servers on the
   same IP ranges except in special configurations.  DNS servers are
   usually identified in NS and A RRs with the 'ns' token prefixed to a
   numeric value, therefore the same token SHOULD be used for the DNS
   RRs of type PTR, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    ns0.example.com.
          1        IN  PTR    ns1.example.com.
          .
          .
          254      IN  PTR    ns254.example.com.
          255      IN  PTR    ns255.example.com.




M. Sullivan                                                    [Page 16]

RFC DRAFT                                                   October 2005


7.4. Core Infrastructure

   Core infrastructure SHOULD NOT be named in a generic fashion, each
   name SHOULD be used as a unique identifier for the piece of
   equipment.  The non generic names of the devices does not have to
   indicate any meaningful information to third parties.  Core
   infrastructure SHOULD use the token 'core' to identify it as a core
   device, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR
        fastethernet3-1.dkn4-core.canberra.example.com.
          1        IN  PTR    gigabitethernet3-0.dkn-
        core1.canberra.example.com.
          .
          .
          54       IN  PTR    pos4-1.ken-core4.sydney.example.com.
          55       IN  PTR
        10gigabitethernet2-2.core02.sydney.example.com.
          .
          .
          254      IN  PTR    i-2-0.dal-core01.example.com.
          255      IN  PTR    i-10-0.chi-core01.example.com.


7.5. Multi-Purpose Hosts

   Multi-purpose servers SHOULD be identifiable with DNS RRs of type
   PTR.  Multi-purpose servers are not servers defined in 6.4. of this
   document, but are servers where multiple public services are
   deployed.  Where the operator does not wish to identify a local
   service, for any reason, and chooses to use a generic name for the
   DNS RRs the server SHOULD be identified by the token 'srv'.  For
   example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    10.0.0.0.srv.example.com.
          1        IN  PTR    10.0.0.1.srv.example.com.
          .
          .
          254      IN  PTR    10.0.0.254.srv.example.com.
          255      IN  PTR    10.0.0.255.srv.example.com.

   If the 'srv' token is used for dynamically allocated hosts the 'srv'
   token MUST suffix a 'dyn' token as described in Section 4.2 of this
   document.





M. Sullivan                                                    [Page 17]

RFC DRAFT                                                   October 2005


8. Language Issues in Naming Schemes

   The author of this document notes, and acknowledges, that there are
   some truly beautiful languages around the world, however the naming
   scheme proposes English tokens as the majority population of the
   Internet speaks English when communicating with persons of another
   country, as English is almost a common language.

9. Miscellaneous Items with Respect to Naming Schemes

   The author also notes that the naming scheme proposed is not
   comprehensive with respect to devices, and suggests that sensible
   choices should be made when introducing new tokens to your networks.
   Particular care should be taken with respect to how others may wish
   to automate access based upon the device type and use, this is
   particularly important when considering connections to other
   organisation's mail servers and other public services.

   Care and consideration should be taken before assigning vendor names
   to devices, for example when choosing names for devices and questions
   like; could the device be replaced in the future by another vendors
   product?

   When using IP addresses in host names, their numbers SHOULD be
   separated by '.'s (dots) rather than any meta character such as a '-'
   (dash) and expressed in decimal.  Host names SHOULD NOT use the '_'
   (underscore) character, host names for hosts with any form of SMTP
   mail service MUST NOT use the '_' (underscore) character.  It is
   preferable to use the IP address in reverse format in the same way
   the the IN-ADDR.ARPA. domain is defined.

   Data repetition MUST be avoided, as MUST redundant (and incorrect)
   references to the fact that the DNS RR is a PTR, reverse DNS, part of
   the IN-ADDR.ARPA zone.  For example, do not use the tokens 'ptr',
   'rev', 'in-addr', 'in-addr.arpa' just to indicate the record is
   within the IN-ADDR.ARPA. domain.  Examples of data repetitions would
   be: 10gigabitethernet2-2.syd-core02.sydney.example.com ('syd' makes
   'sydney' redundant).

   Where Location specific data and tokens describe in Sections 4 and 6
   are used the location data MUST prefix the tokens from Sections 4
   and/or 6, for example:

          $ORIGIN 0.0.10.IN-ADDR.ARPA.
          0        IN  PTR    10.0.0.0.syd.dyn.example.com.
          1        IN  PTR    10.0.0.1.syd.res.dyn.example.com.
          .
          .



M. Sullivan                                                    [Page 18]

RFC DRAFT                                                   October 2005


          254      IN  PTR    10.0.0.254.ny.bus.sta.example.com.
          255      IN  PTR    10.0.0.255.paris.res.sta.example.com.


10. DNS Requirements

   The DNS service and naming schemes MUST conform to other current RFCs
   and BCPs.

   All DNS RRs of type PTR MUST have a corresponding DNS RR of type A.

   Generic naming schemes across multiple networks SHOULD NOT be used
   unless the network is dynamically allocated.  Generic records SHOULD
   be used where networks are dynamically allocated.

11. Security Considerations

   This RFC does not define any new services or protocols. The authors
   of this memo acknowledge that it includes recomendations for the
   adoption of a publicly accesible naming scheme that provides
   information about network allocations and for services provided at
   different network hosts.

   This information is at least partialy available in many ways such as
   existing naming schemes, the Internet's routing table and WHOIS (RFC
   3912) information. Additionally, current network threat models make
   the scanning of large network allocations a non-issue for an
   attacker.  Further, mail and DNS servers are easily identified by
   other methods.

12. Acknowledgements

   Steven Champeon

   Luis Munoz

13. References

   [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
              1033, USC/Information Sciences Institute, November 1987.

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, USC/Information Sciences Institute,
              November 1987.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, USC/Information Sciences
              Institute, November 1987.



M. Sullivan                                                    [Page 19]

RFC DRAFT                                                   October 2005


   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, IETF, October
              1989.

   [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
              1178, Integrated Systems Group/NIST, August 1990.

   [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
              "New DNS RR Definitions", RFC 1183, October 1990.

   [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
              With Widely Deployed DNS Software", RFC 1535, ACES
              Research Inc., October 1993.

   [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
              Miller, "Common DNS Implementation Errors and Suggested
              Fixes", RFC 1536, USC/Information Sciences Institute, USC,
              October 1993.

   [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
              RFC 1537, CWI, October 1993.

   [RFC 1912] Barr, D., "Common DNS Operational and Configuration
   Errors",
              RFC 1912, The Pennsylvania State University, February 1996

   [RFC 2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              AT&T Laboratories, April 2001.

   [RFC 3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
              VeriSign, Inc., September 2004.

   [RFC 4084] Klensin, J., "Terminology for Describing Internet
   Connectivity",
              RFC 4084,, May 2005.

   [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
              Vixie Enterprises, July 1994.

Copyright and Disclaimer

   Copyright (C) The Internet Society (2006).

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

   This document and the information contained herein are provided on an



M. Sullivan                                                    [Page 20]

RFC DRAFT                                                   October 2005


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

Author's  Address:

   Matthew Sullivan
   Spam and Open Relay Blocking System
   Po Box 5150
   Bruce, ACT 2617
   Australia

   Email: matthew@sorbs.net

   Luis Munoz
   Av. Libertador
   Centro Nacional de Telecomunicaciones
   Edif. NEA, Piso 14
   Caracas - Venezuela, 1010

   Email: lem@sorbs.net



























M. Sullivan                                                    [Page 21]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/