Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]

[John Crain <[e-mail]>]

Speculation is all it is and I probably have no better ideas than many  
folks here. Be better to try and figure out what is really happening...

I think this is just a knock on effect from the fact that many folks  
don't keep their systems up to date, especially smaller networks.
Typically they turn something on and just leave it until it stops  
working. Just like they don't update any other software if it isn't  
done for them automatically.

That shouldn't come as a surprise to anyone.

It's nice to think that resolvers will automatically fix themselves  
when priming but I think the stats show this not to be solving the  
issue.

It's too early from the L-root perspective to really see what is  
happening. Less than a month since renumbering, long term trends will  
be more interesting.
We'll start to analyze some of the big hitters on the old address.  
Once we have some long term data I will publish something.

Luckily the folks who gave us DSC made it easy for me to do just that.

Big thanks to Duane and co!!!


John L. Crain
Chief Technical Officer
I.C.A.N.N.



On 28 Nov 2007, at 11:02, Joe Baptista wrote:

> Yes - many questions and few answer and very little data available  
> for the community to figure out those answers. John Crain should  
> publish stats more often. Why indeed does root behave so strangely.  
> That little 40 percentage thingy indeed does raise alotof questions.  
> John can you speculate for us? Whats going on.
>
> Another very interesting thing is the incredible power behind one IP  
> number when it has experienced root activity. It only takes one  
> rogue root to highjack the entire root system. Its been done twice  
> now in internet history. How is that possible?
>
> regards
> joe baptista
>
> JINMEI Tatuya / 神明達哉 wrote:
>
>> At Wed, 28 Nov 2007 10:55:44 +0100,
>> Peter Koch <[e-mail]> wrote:
>>
>>
>>>> Currently about 60% New IP to 40% old IP... and rising slowly
>>>>
>>>> So clearly a lot of folks still need to up date their hints  
>>>> files :(
>>>>
>>> part of that traffic will be due to old hints files, but priming was
>>> actually supposed to accelerate the migration.  40% of total L  
>>> traffic
>>> seems a bit much for 1/13 of the priming traffic?
>>>
>>
>> BIND9 also uses the root hint when it finds necessary glue is
>> missing.  For example, consider the following delegation:
>>
>> child.foo.example.  NS 86400 ns.child.foo.example.
>> ns.child.foo.example. A 3600 192.0.2.1
>>
>> When the (recursive) resolver first visits the child.foo.example  
>> zone,
>> it caches both the NS and A records.  The glue (A) record will expire
>> in 1 hour.  When the resolver tries to visit the zone after that  
>> while
>> still keeping the NS record, it tries to fetch the missing glue from
>> the root using the hint file, regardless of whether it has the root  
>> NS
>> and the root server addresses in its cache.
>>
>> This would be another reason for the queries to the old L-root
>> address, though I don't think it makes the 40% of total traffic  
>> unless
>> the vast majority of hint files aren't updated.
>>
>> 					JINMEI, Tatuya
>> 					Communication Platform Lab.
>> 					Corporate R&D Center, Toshiba Corp.
>> 					[e-mail]
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/dnsop
>>
>>
>>
>
>
> -- 
> Joe Baptista                                www.publicroot.org
> PublicRoot Consortium
> ----------------------------------------------------------------
> The future of the Internet is Open, Transparent, Inclusive,
> Representative & Accountable to the Internet community @large.
> ----------------------------------------------------------------
> Office: [phone]
>    Fax: [phone]
>
> <baptista.vcf>_______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dnsop


_______________________________________________
DNSOP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dnsop