draft-ietf-dnsop-dontpublish-unreachable-01.txt   draft-ietf-dnsop-dontpublish-unreachable-02.txt 
Internet Draft Philip Hazel Internet Draft Philip Hazel
draft-ietf-dnsop-dontpublish-unreachable-01.txt University of Cambridge draft-ietf-dnsop-dontpublish-unreachable-02.txt University of Cambridge
Valid for six months September 2001 Valid for six months January 2002
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 (2002). 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
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 115 skipping to change at line 116
configured to reject (filter out) routing information about configured to reject (filter out) routing information about
private networks. private networks.
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. Consider this set of entries: unwanted behaviour. Consider this set of entries:
@ IN MX 10 smtp @ IN MX 10 smtp
smtp IN A 10.1.2.3 smtp IN A 10.1.2.3
smtp IN A 1.2.3.4 smtp IN A 131.111.10.206
Zones set up in this way have been seen, and some administrators The MX record resolves to two IP addresses, one of which is private
apparently believe this is useful, because it allows mail on their and one of which is public. Zones set up in this way have been seen,
local network to be delivered straight to the internal server (the and some administrators apparently believe this is useful, because
one with address 10.1.2.3). However, it all breaks down when a host it allows mail on their local network to be delivered straight to
on a foreign network that is also using the address 10.1.2.3 the internal server (the one with address 10.1.2.3). However, this
attempts to send mail to the domain. approach 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 In section 5 of [RFC 1918] there is a prohibition of the appearance
private addresses in publicly visible DNS records. It says: of private addresses in publicly visible DNS records. It says:
If an enterprise uses the private address space, or a mix of If an enterprise uses the private address space, or a mix of
private and public address spaces, then DNS clients outside of private and public address spaces, then DNS clients outside of
the enterprise should not see addresses in the private address the enterprise should not see addresses in the private address
space used by the enterprise, since these addresses would be space used by the enterprise, since these addresses would be
ambiguous. ambiguous.
The wording "should not" is not a very strong prohibition, The wording "should not" is not a very strong prohibition,
considering the interworking problems that ignoring it can cause. considering the interworking problems that ignoring it can cause.
Therefore, this document makes a stronger statement: Therefore, this document makes a stronger statement:
skipping to change at line 147 skipping to change at line 149
Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other
addresses designated by IANA as private, in any resource records. addresses designated by IANA as private, in any resource records.
3. Public network addresses that are inacessible 3. Public network addresses that are inacessible
The situation with public network addresses is more complicated The situation with public network addresses is more complicated
because the Internet cannot in general be cleanly divided into because the Internet cannot in general be cleanly divided into
"public" and "private" parts in this case. Examples of situations "public" and "private" parts in this case. Examples of situations
where the division is fuzzy are: where the division is fuzzy are:
(1) A host with a public address that is behind a firewall (1) A host with a public address that is behind a firewall may be
may be accessible for SSH sessions, but not for SMTP sessions. That accessible for SSH sessions, but not for SMTP sessions. That is,
is, the blocking may apply only to certain ports. the blocking may apply only to certain ports.
(2) A host with a public address may make certain services available (2) A host with a public address may make certain services available
only to specific client hosts, for example, those in partner only to specific client hosts, for example, those in partner
enterprises. enterprises, or those in a specific geographic area.
(3) A host might respond to incoming packets only if the client host (3) A host might respond to incoming packets only if the client host
is using IPsec. is using IPsec.
When a host is providing any service at all over the public Internet, When a host is providing any service at all over the public Internet,
a publicly visible address record is of course required to give a publicly visible address record is of course required to give
access to the host. access to that 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 NS
record for SMTP, and the SRV record for other services. The existence record for name servers, the MX record for SMTP, and the SRV record
of such indirect records advertises the availability of the relevant for other services. The existence of such indirect records advertises
service. the availability of the relevant service.
If these services are always inaccessible over the public Internet, If these services are always inaccessible over the public Internet,
it is bad practice to include the MX or SRV records in public DNS it is bad practice to include the NS, MX or SRV records in public DNS
zones, for the following reason: zones, for the following reason:
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 fail only 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, for example, are of the order of considerable time (SMTP timeouts, for example, are of the order of
minutes). It may also cause a gratuitous slowing down of the minutes). It may also cause a gratuitous slowing down of the
application. application.
Furthermore, in the case of dial-up connections, ISDN, or other kinds Furthermore, in the case of dial-up connections, ISDN, or other kinds
of usage-based charged network connection, the wasted network of usage-based charged network connection, the wasted network
resources may cost real money. resources may cost real money.
Public DNS zones SHOULD NOT contain MX or SRV records that point to Public DNS zones SHOULD NOT contain NS, MX or SRV records that point
hosts for which the relevant services are never accessible over the 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 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 make use of the service using the public Internet, the service SHOULD
NOT be publicly advertised. NOT be publicly advertised.
4. Loopback addresses 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.
skipping to change at line 235 skipping to change at line 237
4.3 Other uses of loopback networks 4.3 Other uses of loopback networks
Apart from the exceptions mentioned in 4.1 and 4.2 above, the Apart from the exceptions mentioned in 4.1 and 4.2 above, the
loopback addresses MUST NOT appear in address records in the public loopback addresses MUST NOT appear in address records in the public
DNS. DNS.
4.4 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,
DNS zones MUST NOT contain indirect records (MX or SRV) that DNS zones MUST NOT contain indirect records (NS, MX or SRV) that
reference them. reference them.
5. Alternative techniques 5. Alternative techniques
5.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, as in the example simply to put the data into the public DNS zone, as in the example
shown in section 2 above. Because this can cause problems for shown in section 2 above. Because this can cause problems for
skipping to change at line 279 skipping to change at line 281
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 need to use a DNS lookup. the need to use a DNS lookup.
5.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" more
positively than just refusing connections to the SMTP port. (A refused
connection is treated as a temporary error, because it might be the
result of a system rebooting, for example.)
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.
6. Security Considerations 6. Security Considerations
skipping to change at line 306 skipping to change at line 311
No IANA actions are required by this document. No IANA actions are required by this document.
8. 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.
Draft 01 has benefitted from comments made by Daniel Senie, John Draft 01 has benefitted from comments made by Daniel Senie, John
Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire. Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire.
Draft 02 has benefitted from comments made by David Keegel and Simon
Josefsson.
9. Author's Address 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 3QH, England Cambridge CB2 3QH, England
Phone: + 44 1223 334714 Phone: + 44 1223 334714
Email: ph10@cam.ac.uk Email: ph10@cam.ac.uk
skipping to change at line 329 skipping to change at line 337
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 11. Changes made during development of this document
This section is provided for the convenients of those tracking the This section is provided for the convenients of those tracking the
document. It will be removed from the final draft. document. It will be removed from the final draft.
11.1 Changes made to the -00 version 11.1 Changes made to the -00 version to create -01
. While leaving the MUSTs in for truly private addresses, I've tried . While leaving the MUSTs in for truly private addresses, I've tried
to be more "educational" about the case of public addresses that are to be more "educational" about the case of public addresses that are
inaccessible, and backed down to SHOULD in those cases. inaccessible, and backed down to SHOULD in those cases.
. I've pointed out the lack of a clear-cut public/private boundary, . I've pointed out the lack of a clear-cut public/private boundary,
and tried to make the case for not advertising unavailable services and tried to make the case for not advertising unavailable services
without being so probititive in the wording. This includes using without being so probititive in the wording. This includes using
"never accessible" instead of "not accessible". "never accessible" instead of "not accessible".
. Changed "hostmaster" to "zone" in a couple of cases. . Changed "hostmaster" to "zone" in a couple of cases.
. Included an example of bad MX practice with an [RFC 1918] address. . Included an example of bad MX practice with an [RFC 1918] address.
. Noted that [RFC 1918] is not the only list of private addresses. . Noted that [RFC 1918] is not the only list of private addresses.
. General tidying of the wording and rearrangement of the material. . General tidying of the wording and rearrangement of the material.
. The Post Office changed our postcode! . The Post Office changed our postcode!
11.2 Changes made to the -01 version to create -02
. Add NS to MX and SRV as another DNS record that advertises a service
indirectly.
. Changed the address 1.2.3.4 in an example to a genuine real address
to make it quite clear what I mean.
. Added "geographic area" as another example of a service restriction.
. Suggested why people might want something other than "connection
refused" from hosts that don't provide SMTP service.
. Some other very minor rewording.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). 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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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