draft-ietf-dnsop-default-local-zones-03.txt   draft-ietf-dnsop-default-local-zones-04.txt 
Network Working Group M. Andrews Network Working Group M. Andrews
Internet-Draft ISC Internet-Draft ISC
Intended status: Best Current November 19, 2007 Intended status: Best Current December 4, 2007
Practice Practice
Expires: May 22, 2008 Expires: June 6, 2008
Locally-served DNS Zones Locally-served DNS Zones
draft-ietf-dnsop-default-local-zones-03 draft-ietf-dnsop-default-local-zones-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on June 6, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Experience has shown that there are a number of DNS zones all Experience has shown that there are a number of DNS zones all
iterative resolvers and recursive nameservers should, unless iterative resolvers and recursive nameservers should, unless
configured otherwise, automatically serve. RFC 4193 specifies that configured otherwise, automatically serve. RFC 4193 specifies that
skipping to change at page 4, line 50 skipping to change at page 4, line 50
Internet servers. This document recommends that the NS record Internet servers. This document recommends that the NS record
defaults to the name of the zone and the SOA MNAME defaults to the defaults to the name of the zone and the SOA MNAME defaults to the
name of the only NS RR's target. The SOA RNAME should default to name of the only NS RR's target. The SOA RNAME should default to
"nobody.invalid." [RFC 2606]. Implementations SHOULD provide a "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a
mechanism to set these values. No address records need to be mechanism to set these values. No address records need to be
provided for the name server. provided for the name server.
Below is an example of a generic empty zone in master file format. Below is an example of a generic empty zone in master file format.
It will produce a negative cache TTL of 3 hours. It will produce a negative cache TTL of 3 hours.
@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 @ 10800 @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
IN NS @ @ 10800 IN NS @
The SOA RR is needed to support negative caching [RFC 2308] of name The SOA RR is needed to support negative caching [RFC 2308] of name
error responses and to point clients to the primary master for DNS error responses and to point clients to the primary master for DNS
dynamic updates. dynamic updates.
SOA values of particular importance are the MNAME, the SOA RR's TTL SOA values of particular importance are the MNAME, the SOA RR's TTL
and the negTTL value. Both TTL values SHOULD match. The rest of the and the negTTL value. Both TTL values SHOULD match. The rest of the
SOA timer values MAY be chosen arbitrarily since they are not SOA timer values MAY be chosen arbitrarily since they are not
intended to control any zone transfer activity. intended to control any zone transfer activity.
The NS RR is needed as some UPDATE clients use NS queries to discover The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries
the zone to be updated. Having no address records for the name to discover the zone to be updated. Having no address records for
server is expected to abort UPDATE [RFC 2136] processing in the the name server is expected to abort UPDATE processing in the client.
client.
4. Lists Of Zones Covered 4. Lists Of Zones Covered
The following subsections are intended to seed the IANA registry as The following subsections are intended to seed the IANA registry as
requested in the IANA Considerations Section. The zone name is the requested in the IANA Considerations Section. The zone name is the
entity to be registered. entity to be registered.
4.1. RFC 1918 Zones 4.1. RFC 1918 Zones
The following zones correspond to the IPv4 address space reserved in The following zones correspond to the IPv4 address space reserved in
skipping to change at page 6, line 17 skipping to change at page 6, line 17
The following zones correspond to those address ranges from [RFC The following zones correspond to those address ranges from [RFC
3330] that are not expected to appear as source or destination 3330] that are not expected to appear as source or destination
addresses on the public Internet and to not have a unique name to addresses on the public Internet and to not have a unique name to
associate with. associate with.
The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
attempt to discourage any practice to provide a PTR RR for attempt to discourage any practice to provide a PTR RR for
1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse
mapping should exist, but the exact setup is out of the scope of this mapping should exist, but the exact setup is out of the scope of this
document. Similar logic applies to the reverse mapping for ::1 document. Similar logic applies to the reverse mapping for ::1
Section 4.3. The recommendations made here simply assume no other (Section 4.3). The recommendations made here simply assume no other
coverage for these domains exists. coverage for these domains exists.
+------------------------------+------------------------+ +------------------------------+------------------------+
| Zone | Description | | Zone | Description |
+------------------------------+------------------------+ +------------------------------+------------------------+
| 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK | | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
| 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK | | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK |
| 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL | | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
| 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET | | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET |
| 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST | | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
skipping to change at page 7, line 27 skipping to change at page 7, line 27
| Zone | | Zone |
+----------------+ +----------------+
| 8.E.F.IP6.ARPA | | 8.E.F.IP6.ARPA |
| 9.E.F.IP6.ARPA | | 9.E.F.IP6.ARPA |
| A.E.F.IP6.ARPA | | A.E.F.IP6.ARPA |
| B.E.F.IP6.ARPA | | B.E.F.IP6.ARPA |
+----------------+ +----------------+
5. Zones that are Out-Of-Scope 5. Zones that are Out-Of-Scope
IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.57, and IPv6 IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and
Centrally Assigned Local [RFC 4193] addresses are not covered here. IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered
It is expected that IPv6 site-local addresses will be self correcting here. It is expected that IPv6 site-local addresses will be self
as IPv6 implementations remove support for site-local addresses. correcting as IPv6 implementations remove support for site-local
However, sacrificial servers for C.E.F.IP6.ARPA through addresses. However, sacrificial servers for C.E.F.IP6.ARPA through
F.E.F.IP6.ARPA may still need to be deployed in the short term if the F.E.F.IP6.ARPA may still need to be deployed in the short term if the
traffic becomes excessive. traffic becomes excessive.
For IPv6 Centrally Assigned Local addresses (L = 0) [RFC 4193], there For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193],
has been no decision made about whether the Regional Internet there has been no decision made about whether the Regional Internet
Registries (RIRs) will provide delegations in this space or not. If Registries (RIRs) will provide delegations in this space or not. If
they don't, then C.F.IP6.ARPA will need to be added to the list in they don't, then C.F.IP6.ARPA will need to be added to the list in
Section 4.4. If they do, then registries will need to take steps to Section 4.4. If they do, then registries will need to take steps to
ensure that name servers are provided for these addresses. ensure that name servers are provided for these addresses.
This document also ignores IP6.INT. IP6.INT has been wound up with This document also ignores IP6.INT. IP6.INT has been wound up with
only legacy resolvers now generating reverse queries under IP6.INT only legacy resolvers now generating reverse queries under IP6.INT
[RFC 4159]. [RFC 4159].
This document has also deliberately ignored names immediately under This document has also deliberately ignored names immediately under
skipping to change at page 8, line 49 skipping to change at page 8, line 49
This work was supported by the US National Science Foundation This work was supported by the US National Science Foundation
(research grant SCI-0427144) and DNS-OARC. (research grant SCI-0427144) and DNS-OARC.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC 1034] [RFC 1034]
Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, STD 13, November 1987. STD 13, RFC 1034, November 1987.
[RFC 1035] [RFC 1035]
Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC 1035, STD 13, November 1987. SPECIFICATION", STD 13, RFC 1035, November 1987.
[RFC 1918] [RFC 1918]
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC 2119] [RFC 2119]
Bradner, S., "Key words for use in RFCs to Indicate 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.
[RFC 2136] [RFC 2136]
Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
 End of changes. 12 change blocks. 
21 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/