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