hum... well there are two things here...
) ip6.int.
ICANN has removed that delegation. Me, i'm still serving
up delegations under that which the zone owners have not
removed. Same boat Mark is in... :) Didn't matter to
ICANN or the v6 zelots. L(
) this draft and the whole idea of "special" zones that are
automagically created/defined.
I think this is a horrible idea, a bandaid to try and
cover festering sores created by the IETF. When clean
up is eventually done, there is zero way to tell all those
installed configurations that they are broken and should
be updated/corrected. Time to start patching ISC bind
to get resonable behaviour again.. :(
--bill
On Fri, Aug 11, 2006 at 10:48:46AM +1000, Mark Andrews wrote:
>
> > > This document is also ignoring the IP6.INT counterpart for the
> > > IP6.ARPA addresses above. IP6.INT is in the process of being wound
> > > up with clients already not querying for this suffix.
> >
> > IP6.INT was deprecated in RFC 4159. It is no longer in the process of
> > being wound up.
>
> As long as there are clients which make IP6.INT queries as
> the result of calling getnameinfo(), etc. it is in the
> process of being wound up. I expect there will be a very
> long tail here but so long as the traffic doesn't get too
> large it should not be a issue.
>
> Removing "counterpart for the IP6.ARPA addresses above"
> would be appropriate.
>
> Note: my IPv6 provider [Bcc'd] hasn't yet removed the
> delegation for my /64 under ip6.int. I'm not going to stop
> serving the zone until that delegation is removed or the
> parent zone is removed. I suspect most end user sites are
> in the same position.
>
> Cleaning up IP6.INT has to be a top down process. The top
> has started by the RIR's should, if they havn't already,
> inform all the old registants under IP6.INT that the
> delegation has been removed and that they no longer need
> to serve the next zone down. This should ripple down
> from there.
>
> Yes I could unilaterally stop serving but that would break
> thing rather than resulting in NXDOMAIN being returned for
> the few sites that can still resolve the names.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
> .
> dnsop resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
