Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Tue, Jun 15, 2010 at 02:32:54PM +1000, Mark Andrews wrote: Probably true, but not relevant to the discussion. The idea is to force imple menters to look at the registry so that they see *future* additions to it, ev en if they get there from reading this RFC-to-be. You can't force anyone to do anything. If this was split in two (one part saying look in registry and the other half saying this is the priming list) it still wouldn't help as developers may just read the second document. here's where I think we are: The document serves three purposes: 1) it establishes and/or encourages a practice to serve certain zones locally an any recursive resolver (thus BCP) 2) to make the list non-static and maintainable, it establishes an IANA registry with a policy and guidance (thus BCP) 3) from where it came from initially and to make (1) actually helpful, it seeds this registry giving due space to explanations for choices as well as considerations on thise prefixes/domains deliberately not chosen. (1) is basicly done and understood (2) is covered in the IANA considerations section but while that section refers to a formal policy it does not offer guidance for review. We should capture the considerations from the most recent as well as previous discussions like this: Additions to the registry will not have and instantly relieving effect on those authoritative servers otherwise targetted with the queries to locally served zones, it can be expected that implementations will refresh the list of zones to serve occasionally or based on their update cycles. For the same reason it can not be expected that deletions from the registry will allow the removed domain name to be resolved on the public Internet any time after such removal. Regarding (3), while it is useful to seed the registry as broad as possible, it is safe to err on the side of refusal that to poison a prefix by essentially making it non-reverse-mappable. That said, there is consensus to drop section 4.7 and not to add the ORCHID prefix (resp. its reverse mapping domain name) to the registry. On a more editorial side, the document should state its threefold purpose in the introduction. The -14 version should then be ready to go to the AD together with the two AS112 drafts as a bundle, meking the cross references resolvable. -Peter (with hat and Stephen's advice) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Thu, Jun 17, 2010 at 01:15:06PM +0200, Peter Koch wrote: (2) is covered in the IANA considerations section but while that section refers to a formal policy it does not offer guidance for review. We should capture the considerations from the most recent as well as previous discussions like this: Additions to the registry will not have and instantly relieving effect on those authoritative servers otherwise targetted with the queries to locally served zones, it can be expected that implementations will refresh the list of zones to serve occasionally or based on their update cycles. For the same reason it can not be expected that deletions from the registry will allow the removed domain name to be resolved on the public Internet any time after such removal. ANY TIME?? ever? how about ... deletions from the registry will allow the domain names to be resolved on the public Internet at some reasonable time after removal from the registry. Regarding (3), while it is useful to seed the registry as broad as possible, it is safe to err on the side of refusal that to poison a prefix by essentially making it non-reverse-mappable. That said, there is consensus to drop section 4.7 and not to add the ORCHID prefix (resp. its reverse mapping domain name) to the registry. On a more editorial side, the document should state its threefold purpose in the introduction. The -14 version should then be ready to go to the AD together with the two AS112 drafts as a bundle, meking the cross references resolvable. -Peter (with hat and Stephen's advice) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Thu, Jun 17, 2010 at 02:19:57PM +, bmann...@vacation.karoshi.com wrote: ANY TIME?? ever? how about ... deletions from the registry will allow the domain names to be resolved on the public Internet at some reasonable time after removal from the registry. thanks. Given our limited experience with eternity, this text is not only more precise but also better suggests that one cannot be sure in either direction. -Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Jun 15 2010, Mark Andrews wrote: In message p0624080cc83c9ae05...@[10.20.30.158], Paul Hoffman writes: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( Good call. +1 The zone listed are intended to be stable enough in usage that they can be frozen in code. Zones added to the registry should be of a similar level of stability. It would be a very rare event for a zone to be removed from the registry and it would take decades, if ever, that the zone would be untainted. Probably true, but not relevant to the discussion. The idea is to force imple menters to look at the registry so that they see *future* additions to it, ev en if they get there from reading this RFC-to-be. You can't force anyone to do anything. If this was split in two (one part saying look in registry and the other half saying this is the priming list) it still wouldn't help as developers may just read the second document. A tentative suggestion: maybe lists of this sort ought to be distributed via the DNS itself, with nameserver software encouraged to fetch them dynamically and act accordingly. Something along the lines of local-zones.arpa. PTR 0.in-addr.arpa. PTR 127.in-addr.arpa. PTR 254.169.in-addr.arpa. ... PTR 8.e.f.ip6.arpa. PTR 9.e.f.ip6.arpa. ... Not that this would stop some implementors fetching the current value and fixing it in their code... One would want local.zones.arpa (or whatever) to be signed, of course! -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
A tentative suggestion: maybe lists of this sort ought to be distributed via the DNS itself, with nameserver software encouraged to fetch them dynamically and act accordingly. Something along the lines of local-zones.arpa. PTR 0.in-addr.arpa. PTR 127.in-addr.arpa. PTR 254.169.in-addr.arpa. ... PTR 8.e.f.ip6.arpa. PTR 9.e.f.ip6.arpa. ... Not that this would stop some implementors fetching the current value and fixing it in their code... One would want local.zones.arpa (or whatever) to be signed, of course! Which doesn't work in some of the senarios where you want this code to come into play, i.e. firewalls that let RFC 1918 reverse queries out but not let the replies come back. The idea is to prevent the queries leaving the nameservers in the first place. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( Good call. +1 The zone listed are intended to be stable enough in usage that they can be frozen in code. Zones added to the registry should be of a similar level of stability. It would be a very rare event for a zone to be removed from the registry and it would take decades, if ever, that the zone would be untainted. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
At 12:12 PM +1000 6/15/10, Mark Andrews wrote: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( Good call. +1 The zone listed are intended to be stable enough in usage that they can be frozen in code. Zones added to the registry should be of a similar level of stability. It would be a very rare event for a zone to be removed from the registry and it would take decades, if ever, that the zone would be untainted. Probably true, but not relevant to the discussion. The idea is to force implementers to look at the registry so that they see *future* additions to it, even if they get there from reading this RFC-to-be. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Mon, Jun 14, 2010 at 07:51:14PM -0700, Paul Hoffman wrote: At 12:12 PM +1000 6/15/10, Mark Andrews wrote: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( Good call. +1 The zone listed are intended to be stable enough in usage that they can be frozen in code. Zones added to the registry should be of a similar level of stability. It would be a very rare event for a zone to be removed from the registry and it would take decades, if ever, that the zone would be untainted. Probably true, but not relevant to the discussion. The idea is to force implementers to look at the registry so that they see *future* additions to it, even if they get there from reading this RFC-to-be. --Paul Hoffman, Director --VPN Consortium I'll note in passing that the Martian prefix list took less than 30 days to be declared valid to use prefixes and it has taken decades to eradicate them as Martians (by killing off code which chose to freeze them because of the stability of classful addressing)... there are still vestigages of this cruft around. I can not and do not share Marks naive presumptions about the stability of prefix use. Guess I've been burned by that assumption twice - don't want to be bit by it a third time. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
In message p0624080cc83c9ae05...@[10.20.30.158], Paul Hoffman writes: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( Good call. +1 The zone listed are intended to be stable enough in usage that they can be frozen in code. Zones added to the registry should be of a similar level of stability. It would be a very rare event for a zone to be removed from the registry and it would take decades, if ever, that the zone would be untainted. Probably true, but not relevant to the discussion. The idea is to force imple menters to look at the registry so that they see *future* additions to it, ev en if they get there from reading this RFC-to-be. You can't force anyone to do anything. If this was split in two (one part saying look in registry and the other half saying this is the priming list) it still wouldn't help as developers may just read the second document. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
On Jun 10, 2010 at 17:38 +0200, Shane Kerr wrote: =On Mon, 2010-05-31 at 10:25 +0100, Stephen Morris wrote: = I think the local zones draft is just about there, but a couple more = questions: = = The last revision included the ORCHID addresses. They are not = routable but, unusually, they are time-limited - the assignment is set = to be revoked in 2014. So there is the question as to whether the = address range should be in the draft (or should be marked with this = caveat). = = The ORCHID address range is taken from the IANA special purpose IPv6 = address block, which is reserved - amongst other things - for testing = and experimental use. Currently it also includes address assignments = for TEREDO and benchmarking. Should the draft mention this address = range and/or these assignments? = =I think excluding testing experimental addresses is potentially =dangerous. For example, it is possible that one of these may need DNS =for an Internet-wide experiment. = =In any case, I don't think there is much benefit by including these =blocks. I propose the ORCHID and the rest of the special purpose IPv6 =addresses be left out of the list of local zones, and treated normally. Raising hand timidly Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *** ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13
At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force implementations to go look at the assignment registry and maybe more aware of the dynamic nature of some of these zones. As the draft is now, some implementors probably will stop reading after section 5. :( Good call. +1 --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-default-local-zones-13
I think the local zones draft is just about there, but a couple more questions: The last revision included the ORCHID addresses. They are not routable but, unusually, they are time-limited - the assignment is set to be revoked in 2014. So there is the question as to whether the address range should be in the draft (or should be marked with this caveat). The ORCHID address range is taken from the IANA special purpose IPv6 address block, which is reserved - amongst other things - for testing and experimental use. Currently it also includes address assignments for TEREDO and benchmarking. Should the draft mention this address range and/or these assignments? Stephen Morris ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
