No empty .Rs/.Re
[netbsd-mini2440.git] / external / bsd / bind / dist / doc / draft / draft-ietf-dnsop-default-local-zones-09.txt
blob7e81e4c4bf559a3b65635e7123bd2e246e086162
4 Network Working Group                                         M. Andrews
5 Internet-Draft                                                       ISC
6 Intended status: BCP                                   November 19, 2009
7 Expires: May 23, 2010
10                         Locally-served DNS Zones
11                 draft-ietf-dnsop-default-local-zones-09
13 Abstract
15    Experience with the Domain Name System (DNS) has shown that there are
16    a number of DNS zones all iterative resolvers and recursive
17    nameservers should automatically serve, unless configured otherwise.
18    RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This
19    document extends the practice to cover the IN-ADDR.ARPA zones for RFC
20    1918 address space and other well known zones with similar
21    characteristics.
23 Status of this Memo
25    This Internet-Draft is submitted to IETF in full conformance with the
26    provisions of BCP 78 and BCP 79.
28    Internet-Drafts are working documents of the Internet Engineering
29    Task Force (IETF), its areas, and its working groups.  Note that
30    other groups may also distribute working documents as Internet-
31    Drafts.
33    Internet-Drafts are draft documents valid for a maximum of six months
34    and may be updated, replaced, or obsoleted by other documents at any
35    time.  It is inappropriate to use Internet-Drafts as reference
36    material or to cite them other than as "work in progress."
38    The list of current Internet-Drafts can be accessed at
39    http://www.ietf.org/ietf/1id-abstracts.txt.
41    The list of Internet-Draft Shadow Directories can be accessed at
42    http://www.ietf.org/shadow.html.
44    This Internet-Draft will expire on May 23, 2010.
46 Copyright Notice
48    Copyright (c) 2009 IETF Trust and the persons identified as the
49    document authors.  All rights reserved.
51    This document is subject to BCP 78 and the IETF Trust's Legal
55 Andrews                   Expires May 23, 2010                  [Page 1]
57 Internet-Draft          Locally-served DNS Zones           November 2009
60    Provisions Relating to IETF Documents
61    (http://trustee.ietf.org/license-info) in effect on the date of
62    publication of this document.  Please review these documents
63    carefully, as they describe your rights and restrictions with respect
64    to this document.  Code Components extracted from this document must
65    include Simplified BSD License text as described in Section 4.e of
66    the Trust Legal Provisions and are provided without warranty as
67    described in the BSD License.
69    This document may contain material from IETF Documents or IETF
70    Contributions published or made publicly available before November
71    10, 2008.  The person(s) controlling the copyright in some of this
72    material may not have granted the IETF Trust the right to allow
73    modifications of such material outside the IETF Standards Process.
74    Without obtaining an adequate license from the person(s) controlling
75    the copyright in such materials, this document may not be modified
76    outside the IETF Standards Process, and derivative works of it may
77    not be created outside the IETF Standards Process, except to format
78    it for publication as an RFC or to translate it into languages other
79    than English.
111 Andrews                   Expires May 23, 2010                  [Page 2]
113 Internet-Draft          Locally-served DNS Zones           November 2009
116 Table of Contents
118    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
119      1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
120    2.  Effects on sites using RFC 1918 addresses. . . . . . . . . . .  4
121    3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
122    4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
123      4.1.  RFC1918 Zones  . . . . . . . . . . . . . . . . . . . . . .  5
124      4.2.  RFC3330 Zones  . . . . . . . . . . . . . . . . . . . . . .  6
125      4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
126      4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  6
127      4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
128      4.6.  IPv6 Example Prefix  . . . . . . . . . . . . . . . . . . .  7
129    5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
130    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
131    7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
132    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
133    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
134      9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
135      9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
136    Appendix A.  Change History [To Be Removed on Publication] . . . . 10
137      A.1.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
138      A.2.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 10
139      A.3.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 10
140      A.4.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 10
141      A.5.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
142      A.6.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
143      A.7.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
144      A.8.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
145      A.9.  draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
146      A.10. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
147      A.11. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 11
148      A.12. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
149    Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 12
150    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
167 Andrews                   Expires May 23, 2010                  [Page 3]
169 Internet-Draft          Locally-served DNS Zones           November 2009
172 1.  Introduction
174    Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035])
175    has shown that there are a number of DNS zones that all iterative
176    resolvers and recursive nameservers SHOULD automatically serve,
177    unless intentionally configured otherwise.  These zones include, but
178    are not limited to, the IN-ADDR.ARPA zones for the address space
179    allocated by [RFC1918] and the IP6.ARPA zones for locally assigned
180    unique local IPv6 addresses defined in [RFC4193].
182    This recommendation is made because data has shown that significant
183    leakage of queries for these name spaces is occurring, despite
184    instructions to restrict them, and because it has therefore become
185    necessary to deploy sacrificial name servers to protect the immediate
186    parent name servers for these zones from excessive, unintentional,
187    query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
188    [I-D.draft-ietf-dnsop-as112-under-attack-help-help].  There is every
189    expectation that the query load will continue to increase unless
190    steps are taken as outlined here.
192    Additionally, queries from clients behind badly configured firewalls
193    that allow outgoing queries for these name spaces but drop the
194    responses, put a significant load on the root servers (forward but no
195    reverse zones configured).  They also cause operational load for the
196    root server operators as they have to reply to enquiries about why
197    the root servers are "attacking" these clients.  Changing the default
198    configuration will address all these issues for the zones listed in
199    Section 4.
201    [RFC4193] recommends that queries for D.F.IP6.ARPA be handled
202    locally.  This document extends the recommendation to cover the IN-
203    ADDR.ARPA zones for [RFC1918] and other well known IN-ADDR.ARPA and
204    IP6.ARPA zones for which queries should not appear on the public
205    Internet.
207    It is hoped that by doing this the number of sacrificial servers
208    [AS112] will not have to be increased, and may in time be reduced.
210    This recommendation should also help DNS responsiveness for sites
211    which are using [RFC1918] addresses but do not follow the last
212    paragraph in Section 3 of [RFC1918].
214 1.1.  Reserved Words
216    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
218    document are to be interpreted as described in [RFC2119].
223 Andrews                   Expires May 23, 2010                  [Page 4]
225 Internet-Draft          Locally-served DNS Zones           November 2009
228 2.  Effects on sites using RFC 1918 addresses.
230    For most sites using [RFC1918] addresses, the changes here will have
231    little or no detrimental effect.  If the site does not already have
232    the reverse tree populated the only effect will be that the name
233    error responses will be generated locally rather than remotely.
235    For sites that do have the reverse tree populated, most will either
236    have a local copy of the zones or will be forwarding the queries to
237    servers which have local copies of the zone.  Therefore this
238    recommendation will not be relevant.
240    The most significant impact will be felt at sites that make use of
241    delegations for [RFC1918] addresses and have populated these zones.
242    These sites will need to override the default configuration expressed
243    in this document to allow resolution to continue.  Typically, such
244    sites will be fully disconnected from the Internet and have their own
245    root servers for their own non-Internet DNS tree.
248 3.  Changes to Iterative Resolver Behaviour.
250    Unless configured otherwise, an iterative resolver will now return
251    authoritatively (aa=1) name errors (RCODE=3) for queries within the
252    zones in Section 4, with the obvious exception of queries for the
253    zone name itself where SOA, NS and "no data" responses will be
254    returned as appropriate to the query type.  One common way to do this
255    all at once is to serve empty (SOA and NS only) zones.
257    An implementation of this recommendation MUST provide a mechanism to
258    disable this new behaviour, and SHOULD allow this decision on a zone
259    by zone basis.
261    If using empty zones one SHOULD NOT use the same NS and SOA records
262    as used on the public Internet servers as that will make it harder to
263    detect the origin of the responses and thus any leakage to the public
264    Internet servers.  This document recommends that the NS record
265    defaults to the name of the zone and the SOA MNAME defaults to the
266    name of the only NS RR's target.  The SOA RNAME should default to
267    "nobody.invalid."  [RFC2606].  Implementations SHOULD provide a
268    mechanism to set these values.  No address records need to be
269    provided for the name server.
271    Below is an example of a generic empty zone in master file format.
272    It will produce a negative cache TTL of 3 hours.
274    @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
275    @ 10800 IN NS @
279 Andrews                   Expires May 23, 2010                  [Page 5]
281 Internet-Draft          Locally-served DNS Zones           November 2009
284    The SOA RR is needed to support negative caching [RFC2308] of name
285    error responses and to point clients to the primary master for DNS
286    dynamic updates.
288    SOA values of particular importance are the MNAME, the SOA RR's TTL
289    and the negTTL value.  Both TTL values SHOULD match.  The rest of the
290    SOA timer values MAY be chosen arbitrarily since they are not
291    intended to control any zone transfer activity.
293    The NS RR is needed as some UPDATE [RFC2136] clients use NS queries
294    to discover the zone to be updated.  Having no address records for
295    the name server is expected to abort UPDATE processing in the client.
298 4.  Lists Of Zones Covered
300    The following subsections are intended to seed the IANA registry as
301    requested in the IANA Considerations Section.  The zone name is the
302    entity to be registered.
304 4.1.  RFC1918 Zones
306    The following zones correspond to the IPv4 address space reserved in
307    [RFC1918].
309                          +----------------------+
310                          | Zone                 |
311                          +----------------------+
312                          | 10.IN-ADDR.ARPA      |
313                          | 16.172.IN-ADDR.ARPA  |
314                          | 17.172.IN-ADDR.ARPA  |
315                          | 18.172.IN-ADDR.ARPA  |
316                          | 19.172.IN-ADDR.ARPA  |
317                          | 20.172.IN-ADDR.ARPA  |
318                          | 21.172.IN-ADDR.ARPA  |
319                          | 22.172.IN-ADDR.ARPA  |
320                          | 23.172.IN-ADDR.ARPA  |
321                          | 24.172.IN-ADDR.ARPA  |
322                          | 25.172.IN-ADDR.ARPA  |
323                          | 26.172.IN-ADDR.ARPA  |
324                          | 27.172.IN-ADDR.ARPA  |
325                          | 28.172.IN-ADDR.ARPA  |
326                          | 29.172.IN-ADDR.ARPA  |
327                          | 30.172.IN-ADDR.ARPA  |
328                          | 31.172.IN-ADDR.ARPA  |
329                          | 168.192.IN-ADDR.ARPA |
330                          +----------------------+
335 Andrews                   Expires May 23, 2010                  [Page 6]
337 Internet-Draft          Locally-served DNS Zones           November 2009
340 4.2.  RFC3330 Zones
342    The following zones correspond to those address ranges from [RFC3330]
343    that are not expected to appear as source or destination addresses on
344    the public Internet and to not have a unique name to associate with.
346    The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
347    attempt to discourage any practice to provide a PTR RR for
348    1.0.0.127.IN-ADDR.ARPA locally.  In fact, a meaningful reverse
349    mapping should exist, but the exact setup is out of the scope of this
350    document.  Similar logic applies to the reverse mapping for ::1
351    (Section 4.3).  The recommendations made here simply assume no other
352    coverage for these domains exists.
354          +------------------------------+------------------------+
355          | Zone                         | Description            |
356          +------------------------------+------------------------+
357          | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK    |
358          | 127.IN-ADDR.ARPA             | IPv4 LOOP-BACK NETWORK |
359          | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL        |
360          | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET          |
361          | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
362          +------------------------------+------------------------+
364 4.3.  Local IPv6 Unicast Addresses
366    The reverse mappings ([RFC3596], Section 2.5 IP6.ARPA Domain) for the
367    IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291],
368    Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
370                +-------------------------------------------+
371                | Zone                                      |
372                +-------------------------------------------+
373                | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
374                |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
375                | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
376                |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
377                +-------------------------------------------+
379    Note: Line breaks and a escapes '\' have been inserted above for
380    readability and to adhere to line width constraints.  They are not
381    parts of the zone names.
383 4.4.  IPv6 Locally Assigned Local Addresses
385    Section 4.4 of [RFC4193] already required special treatment of:
391 Andrews                   Expires May 23, 2010                  [Page 7]
393 Internet-Draft          Locally-served DNS Zones           November 2009
396                              +--------------+
397                              | Zone         |
398                              +--------------+
399                              | D.F.IP6.ARPA |
400                              +--------------+
402 4.5.  IPv6 Link Local Addresses
404    IPv6 Link-Local Addresses as of [RFC4291], Section 2.5.6 are covered
405    by four distinct reverse DNS zones:
407                             +----------------+
408                             | Zone           |
409                             +----------------+
410                             | 8.E.F.IP6.ARPA |
411                             | 9.E.F.IP6.ARPA |
412                             | A.E.F.IP6.ARPA |
413                             | B.E.F.IP6.ARPA |
414                             +----------------+
416 4.6.  IPv6 Example Prefix
418    IPv6 example prefix [RFC3849].
420                        +--------------------------+
421                        | Zone                     |
422                        +--------------------------+
423                        | 8.B.D.0.1.0.0.2.IP6.ARPA |
424                        +--------------------------+
426    Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as a example here.
429 5.  Zones that are Out-Of-Scope
431    IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and
432    2.5.7), and IPv6 Non-Locally Assigned Local addresses ([RFC4193]) are
433    not covered here.
435    It is expected that IPv6 site-local addresses will be self correcting
436    as IPv6 implementations remove support for site-local addresses.
437    However, sacrificial servers for the zones C.E.F.IP6.ARPA through
438    F.E.F.IP6.ARPA may still need to be deployed in the short term if the
439    traffic becomes excessive.
441    For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193],
442    there has been no decision made about whether the Regional Internet
443    Registries (RIRs) will provide delegations in this space or not.  If
447 Andrews                   Expires May 23, 2010                  [Page 8]
449 Internet-Draft          Locally-served DNS Zones           November 2009
452    they don't, then C.F.IP6.ARPA will need to be added to the list in
453    Section 4.4.  If they do, then registries will need to take steps to
454    ensure that name servers are provided for these addresses.
456    This document also ignores IP6.INT.  IP6.INT has been wound up with
457    only legacy resolvers now generating reverse queries under IP6.INT
458    [RFC4159].
460    This document has also deliberately ignored names immediately under
461    the root domain.  While there is a subset of queries to the root name
462    servers which could be addressed using the techniques described here
463    (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
464    amount of traffic that requires a different strategy (e.g. lookups
465    for unqualified hostnames, IPv6 addresses).
468 6.  IANA Considerations
470    This document requests that IANA establish a registry of zones which
471    require this default behaviour.  The initial contents of this
472    registry are defined in Section 4.  Implementors are encouraged to
473    periodically check this registry and adjust their implementations to
474    reflect changes therein.
476    This registry can be amended through "IETF Review" as per [RFC5226].
478    IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
479    deployed in the reverse tree, delegations for these zones are made in
480    the manner described in Section 7.
483 7.  Security Considerations
485    During the initial deployment phase, particularly where [RFC1918]
486    addresses are in use, there may be some clients that unexpectedly
487    receive a name error rather than a PTR record.  This may cause some
488    service disruption until their recursive name server(s) have been re-
489    configured.
491    As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
492    namespaces, the zones listed above will need to be delegated as
493    insecure delegations, or be within insecure zones.  This will allow
494    DNSSEC validation to succeed for queries in these spaces despite not
495    being answered from the delegated servers.
497    It is recommended that sites actively using these namespaces secure
498    them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
499    anchors.  This will protect the clients from accidental import of
503 Andrews                   Expires May 23, 2010                  [Page 9]
505 Internet-Draft          Locally-served DNS Zones           November 2009
508    unsigned responses from the Internet.
511 8.  Acknowledgements
513    This work was supported by the US National Science Foundation
514    (research grant SCI-0427144) and DNS-OARC.
517 9.  References
519 9.1.  Normative References
521    [RFC1034]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
522               STD 13, RFC 1034, November 1987.
524    [RFC1035]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
525               SPECIFICATION", STD 13, RFC 1035, November 1987.
527    [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
528               and E. Lear, "Address Allocation for Private Internets",
529               BCP 5, RFC 1918, February 1996.
531    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
532               Requirement Levels", BCP 14, RFC 2119, March 1997.
534    [RFC2136]  Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
535               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
536               RFC 2136, April 1997.
538    [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
539               NCACHE)", RFC 2398, March 1998.
541    [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
542               Names", BCP 32, RFC 2606, June 1999.
544    [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
545               "DNS Extensions to Support IPv6", RFC 3596, October 2003.
547    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
548               Rose, "Protocol Modifications for the DNS Security
549               Extensions", RFC 4035, March 2005.
551    [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
552               August 2005.
554    [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
555               Addresses", RFC 4193, October 2005.
559 Andrews                   Expires May 23, 2010                 [Page 10]
561 Internet-Draft          Locally-served DNS Zones           November 2009
564    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
565               Architecture", RFC 4291, February 2006.
567    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
568               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
569               October 2008.
571 9.2.  Informative References
573    [AS112]    "AS112 Project", <http://www.as112.net/>.
575    [I-D.draft-ietf-dnsop-as112-ops]
576               Abley, J. and W. Maton, "AS112 Nameserver Operations",
577               draft-ietf-dnsop-as112-ops-01 (work in progress),
578               November 2007.
580    [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
581               Abley, J. and W. Maton, "I'm Being Attacked by
582               PRISONER.IANA.ORG!",
583               draft-ietf-dnsop-as112-under-attack-help-help-01 (work in
584               progress), November 2007.
586    [RFC3330]  "Special-Use IPv4 Addresses", RFC 3330, September 2002.
588    [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
589               Reserved for Documentation", RFC 3849, July 2004.
592 Appendix A.  Change History [To Be Removed on Publication]
594 A.1.  draft-ietf-dnsop-default-local-zones-09.txt
596    refresh awaiting writeup
598 A.2.  draft-ietf-dnsop-default-local-zones-08.txt
600    editorial, reference updates
602 A.3.  draft-ietf-dnsop-default-local-zones-07.txt
604    none, expiry prevention
606 A.4.  draft-ietf-dnsop-default-local-zones-06.txt
608    add IPv6 example prefix
615 Andrews                   Expires May 23, 2010                 [Page 11]
617 Internet-Draft          Locally-served DNS Zones           November 2009
620 A.5.  draft-ietf-dnsop-default-local-zones-05.txt
622    none, expiry prevention
624 A.6.  draft-ietf-dnsop-default-local-zones-04.txt
626    Centrally Assigned Local addresses -> Non-Locally Assigned Local
627    address
629 A.7.  draft-ietf-dnsop-default-local-zones-03.txt
631    expanded section 4 descriptions
633    Added references [RFC2136], [RFC3596],
634    [I-D.draft-ietf-dnsop-as112-ops] and
635    [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
637    Revised language.
639 A.8.  draft-ietf-dnsop-default-local-zones-02.txt
641    RNAME now "nobody.invalid."
643    Revised language.
645 A.9.  draft-ietf-dnsop-default-local-zones-01.txt
647    Revised impact description.
649    Updated to reflect change in IP6.INT status.
651 A.10.  draft-ietf-dnsop-default-local-zones-00.txt
653    Adopted by DNSOP.
655    "Author's Note" re-titled "Zones that are Out-Of-Scope"
657    Add note that these zone are expected to seed the IANA registry.
659    Title changed.
661 A.11.  draft-andrews-full-service-resolvers-03.txt
663    Added "Proposed Status".
671 Andrews                   Expires May 23, 2010                 [Page 12]
673 Internet-Draft          Locally-served DNS Zones           November 2009
676 A.12.  draft-andrews-full-service-resolvers-02.txt
678    Added 0.IN-ADDR.ARPA.
681 Appendix B.  Proposed Status [To Be Removed on Publication]
683    This Internet-Draft is being submitted for eventual publication as an
684    RFC with a proposed status of Best Current Practice.
687 Author's Address
689    Mark P. Andrews
690    Internet Systems Consortium
691    950 Charter Street
692    Redwood City, CA  94063
693    US
695    Email: Mark_Andrews@isc.org
727 Andrews                   Expires May 23, 2010                 [Page 13]