draft-ietf-dnsop-dontpublish-unreachable-00.txt   draft-ietf-dnsop-dontpublish-unreachable-01.txt 
Internet Draft Philip Hazel Internet Draft Philip Hazel
draft-ietf-dnsop-dontpublish-unreachable-00.txt University of Cambridge draft-ietf-dnsop-dontpublish-unreachable-01.txt University of Cambridge
Valid for six months September 2001 Valid for six months September 2001
Category: Best Current Practice Category: Best Current Practice
IP Addresses that should never appear in the public DNS IP Addresses that should never appear in the public DNS
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at line 34 skipping to change at line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies an Internet Best Current Practice for the This document specifies an Internet Best Current Practice for the
Internet Community. It prohibits the appearance of private IP Internet Community. It has two themes. Firstly, it reinforces the
addresses in publicly visible DNS records. It also prohibits the prohibition in [RFC 1918] about the appearance of private IP
appearance of public addresses, or indirect references to them, when addresses in publicly visible DNS records. Secondly, the document
the service implied by the address or reference is inaccessible from discusses the problems that can be caused by the appearance of public
the public Internet. Specifying the second prohibition is more addresses, or indirect references to them, when the service implied
difficult because inaccessibility may arise from many causes, some by the address or reference is inaccessible from the public Internet.
possibly legitimate. Specifying a blanket prohibition in the second case is difficult
because inaccessibility may arise from many causes, some possibly
legitimate. Instead, the document points out some of the problems
that can arise, and suggests that other means of achieving the
desired effects should be used wherever possible.
1. Introduction 1. Introduction
The increasing use of firewalls, NAT boxes, and similar technology The increasing use of firewalls, NAT boxes, and similar technology
has resulted in the fragmentation of the Internet into regions whose has resulted in the fragmentation of the Internet into regions whose
boundaries do not allow general connectivity. There are two primary boundaries do not allow general connectivity. There are two primary
reasons for this: reasons for this:
(1) The perceived shortage of IPv4 addresses has caused increasing (1) The perceived shortage of IPv4 addresses has caused increasing
use of private IP network addresses such as 10.0.0.0/8 on LANs. A use of private IP network addresses such as 10.0.0.0/8 on LANs. A
number of private address ranges are designated in [RFC 1918]. Hosts number of such private address ranges are designated in [RFC 1918],
using private addresses that wish to communicate with the public and others may be also assigned by IANA.
Internet must do so via an address translation mechanism such as a
NAT box. This allows a host with a private address to send packets to [Note: For example, there's 169.254/16, which is mentioned in
public Internet hosts, and to receive replies. However, unsolicited draft-ietf-zeroconf-ipv4-linklocal-04.txt, but since that's still a
incoming packets cannot reach these hosts from outside their own draft, I can't cite it.]
private network.
Hosts using private addresses that wish to communicate with the
public Internet must do so via an address translation mechanism such
as a NAT box. This allows a host with a private address to send
packets to public Internet hosts, and to receive replies. However,
unsolicited incoming packets cannot reach these hosts from outside
their own private network.
(2) Increasing security concerns have caused many sites to install (2) Increasing security concerns have caused many sites to install
firewalls or to implement restrictions in their boundary routers in firewalls or to implement restrictions in their boundary routers in
order to lock out certain kinds of connection to their hosts, even order to lock out certain kinds of connection to their hosts, even
when the hosts are using public Internet addresses, though in many when the hosts are using public Internet addresses, though in many
cases firewalls also provide NAT functionality. cases firewalls also provide NAT functionality.
Thus, there are two classes of host which some or all types of Thus, there are two classes of host which some or all types of
unexpected incoming packet from the public Internet cannot reach. unexpected incoming packet from the public Internet cannot reach.
A number of instances have been observed where IP addresses that are A number of instances have been observed where IP addresses that are
not accessible from the public Internet have nevertheless been never accessible from the public Internet have nevertheless been
inserted into resource records in the public DNS. This document seeks inserted into resource records in the public DNS. This document seeks
to prohibit such behaviour. to prohibit such behaviour in the case of truly private addresses,
and to discourage it in the case of public, but unreachable,
addresses.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
The phrase "address record" means an A record or an AAAA record, or The phrase "address record" means an A record or an AAAA record, or
any other kind of name-to-address record that may come into use. any other kind of name-to-address record that may come into use.
2. Private network addresses 2. Private network addresses
skipping to change at line 96 skipping to change at line 108
Because private addresses have no global meaning, routing Because private addresses have no global meaning, routing
information about private networks shall not be propagated on information about private networks shall not be propagated on
inter-enterprise links, and packets with private source or inter-enterprise links, and packets with private source or
destination addresses should not be forwarded across such links. destination addresses should not be forwarded across such links.
Routers in networks not using private address space, especially Routers in networks not using private address space, especially
those of Internet service providers, are expected to be those of Internet service providers, are expected to be
configured to reject (filter out) routing information about configured to reject (filter out) routing information about
private networks. private networks.
In section 5 of [RFC 1918] there is already a prohibition of the
appearance of private addresses in publicly visible DNS records.
However, the wording is merely "should not". This document makes a
stronger statement:
Public DNS zones MUST NOT contain [RFC 1918] private addresses in
any resource records.
Because the same private addresses are in use in many different Because the same private addresses are in use in many different
organizations, they are ambiguous. The appearance of private organizations, they are ambiguous. The appearance of private
addresses in the DNS could therefore lead to unpredictable and addresses in the DNS could therefore lead to unpredictable and
unwanted behaviour. unwanted behaviour. Consider this set of entries:
3. Public network addresses that are blocked @ IN MX 10 smtp
smtp IN A 10.1.2.3
smtp IN A 1.2.3.4
The situation with public network addresses is more complicated. Zones set up in this way have been seen, and some administrators
For example, a host with a public address that is behind a firewall apparently believe this is useful, because it allows mail on their
local network to be delivered straight to the internal server (the
one with address 10.1.2.3). However, it all breaks down when a host
on a foreign network that is also using the address 10.1.2.3
attempts to send mail to the domain.
In section 5 of [RFC 1918] there is a prohibition of the appearance of
private addresses in publicly visible DNS records. It says:
If an enterprise uses the private address space, or a mix of
private and public address spaces, then DNS clients outside of
the enterprise should not see addresses in the private address
space used by the enterprise, since these addresses would be
ambiguous.
The wording "should not" is not a very strong prohibition,
considering the interworking problems that ignoring it can cause.
Therefore, this document makes a stronger statement:
Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other
addresses designated by IANA as private, in any resource records.
3. Public network addresses that are inacessible
The situation with public network addresses is more complicated
because the Internet cannot in general be cleanly divided into
"public" and "private" parts in this case. Examples of situations
where the division is fuzzy are:
(1) A host with a public address that is behind a firewall
may be accessible for SSH sessions, but not for SMTP sessions. That may be accessible for SSH sessions, but not for SMTP sessions. That
is, the blocking may apply only to certain ports. A publicly visible is, the blocking may apply only to certain ports.
address record is therefore required to give access to those ports
that are accessible, and there can be no blanket prohibition. (2) A host with a public address may make certain services available
only to specific client hosts, for example, those in partner
enterprises.
(3) A host might respond to incoming packets only if the client host
is using IPsec.
When a host is providing any service at all over the public Internet,
a publicly visible address record is of course required to give
access to the host.
However, for some protocols and services, additional DNS records However, for some protocols and services, additional DNS records
are defined that reference hosts' address records. These are the MX are defined that reference hosts' address records. These are the MX
record for SMTP, and the SRV record for other services. The existence record for SMTP, and the SRV record for other services. The existence
of such indirect records advertises the availability of the relevant of such indirect records advertises the availability of the relevant
service. service.
Public DNS zones MUST NOT contain MX or SRV records that point to If these services are always inaccessible over the public Internet,
hosts for which the relevant services are not accessible from the it is bad practice to include the MX or SRV records in public DNS
public Internet. In other words, if a DNS resource record that zones, for the following reason:
yields an IP address is visible to some part of the Internet, the
IP address yielded must be reachable by the protocol(s) implied by
the resource record type from the parts of the Internet where the
record is visible.
4. Why publishing public but unreachable addresses is bad
A host that tries to connect to an unreachable address (or port) A host that tries to connect to an unreachable address (or port)
may not receive an immediate rejection; in many cases the connection may not receive an immediate rejection; in many cases the connection
will only fail after a timeout expires. The wasted effort ties up will fail only after a timeout expires. The wasted effort ties up
resources on the calling host and the network, possibly for some resources on the calling host and the network, possibly for some
considerable time (SMTP timeouts are of the order of minutes). considerable time (SMTP timeouts, for example, are of the order of
It also causes a gratuitous slowing down of the application. minutes). It may also cause a gratuitous slowing down of the
application.
Furthermore, in the case of dial-up, ISDN, or other kinds of Furthermore, in the case of dial-up connections, ISDN, or other kinds
usage-based charged network connection, the wasted network resources of usage-based charged network connection, the wasted network
may cost real money. resources may cost real money.
5. Loopback addresses Public DNS zones SHOULD NOT contain MX or SRV records that point to
hosts for which the relevant services are never accessible over the
public Internet. In other words, if there is no host that is able to
make use of the service using the public Internet, the service SHOULD
NOT be publicly advertised.
4. Loopback addresses
The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are
another form of private address. There has been a practice of including another form of private address. There has been a practice of including
them in DNS zones for two entirely different reasons. them in DNS zones for two entirely different reasons.
5.1 The name "localhost" 4.1 The name "localhost"
Some hostmasters include records of this type in their zones: Some hostmasters include records of this type in their zones:
localhost.some.domain.example. A 127.0.0.1 localhost.some.domain.example. A 127.0.0.1
The reason for doing this is so that other hosts in the domain The reason for doing this is so that other hosts in the domain
that use the DNS for all their name resolution can make use of the that use the DNS for all their name resolution can make use of the
unqualified name "localhost". This works because DNS resolvers unqualified name "localhost". This works because DNS resolvers
normally add the local enclosing domain to unqualified names. normally add the local enclosing domain to unqualified names.
DNS zones MAY make use of this technique for the name "localhost" DNS zones MAY make use of this technique for the name "localhost"
only, if it is required in their environment, but SHOULD avoid it only, if it is required in their environment, but SHOULD avoid it
if possible. if possible.
5.3 DNS "black lists" 4.2 DNS "black lists"
There is an increasingly popular practice of creating "black There is an increasingly popular practice of creating "black
lists" of misbehaving hosts (for example, open mail relays) in lists" of misbehaving hosts (for example, open mail relays) in
the DNS. The first of these was the "Realtime Blackhole List" the DNS. The first of these was the "Realtime Blackhole List"
(RBL). Such lists make use of addresses in the 127.0.0.0/8 (RBL). Such lists make use of addresses in the 127.0.0.0/8
network in DNS address records to give information about listed network in DNS address records to give information about listed
hosts (which are looked up via their inverted IP addresses). hosts (which are looked up via their inverted IP addresses).
Such records are in specific "black list" domains, and are well Such records are in specific "black list" domains, and are well
understood not to be invitations to attempt connections to the understood not to be invitations to attempt connections to the
addresses they publish. addresses they publish.
Hostmasters MAY continue to make use of this technique. DNS zones MAY continue to make use of this technique.
5.4 Other uses of loopback networks 4.3 Other uses of loopback networks
Apart from the exceptions mentioned in 5.2 and 5.3, the loopback Apart from the exceptions mentioned in 4.1 and 4.2 above, the
addresses MUST NOT appear in address records in the public DNS. loopback addresses MUST NOT appear in address records in the public
DNS.
5.5 References to loopback addresses 4.4 References to loopback addresses
When address records that contain loopback addresses do exist, When address records that contain loopback addresses do exist,
hostmasters MUST NOT create indirect records (MX or SRV) that DNS zones MUST NOT contain indirect records (MX or SRV) that
reference them. reference them.
6. Alternative techniques 5. Alternative techniques
6.1 Splitting DNS zones 5.1 Splitting DNS zones
A site that is using private addresses may well want to use DNS A site that is using private addresses may well want to use DNS
lookups for address resolution on its hosts. The lazy way approach is lookups for address resolution on its hosts. The lazy way approach is
simply to put the data into the public DNS zone. Because this can simply to put the data into the public DNS zone, as in the example
cause problems for external hosts, this MUST NOT be done. shown in section 2 above. Because this can cause problems for
external hosts, this MUST NOT be done.
One approach that is commonly taken is to run a so-called "split One approach that is commonly taken is to run a so-called "split
DNS". Two different authoritative servers are created: one containing DNS". Two different authoritative servers are created: one containing
all the zone data is accessible only from within the private network. all the zone data is accessible only from within the private network.
External DNS queries are directed to the second server, which External DNS queries are directed to the second server, which
contains a filtered version of the zone, without the private contains a filtered version of the zone, without the private
addresses. addresses.
6.2 SMTP servers behind firewalls 5.2 SMTP servers behind firewalls
The complication of a split DNS is not normally needed if it is only The complication of a split DNS is not normally needed if it is only
SMTP traffic that is being blocked to a public address on a host SMTP traffic that is being blocked to a public address on a host
behind a firewall. Public MX records must always point to publicly behind a firewall. Setting up MX records like this:
accessible hosts. Setting up MX records like this:
plc.example. MX 5 mail.plc.example. plc.example. MX 5 mail.plc.example.
MX 10 public.plc.example. MX 10 public.plc.example.
where both hosts have public IP addresses, but the first is blocked where both hosts have public IP addresses, but the first is blocked
at the firewall, MUST NOT be done. Only the publicly accessible host at the firewall, SHOULD NOT be done. Only the publicly accessible
must be used: host should be used:
plc.example. MX 10 public.plc.example. plc.example. MX 10 public.plc.example.
If a split DNS is in use, the host public.plc.example can use the If a split DNS is in use, the host public.plc.example can use the
internal version to route the mail onwards. However, most MTAs have internal version to route the mail onwards. However, most MTAs have
configuration facilities to allow for explicit routing of mail, without configuration facilities to allow for explicit routing of mail, without
the use of the DNS. the need to use a DNS lookup.
6.3 Specification of no SMTP service 5.3 Specification of no SMTP service
MX records that point to host names whose address records specify the MX records that point to host names whose address records specify the
loopback address have been seen in the DNS. This seems to be a loopback address have been seen in the DNS. This seems to be a
misguided attempt to specify "no SMTP service for this domain". misguided attempt to specify "no SMTP service for this domain".
If such a facility is required, it should instead be done by If such a facility is required, it SHOULD instead be done by
arranging for the hosts in question to return arranging for the hosts in question to return
554 No SMTP service here 554 No SMTP service here
to all SMTP connections. to all SMTP connections.
7. Security Considerations 6. Security Considerations
This document is not known to create new security issues in the DNS, This document is not known to create new security issues in the DNS,
mail agents, etc. In some sense, it may reduce security exposure by mail agents, etc. In some sense, it may reduce security exposure by
insisting that a site's inappropriate internal data not be exposed. insisting that a site's inappropriate internal data not be exposed.
8. IANA Considerations 7. IANA Considerations
No IANA actions are required by this document. No IANA actions are required by this document.
9. Acknowledgements 8. Acknowledgements
Randy Bush read an early draft of this document and suggested several Randy Bush read an early draft of this document and suggested several
improvements. improvements.
10. Author's Address Draft 01 has benefitted from comments made by Daniel Senie, John
Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire.
9. Author's Address
Philip Hazel Philip Hazel
University of Cambridge Computing Service University of Cambridge Computing Service
New Museums Site, Pembroke Street New Museums Site, Pembroke Street
Cambridge CB2 3QG, England Cambridge CB2 3QH, England
Phone: + 44 1223 334714 Phone: + 44 1223 334714
Email: ph10@cam.ac.uk Email: ph10@cam.ac.uk
11. References 10. References
[RFC 1918] Rekhter, Y. et al "Address allocation for Private [RFC 1918] Rekhter, Y. et al "Address allocation for Private
Internets", BCP 5, RFC 1918, February 1996. Internets", BCP 5, RFC 1918, February 1996.
[RFC 2119] Bradner, S."Key words for use in RFCs to Indicate [RFC 2119] Bradner, S."Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11. Changes made during development of this document
This section is provided for the convenients of those tracking the
document. It will be removed from the final draft.
11.1 Changes made to the -00 version
. While leaving the MUSTs in for truly private addresses, I've tried
to be more "educational" about the case of public addresses that are
inaccessible, and backed down to SHOULD in those cases.
. I've pointed out the lack of a clear-cut public/private boundary,
and tried to make the case for not advertising unavailable services
without being so probititive in the wording. This includes using
"never accessible" instead of "not accessible".
. Changed "hostmaster" to "zone" in a couple of cases.
. Included an example of bad MX practice with an [RFC 1918] address.
. Noted that [RFC 1918] is not the only list of private addresses.
. General tidying of the wording and rearrangement of the material.
. The Post Office changed our postcode!
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/