On Fri, Apr 07, 2006 at 12:30:23PM +1000, Mark Andrews wrote:
>
> > > http://v6fix.net/docs/ip6.int show that a number of current
> > > resolvers are still falling back to IP6.INT. Until these
> > > resolvers are corrected to be arpa (nibble) only the load
> > > on the IP6.INT servers will only increase.
> >
> > presuming IANA leaves that delegation in place...
> > if they pull it, the load goes to the INT servers...
> > me, i'd need a COMPELLING reason to pull the delegations.
> > i've not heard one yet... but its not my call. :)
> >
> > --bill
>
> Ask Sun why they still fallback to IP6.INT.
> Ask the glibc developers why they still fallback to IP6.INT.
nope... the IETF has been preaching the death of ip6.int for
years and have declared it to historic, depricated, et.al.
... kind of like what happened when the IETF declared RIPv1 dead.
if developers have their own reasons for ignoring IETF edicts
there is zero percentage in my asking them questions. Or was this
a retorical question?
> I suspect the answers will be: "there is still information
> under IP6.INT that is not available under IP6.ARPA,
> in-particular local information and we can't break local
> reverse lookups for our customers."
Perhaps ... it took several heroic efforts to undo some (imho)
misguided attempts to restrict any DNS entries in reverse maps to
RIR's or their customers. the 3ffe:: delegation took a serious hit
with that "change"... There is still some vestigal goo that only
sits in ip6.int...
>
> To be able to close down IP6.INT you have to get all the
> vendors to stop querying IP6.INT or remove the data available
> under IP6.INT globally.
but whats the point? instead of shooting the horse and trying
to get unstuck from the mess left behind, a credible stratagy is
to just leave the delegations in place to deal w/ the leftovers...
eventually, after a suitable(*) mourning period, pull the delegations.
whats the rush? RIRs are not going to populate any data in this
part of the tree... this might be enough clue for OS/developers
to figure out that the ip6.arpa arguement, while technically lame,
is the wave of the future and they can be persuaded to change...
* imho 3 - 5 years. i think it is finally time to shut off the pre-6bone
delegation... the servers have gotten less than 10 queries this year... and
4 of them have been from me... :)
> Deploying empty IP6.INT zones in recurive nameservers would
> allow local IP6.INT to still succeed without creating load
> on the global servers. However I would only recommend this
> course if we can't convince Sun and glibc to fix there
> resolvers.
There is some validity to keeping authoritative copies of
"special" zones ... but there is a real problem of when (not IF)
there is a change required ... then there is the whole syncronization
problem of having to upgrade (thousands, 10's of thousands, 100's
of thousands?) of systems. Experiences with the whole belt/suspenders
thing over the last 15 years has been an effort in futility.
--bill
>
> 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
