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 DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop