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]