Subject: [DNSOP] draft-ietf-dnsop-default-local-zones-01

From: Doug Barton <[email-masked]>
Date: Wed, 06 Jun 2007 14:03:01 -0700

Howdy,

I finally had a chance to take a serious look at this draft with an
eye toward implementing its recommendations for FreeBSD's default name
server configuration, and noticed that it isn't quite in final form,
so I decided to take a crack at improving the text. Along the way I
have some additional recommendations regarding name spaces that I
think should be included, some of which I realize might be
controversial. :)

I should point out that I did read the threads on this paper already,
and I apologize in advance for not giving full credit to others who
have advanced some of these suggestions already. Where that is true
please read it as my agreeing with their suggestion, rather than
trying to take credit for their work.

To be explicit, I do support the draft moving forward once it's in
better shape, and I support the proposed BCP status.

Because my edits are somewhat extensive, rather than go line by line
I've provided diffs in both unified and context formats:

http://dougbarton.us/draft-ietf-dnsop-default-local-zones-01.udiff.txt
http://dougbarton.us/draft-ietf-dnsop-default-local-zones-01.cdiff.txt

I could provide line by line suggestions if that's preferred.

I also have a few comments, questions and suggestions that I didn't
include in the text.

Abstract
Is it preferred to use 2119-style SHOULDs, etc.; and brackets around
the references in the abstract, or is that text allowed to be more
free form?

Section 3, paragraph 3
I am not sure what is meant by "the same NS and SOA records as used on
the public Internet servers" in the first sentence. I feel like Mark
is trying to make a useful point, and I'm missing it.

I also concur with the various protests against using . for the RNAME,
and would suggest instead "nobody.localhost." along with a ref to
2606. That should be sufficiently clear to any human who looks at it,
and also meets the goal of not providing any useful data to a spam bot.

Section 3, paragraph 6
I'm not arguing against this, but I'm curious about your reasoning for
saying the 2 TTL values SHOULD match. It would probably be useful to
expand that text so that implementors could make a more informed
decision.

In Section 4 I struck the first sentence, since it seems redundant.

Section 4.2
I added some white space between the names and descriptions since I
agreed with the earlier suggestion to do this. I also added several
name spaces from 3330 that I think should also be included, and used
255.IN-ADDR.ARPA instead of just the one address per the
recommendation in 1912. It may be relevant to add a ref there, but I
wasn't sure how best to format that. I realize that expanding the list
might not be a popular idea, so I'm perfectly happy to have those
additional zones removed if that's the consensus, but I thought I'd
make the suggestion. In my experience nothing is harmed by adding these.

I think this also opens up a question about the motivation for this
draft. Is it primarily to reduce spurious traffic to the roots and/or
AS112 (certainly a noble goal, don't get me wrong), or is it primarily
to aid operators in configuring helpful defaults? If the latter I
think that including more zones that are highly unlikely to be the
subject of legitimate queries is a good idea. If the former then we
should focus on those zones that are giving the roots/AS112 the most
trouble (which presumably is what Mark has done).

Section 4.3
I agree with the recommendation to add the all 0's address, but
shouldn't ::1 be defined as "localhost," per 1912 (by extension)?

I'm also proposing 2 new sections, 4.6 to include all IPv6 space that
is currently "reserved" by the IETF, and 4.7 for IPv4 space that is
currently "reserved" by IANA, and highly unlikely to be allocated any
time soon. In 4.6 the ...'s in the diff are meant to indicate that the
whole range between the zones above and below the dots should be
included in the final product. Once again, one could easily argue that
this is overkill, but I wanted to open up discussion on why this is or
is not a good idea.

Section 5, paragraph 2
I think the ref to 4291 is meant to be 4193.

Section 5, paragraph 3
I reworded the paragraph on IP6.INT to take current reality into account.

Section 6
I reworded the IANA Considerations to be more clear about what is
being requested. I also condensed the sentence that seemed to be
making a distinction between ICANN and IANA. I know it's a touchy
subject for some people though, so no objections if people want it
worded differently.

Section 7
"When DNSSEC is deployed," *cough* we will want the current contents
of the IANA registry to be delegated insecurely, not necessarily
what's in the doc when it's published.

I hope this is useful, and I look forward to a lively discussion. :)

Doug

-- 

	If you're never wrong, you're not trying hard enough

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop