Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On Fri, Jun 08, 2007 at 02:57:35PM +1000, Mark Andrews wrote: 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. Not nobody.invalid.? [EMAIL PROTECTED] is likely to be a real mailbox. [EMAIL PROTECTED] should bounce. why do you think so? Mark -- 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 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On Jun 7, 2007, at 9:57 PM, Mark Andrews wrote: 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. Not nobody.invalid.? [EMAIL PROTECTED] is likely to be a real mailbox. [EMAIL PROTECTED] should bounce. It seems that a domain of invalid may not be recognized by its name alone as being invalid. How long will it be before DNS servers and applications reliably recognize this domain as being invalid? There might be a desire in some protocols to publish records that points to an invalid hostname. This could be their method to indicate a type of non-existence. However, this might backfire as being seen as being a valid hostname instead. Applications may also attempt to discover a name server for this domain. What portion of this traffic will be mitigated? -Doug ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On Fri, Jun 08, 2007 at 02:57:35PM +1000, Mark Andrews wrote: 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. Not nobody.invalid.? [EMAIL PROTECTED] is likely to be a real mailbox. [EMAIL PROTECTED] should bounce. why do you think so? a) nobody exists on lots of boxes. Not all boxes alias nobody to something that gets read. b) localhost is usually correctly processes to mean deliver locally. Put (a) and (b) together and you have mail going into a black hole. Mark -- 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 -- 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
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On 7-Jun-2007, at 01:20, Mark Andrews wrote: Show me the xml. There should be a way to do a table. t list t0.IN-ADDR.ARPA /* IPv4 THIS NETWORK *//t t127.IN-ADDR.ARPA /* IPv4 LOOP-BACK NETWORK *//t t254.169.IN-ADDR.ARPA /* IPv4 LINK LOCAL *//t t2.0.192.IN-ADDR.ARPA /* IPv4 TEST NET *//t t255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST *//t /list /t There is a way to do a table: texttable ttcolZone/ttcolttcolDescription/ttcol c0.IN-ADDR.ARPA/c/cIPv4 THIS NETWORK/c c127.IN-ADDR.ARPA/ccIPv4 LOOP-BACK NETWORK/c c254.169.IN-ADDR.ARPA/ccIPv4 LINK LOCAL/c c2.0.192.IN-ADDR.ARPA/ccIPv4 TEST NET/c c255.255.255.255.IN-ADDR.ARPA/ccIPv4 BROADCAST/c /texttable There are details in http://xml.resource.org/authoring/draft-mrose- writing-rfcs.html (see section 2.3.1.4). Joe ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On Thu, Jun 07, 2007 at 07:18:01AM -0400, Joe Abley wrote: On 7-Jun-2007, at 01:20, Mark Andrews wrote: Show me the xml. There should be a way to do a table. t list t0.IN-ADDR.ARPA /* IPv4 THIS NETWORK *//t t127.IN-ADDR.ARPA /* IPv4 LOOP-BACK NETWORK *//t t254.169.IN-ADDR.ARPA /* IPv4 LINK LOCAL *//t t2.0.192.IN-ADDR.ARPA /* IPv4 TEST NET *//t t255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST *//t /list /t There is a way to do a table: texttable ttcolZone/ttcolttcolDescription/ttcol c0.IN-ADDR.ARPA/c/cIPv4 THIS NETWORK/c c127.IN-ADDR.ARPA/ccIPv4 LOOP-BACK NETWORK/c c254.169.IN-ADDR.ARPA/ccIPv4 LINK LOCAL/c c2.0.192.IN-ADDR.ARPA/ccIPv4 TEST NET/c c255.255.255.255.IN-ADDR.ARPA/ccIPv4 BROADCAST/c /texttable There are details in http://xml.resource.org/authoring/draft-mrose- writing-rfcs.html (see section 2.3.1.4). JoeA to borrow a phrase: I'm too young for nroff and too old for xml... I'm generation V(i)! --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-default-local-zones-01
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
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-01
On Wed, 6 Jun 2007, Doug Barton wrote: 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 Putting on my AS112 hat on: Yes. Taking it off, yes to both questions. Section 4.3 [snipping out proposed inclusion of other space.] I think I know the gist of what you're trying to do here. W.r.t inclusion of other address space in the amended and proposed new sections, I would say that including *reserved* space as opposed to *unallocated* space is a good idea in principle. I make this distinction, because I would hate to see this draft go to the other extreme and propose to create a DNS version of a 'bogon-prefix-list', as unallocated space does tend to get allocated, and people's bogon filters don't rapidly change to suit. This creates all sorts of nifty routing problems. :-) wfms ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
