> 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
draft-ietf-dnsop-default-local-zones-02 is current.
> 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?
Abstracts don't normally use 2119-style SHOULDs.
> 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.
10.in-addr.arpa. 300 IN SOA prisoner.iana.org.
hostmaster.root-servers.org. 2002040800 1800 900 604800 604800
10.in-addr.arpa. 300 IN NS blackhole-1.iana.org.
10.in-addr.arpa. 300 IN NS blackhole-2.iana.org.
;; Received 162 bytes from 192.175.48.42#53(blackhole-2.iana.org) in 220 ms
You want recurive nameservers to be able to detect leakage
of queries to the above servers then to log that fact. You
can only do that if the SOA and NS records are differnet
(think answer via forwarder).
> 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.
Show me the xml. There should be a way to do a table.
<t>
<list>
<t>0.IN-ADDR.ARPA /* IPv4 "THIS" NETWORK */</t>
<t>127.IN-ADDR.ARPA /* IPv4 LOOP-BACK NETWORK */</t>
<t>254.169.IN-ADDR.ARPA /* IPv4 LINK LOCAL */</t>
<t>2.0.192.IN-ADDR.ARPA /* IPv4 TEST NET */</t>
<t>255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */</t>
</list>
</t>
> 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?
It's to allow the zones to be hard wired in. It needs to be
a conservative list.
> 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)?
This doesn't fit with the model of the correct answer is
NXDOMAIN.
> 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.
Adding reserved space 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
