Locally Served DNS Zones
RFC 6303
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
15 | (System) | Notify list changed from dnsop-chairs@ietf.org, draft-ietf-dnsop-default-local-zones@ietf.org to (None) |
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the No Objection position for Ralph Droms |
2011-07-14
|
15 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
2011-07-14
|
15 | Cindy Morgan | [Note]: changed to 'BCP 163 ; RFC 6303' |
2011-07-13
|
15 | (System) | RFC published |
2011-06-21
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-06-21
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2011-06-21
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-06-20
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2011-06-10
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-05-31
|
15 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-05-31
|
15 | (System) | IANA Action state changed to In Progress |
2011-05-31
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-05-31
|
15 | Amy Vezza | IESG has approved the document |
2011-05-31
|
15 | Amy Vezza | Closed "Approve" ballot |
2011-05-31
|
15 | Amy Vezza | Approval announcement text regenerated |
2011-05-31
|
15 | Amy Vezza | Ballot writeup text changed |
2011-05-27
|
15 | Ron Bonica | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
2011-05-13
|
15 | Ralph Droms | [Ballot comment] I've cleared my DISCUSS. Any names from this document that need to be added to the Special Names registry defined in draft-cheshire-dnsext-special-names will … [Ballot comment] I've cleared my DISCUSS. Any names from this document that need to be added to the Special Names registry defined in draft-cheshire-dnsext-special-names will be picked up when that new registry is populated. |
2011-05-13
|
15 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2011-04-28
|
15 | Cindy Morgan | Removed from agenda for telechat |
2011-04-28
|
15 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation. |
2011-04-28
|
15 | Amy Vezza | Ballot writeup text changed |
2011-04-28
|
15 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded |
2011-04-27
|
15 | Ralph Droms | [Ballot discuss] I'd like to discuss whether this document should define the lists of prefix names for inclusion in the IANA registry for special use … [Ballot discuss] I'd like to discuss whether this document should define the lists of prefix names for inclusion in the IANA registry for special use names defined in draft-cheshire-dnsext-special-names. |
2011-04-27
|
15 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded |
2011-04-27
|
15 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
15 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
15 | Sean Turner | [Ballot comment] wordsmithing here: Sec 3: use 2219 language in the following?: OLD: This document recommends that the NS record defaults to the … [Ballot comment] wordsmithing here: Sec 3: use 2219 language in the following?: OLD: This document recommends that the NS record defaults to the name of the zone and the SOA MNAME defaults to the name of the only NS RR's target. NEW: It is RECOMMENDED that the NS record defaults to the name of the zone and the SOA MNAME defaults to the name of the only NS RR's target. |
2011-04-27
|
15 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
15 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26
|
15 | Adrian Farrel | [Ballot comment] Will it be clear to IANA exactly what they have to do in order to satisfy the following text from Section 6? … [Ballot comment] Will it be clear to IANA exactly what they have to do in order to satisfy the following text from Section 6? IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is deployed in the reverse tree, delegations for these zones are made in the manner described in Section 7. |
2011-04-26
|
15 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26
|
15 | Pete Resnick | [Ballot comment] I don't understand why this is not standards track. It might not be likely that implementation experience will change this spec, but it's … [Ballot comment] I don't understand why this is not standards track. It might not be likely that implementation experience will change this spec, but it's certainly possible. |
2011-04-26
|
15 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26
|
15 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26
|
15 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26
|
15 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-25
|
15 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-25
|
15 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
2011-04-25
|
15 | Ron Bonica | Ballot has been issued |
2011-04-25
|
15 | Ron Bonica | Created "Approve" ballot |
2011-04-25
|
15 | Ron Bonica | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-04-25
|
15 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-04-22
|
15 | Amanda Baber | IANA understands that there are three IANA Actions that are required upon approval of this document. First, a new registry will be created called the … IANA understands that there are three IANA Actions that are required upon approval of this document. First, a new registry will be created called the "Locally Served DNS Zone Registry" This registry will be linked on the IANA Matrix with [ RFC-to-be ] as the reference. The new registry will be managed and maintained through "IETF Review" as per RFC5226. The initial contents of the new registry is described in the next step. Second, the new registry created above will have two subregistries: one for the IPv4 local zones and the other for IPv6 local zones. In both cases the reference will be [ RFC-to-be ] and the registration rules will be "IETF Review." IANA will note on the registry that once a zone is added to one of these subregistries, it is effectively added permanently; once an address range starts being configured as a local zone in systems on the Internet, it will be impossible to reverse those changes. The initial contents for the IPv4 Locally Served DNS Zone Registry will be: +------------------------------+------------------------+ | Zone | Description | +------------------------------+------------------------+ | 10.IN-ADDR.ARPA | RFC1918 Zone | | 16.172.IN-ADDR.ARPA | RFC1918 Zone | | 17.172.IN-ADDR.ARPA | RFC1918 Zone | | 18.172.IN-ADDR.ARPA | RFC1918 Zone | | 19.172.IN-ADDR.ARPA | RFC1918 Zone | | 20.172.IN-ADDR.ARPA | RFC1918 Zone | | 21.172.IN-ADDR.ARPA | RFC1918 Zone | | 22.172.IN-ADDR.ARPA | RFC1918 Zone | | 23.172.IN-ADDR.ARPA | RFC1918 Zone | | 24.172.IN-ADDR.ARPA | RFC1918 Zone | | 25.172.IN-ADDR.ARPA | RFC1918 Zone | | 26.172.IN-ADDR.ARPA | RFC1918 Zone | | 27.172.IN-ADDR.ARPA | RFC1918 Zone | | 28.172.IN-ADDR.ARPA | RFC1918 Zone | | 29.172.IN-ADDR.ARPA | RFC1918 Zone | | 30.172.IN-ADDR.ARPA | RFC1918 Zone | | 31.172.IN-ADDR.ARPA | RFC1918 Zone | | 168.192.IN-ADDR.ARPA | RFC1918 Zone | | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK | | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK | | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL | | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET 1 | | 100.51.198.IN-ADDR.ARPA | IPv4 TEST NET 2 | | 113.0.203.IN-ADDR.ARPA | IPv4 TEST NET 3 | | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST | +------------------------------+------------------------+ The initial contents for the IPv6 Locally Served DNS Zone Registry will be: +-------------------------------------------------------------------------+ | Zone | Description | +-------------------------------------------+-----------------------------+ | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | IPv6 Unspecified Address | | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | | | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | IPv6 Loopback Address | | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | | | D.F.IP6.ARPA | IPv6 Locally Assigned Local | | | Address | | 8.E.F.IP6.ARPA | IPv6 Link Local Address | | 9.E.F.IP6.ARPA | IPv6 Link Local Address | | A.E.F.IP6.ARPA | IPv6 Link Local Address | | B.E.F.IP6.ARPA | IPv6 Link Local Address | | 8.B.D.0.1.0.0.2.IP6.ARPA | IPv6 Example Prefix | +-------------------------------------------+-----------------------------+ Third, IANA will work with the appropriate RIRs to ensure that, as DNSSEC is deployed in the reverse tree, delegations for these zones are made in the manner described in the Security Considerations section of the approved document. IANA understands that these are the only actions required upon approval of this document. |
2011-04-14
|
15 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Julien Laganier |
2011-04-14
|
15 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Julien Laganier |
2011-04-11
|
15 | Amy Vezza | Last call sent |
2011-04-11
|
15 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Locally-served DNS Zones) to BCP The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Locally-served DNS Zones' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsop-default-local-zones/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsop-default-local-zones/ |
2011-04-11
|
15 | Ron Bonica | Placed on agenda for telechat - 2011-04-28 by Ron Bonica |
2011-04-11
|
15 | Ron Bonica | [Note]: 'Peter Koch (pk@ISOC.DE) is the document shepherd.' added by Ron Bonica |
2011-04-11
|
15 | Ron Bonica | Last Call was requested |
2011-04-11
|
15 | Ron Bonica | State changed to Last Call Requested from Publication Requested. |
2011-04-11
|
15 | Ron Bonica | Last Call text changed |
2011-04-11
|
15 | (System) | Ballot writeup text was added |
2011-04-11
|
15 | (System) | Last call text was added |
2011-04-11
|
15 | (System) | Ballot approval text was added |
2011-04-04
|
15 | Ron Bonica | Ballot writeup text changed |
2011-04-04
|
15 | Ron Bonica | Ballot writeup text changed |
2011-04-01
|
15 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Peter Koch is the document shepherd and believes that this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by a number of WG members who have expressed explicit support for the document. There are no concerns as to the depth or breadth of reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Many members of the DNS operational community have supported this approach, including operators of the infrastructure (AS112, IN-ADDR.ARPA) that is currently affected by the query leakage to be addressed by this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The nits checker warns about one IP addresses appearing literally. Since it is not meant as an example and is rightfully mentioned in the document, this warning can be ignored. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. There are references to two other documents that are being submitted to the IESG at the same time (draft-ietf-dnsop-as112-help-help and draft-ietf-dnsop-as112-ops). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This document defines an IANA registry for "locally served zones". It specifies the registration policy and the seed values. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group strong but not unanimous consensus. Discussion arose around how exactly to seed the IANA registry that defines the list of zones to locally serve. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are name server implementations that already use the feature described in this document. |
2011-04-01
|
15 | Cindy Morgan | Draft added in state Publication Requested |
2011-04-01
|
15 | Cindy Morgan | [Note]: 'Peter Koch (pk@ISOC.DE) is the document shepherd.' added |
2011-03-14
|
15 | (System) | New version available: draft-ietf-dnsop-default-local-zones-15.txt |
2010-09-21
|
14 | (System) | New version available: draft-ietf-dnsop-default-local-zones-14.txt |
2010-04-30
|
13 | (System) | New version available: draft-ietf-dnsop-default-local-zones-13.txt |
2010-04-08
|
12 | (System) | New version available: draft-ietf-dnsop-default-local-zones-12.txt |
2010-04-01
|
11 | (System) | New version available: draft-ietf-dnsop-default-local-zones-11.txt |
2010-03-25
|
10 | (System) | New version available: draft-ietf-dnsop-default-local-zones-10.txt |
2009-11-19
|
09 | (System) | New version available: draft-ietf-dnsop-default-local-zones-09.txt |
2009-08-30
|
15 | (System) | Document has expired |
2009-02-27
|
08 | (System) | New version available: draft-ietf-dnsop-default-local-zones-08.txt |
2009-02-25
|
07 | (System) | New version available: draft-ietf-dnsop-default-local-zones-07.txt |
2008-07-11
|
06 | (System) | New version available: draft-ietf-dnsop-default-local-zones-06.txt |
2008-06-05
|
05 | (System) | New version available: draft-ietf-dnsop-default-local-zones-05.txt |
2007-12-03
|
04 | (System) | New version available: draft-ietf-dnsop-default-local-zones-04.txt |
2007-11-18
|
03 | (System) | New version available: draft-ietf-dnsop-default-local-zones-03.txt |
2007-06-08
|
02 | (System) | New version available: draft-ietf-dnsop-default-local-zones-02.txt |
2007-03-02
|
01 | (System) | New version available: draft-ietf-dnsop-default-local-zones-01.txt |
2006-06-20
|
00 | (System) | New version available: draft-ietf-dnsop-default-local-zones-00.txt |