6bone/ip6.int interaction

bmanning at vacation.karoshi.com bmanning at vacation.karoshi.com
Wed Jun 14 18:46:05 CEST 2006

On Wed, Jun 14, 2006 at 06:24:00PM +0200, Mohsen Souissi wrote:
> Sorry for my late answer (below):
>  On 13 Jun, Doug Barton wrote:
>  | Bernhard Schmidt wrote:
>  | 
>  | > Do you have the necessary force to avoid ip6.int sneaking in through
>  | > ns.isi.edu (which is a listed authoritative server of .int and has
>  | > ip6.int loaded into)?
>  | 
>  | Well, it's slightly worse than that actually. Not only does ns.isi.edu still
>  | have the zone loaded, but it's (the only INT server) still running the
>  | 2006050200 version of the INT zone which still has the delegation. Bill,
>  | time to play nice with others. :)
>  | 
>  | As long as we're at it, ns3.nic.fr is still serving the ip6.int zone as
>  | well. Stephane? Anyone else from AFNIC?
> ==> Maybe that wasn't the best way to do it but I wished to see 
> the delegation from .int to ip6.int cut before asking ip6.int
> authoritative servers to stop serving that zone. If I had to
> deconfigure ip6.int on ns3.nic.fr before the delegation int -->
> ip6.int being cut, I would simly have caused a lame delegation which
> is not a clean way to make ip6.int disappear from the DNS.
> I removed all RIR-based *ip6.int zones on ns3.nic.fr because RIRs had
> already cut the delegation. I presume that was the right order of
> actions.
> Now, the ip6.int has gone from ns3.nic.fr thus creating a lame
> delegation. It's up to the parent zone maintainer to take the
> appropriate actions.
> Regards,
> Mohsen.

	amen.  and ns.isi.edu is still prohibited from doing 
	zone transfers from ICANN, so the copy of the int zone
	it serves will be lame until ICANN removes the block.


More information about the ipv6-ops mailing list