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.
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.
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?
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.
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
