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.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to