>
> On 8-Aug-2006, at 09:05, Peter Koch wrote:
>
> > Please review the document and send comments to the WG mailing list.
>
> See in-line, below.
>
> > This draft has a target status of BCP. Please state whether you
> > agree with
> > this intended status.
>
> I agree with that intended status.
>
> > If you are an implementor of a "full" resolver and/or
> > recursive nameserver, please indicate whether you are planning to
> > implement
> > the recommendation made in this draft.
>
> I am not such an implementer.
>
> I found a few nits that I think should be ironed out before the
> document is sent up the tree, most of them editorial, and all fairly
> inconsequential with respect to the draft's core intention. Those
> nits aside, I support the document going forward.
>
> > 1. Introduction
> >
> > [...]
> >
> > This recommendation is made because data has shown that significant
> > leakage of queries for these name spaces is occurring, despite
>
> Citing data without a reference is weak. A reference should be supplied.
>
> > 2. Effects on sites using RFC 1918 addresses.
> >
> > Sites using [RFC 1918] addresses should already be serving these
> > queries internally, without referring them to public name
> > servers on
> > the Internet.
>
> "answering these queries", not "serving".
>
> > The main impact will be felt on sites that make use of recursion
> > for
> > reverse lookups for [RFC 1918] addresses and have populated these
> > zones. Typically, such sites will be fully disconnected from the
> > Internet and have their own root servers for their own non-Internet
> > DNS tree or make use of local delegation overrides (otherwise known
> > as "forwarding") to reach the private servers for these reverse
> > zones. These sites will need to override the default configuration
> > proposed in this draft to allow resolution to continue.
>
> I'm not convinced that "running your own root server" is typical for
> operators who make use of RFC 1918 addresses, and it scares me a bit
> to see the inference that this is an everyday thing in a document
> aimed at BCP. (The typical approach taken by operators is to avoid
> the issue altogether, which is why this is a good document.)
>
> Usually these sites are *not* fully disconnected from the Internet,
> in my experience; they are attached through leaky middleware, which
> is why AS112 servers receive traffic.
I'm pointing out the sites that will have problems not all
the ways that people insert answers for RFC 1918 addresses.
For most RFC 1918 sites that actually maintain there own
reverse records there won't be problem as they will already
have explict configuration for these zones and won't need
to instanciate the automatic ones.
> > Other sites that use [RFC 1918] addresses and either have local
> > copies of the reverse zones or don't have reverse zones configured
> > should see no difference other than the name error appearing to
> > come
> > from a different source.
> >
> >
> > 3. Changes Iterative Resolver Behaviour.
>
> "Changes to Iterative Resolver Behaviour". Iterative or recursive?
> Recursive is more usual, I thought.
Iterative is correct. I want to capture more than recursive
nameservers.
> > Unless configured otherwise, a iterative resolver will return name
> > errors for queries within the lists of zones covered below. One
> > common way to do this is to serve empty (SOA and NS only) zones.
> >
> > A server doing this MUST provide a mechanism to disable this
> > behaviour, preferably on a zone by zone basis.
> >
> > If using empty zones one should not use the same NS and SOA records
> > as used on the public Internet servers as that will make it
> > harder to
> > detect leakage from the public Internet servers. This document
>
> "Leakage to", rather than "leakage from,", presumably.
>
> > recommends that the NS record default to the name of the zone
> > and the
> > SOA MNAME default to the name of the zone. The SOA RNAME should
> > default to ".". Implementations SHOULD provide a mechanism to set
> > these values. No address records need to be provided for the name
> > server.
> >
> > @ 10800 IN SOA @ . 1 3600 1200 604800 10800
> > @ 10800 IN NS @
>
> Is the use of "@" in this context a BIND-ism, or does it have a more
> implementation-neutral heritage?
It is RFC 1035 master file syntax.
RFC 1035
@ A free standing @ is used to denote the current origin.
> > 4. Lists Of Zones Covered
> >
> > The lists below are expected to seed a IANA registry.
>
> "An IANA registry", not "a".
>
> > 4.2. RFC 3330 Zones
> >
> > 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 */
> > 255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */
>
> Those comments would be easier to read if this was a two-column table.
>
> > 4.3. Local IPv6 Unicast Addresses
> >
> >
> > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP
> > 6.ARPA
> >
> > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP
> > 6.ARPA
>
> Those line breaks are unfortunate.
I agree.
> > 4.4. IPv6 Locally Assigned Local Addresses
> >
> > D.F.IP6.ARPA
>
> This wants a reference to RFC 4193.
>
> > 4.5. IPv6 Link Local Addresses
> >
> > 8.E.F.IP6.ARPA
> > 9.E.F.IP6.ARPA
> > A.E.F.IP6.ARPA
> > B.E.F.IP6.ARPA
>
> These want a reference, too.
>
> > 5. Zones that are Out-Of-Scope
> >
> > IPv6 site-local addresses and IPv6 Globally Assigned Local
> > addresses
> > are not covered here. It is expected that IPv6 site-local
> > addresses
> > will be self correcting as IPv6 implementations remove support for
> > site-local addresses however, sacrificial servers for
> > C.E.F.IP6.ARPA
> > to F.E.F.IP6.ARPA may still need to be deployed in the short
> > term if
> > the traffic becomes excessive.
>
> It seems more proper to describe FEC0::/10 as space reserved by RFC
> 3879 than as "IPv6 site-local addresses", since site-local addresses
> have been deprecated.
>
> > For IPv6 Globally Assigned Local addresses there has been no
> > decision
> > made about whether the registries 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 above. If they do then registries will need to take
> > steps to ensure that name servers are provided for these addresses.
>
> RFC 4193 says "At the present time, AAAA and PTR records for locally
> assigned local IPv6 addresses are not recommended to be installed in
> the global DNS." Your commentary might make reference to that.
>
> > This document is also ignoring the IP6.INT counterpart for the
> > IP6.ARPA addresses above. IP6.INT is in the process of being wound
> > up with clients already not querying for this suffix.
>
> IP6.INT was deprecated in RFC 4159. It is no longer in the process of
> being wound up.
>
> > This document has also deliberately ignored zones immediately under
> > the root. The author believes other methods would be more
> > applicable
> > for dealing with the excess / bogus traffic these generate.
>
> "Zones immediately under the root" is a little cryptic. How about
> referring instead to top-level domains which have no corresponding
> zone delegated from the root, perhaps including examples such as
> "local" and "workgroup"?
>
> > 6. IANA Considerations
> >
> > This document recommends that IANA establish a registry of zones
> > which require this default behaviour, the initial contents are
> > above.
>
> That wants to be two sentences, or one sentence with the comma
> replaced with something stronger (e.g. a semi-colon).
>
> > More zones are expected to be added, and possibly deleted from this
> > registry over time.
>
> This comment seems superfluous -- if no modifications were required
> then a registry would not be needed, and a static list would suffice.
>
> > 7. Security Considerations
> >
> > During the initial deployment phase, particularly where [RFC 1918]
> > addresses are in use, there may be some clients that unexpectedly
> > receive name error rather than a PTR record. This may cause some
> > service disruption until full service resolvers have been re-
> > configured.
> >
> > When DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
> > namespaces, the zones listed above will need to be delegated as
> > insecure delegations. This will allow DNSSEC validation to succeed
> > for queries in these spaces despite not being answered from the
> > delegated servers.
> >
> > It is recommended that sites actively using these namespaces secure
> > them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
> > anchors. This is good just on general principles. It will also
> > protect the clients from accidental leakage of answers from the
> > Internet which will be unsigned.
>
> "This is just good on general principles" seems unconvincing :-) How
> about just "This will protect clients from accidental leakage of
> unsigned answers from the Internet".
>
> > 9.2. Informative References
> >
> > [AS112] "AS112 Project", <http://as112.net/>.
>
> A reference to one of the as112 drafts might be useful. This seems
> unlikely to delay the progress of this draft, since the as112
> documents will be put forward as informational.
>
>
> Joe
> .
> dnsop resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
