Mailing List Archive

> But it does bring up an interesting point.... is it that easy to create
> chaos? They are so far down the food chain, and yet....

BIND 4.9.5-P1 and later (which is 4.9.6 and all versions of 8.*) is not
susceptible to this corruption. see ftp://ftp.isc.org/isc/bind/src.

At 10:32 AM 7/3/97 -0700, Rodney Joffe wrote:

Yeah it is. Wait till someone steals your network numbers by broadcasting
them and their ISP isn't filtering.
It's Happened Before.

This is one of the things we don't want the press writing about. How
darned easy it is for some person making a silly mistake to introduce a big
transient problem until it gets killed. Fortunately, people pay attention
and kill these things off reasonably quickly, but it makes managing the net
a much more "active" thing than one would think at first inspection. A lot
of management at a lot of companies (even ISPs), doesn't realize this.

The problem of course is that we can't scale the number of people who know
how to fix things like this nearly as fast as we can (and are) scaling the
network. The whole thing needs to be a lot more insensitive to minor
screwups. The fact that most of our protocols (like especially DNS and
even to an extent BGP) were designed when the universe of people who would
be managing them was much smaller. The problem gets worse when people use
old protocols (like DNS) that were intended for one thing (nameing) to
implement something different (like load balancing) "because it works".
Kind of. On the other hand, with the installed base, replacing old
protocols is getting really difficult.

As an industry, we need to move this process forward. The network grows
while you sleep...

-jcp-

PS:
Personal note: This is my last week at PointCast, hence the 'jcphome'
address. That's my permanent address.

-jcp-

>This has been corrected temporarily. With brute force ;-)
>
>Genieweb is a downstream customer of Los Nettos, one of our customers.
>No-one has been able to reach the company or the contact, so their T1
>was just taken down. I expect a call rather soon, so we can get them to
>fix their mistake.
>
>But it does bring up an interesting point.... is it that easy to create
>chaos? They are so far down the food chain, and yet....
>
>
>
>Rodney Joffe
>Chief Technology Officer
>Genuity Inc., a Bechtel company
>http://www.genuity.net
>
>
>
>> -----Original Message-----
>> From: seanl@literati.org [SMTP:seanl@literati.org]
>> Sent: Thursday, July 03, 1997 9:59 AM
>> To: nanog@merit.edu
>> Subject: genieweb.com answering for COM
>>
>> com. 304 SOA genieweb.com. root.genieweb.com. (
>> 11 ; serial
>> 10800 ; refresh (3 hours)
>> 3600 ; retry (1 hour)
>> 604800 ; expire (7 days)
>>
>> This was cached on one our name servers. Sure enough, dig any com
>> @genieweb.com shows:
>>
>> ;; ANSWERS:
>> com. 86400 SOA genieweb.com. root.genieweb.com. (
>> 11 ; serial
>> 10800 ; refresh (3 hours)
>> 3600 ; retry (1 hour)
>> 604800 ; expire (7 days)
>> 86400 ) ; minimum (1 day)
>> com. 86400 NS genieweb.com.
>>
>> ;; AUTHORITY RECORDS:
>> com. 86400 NS genieweb.com.
>>
>> ;; ADDITIONAL RECORDS:
>> genieweb.com. 86400 A 198.147.97.23
>>
>> I wonder if this is what has been causing random COM domain lookups to
>> fail for random people at random places.
>>
>> The time I can see this affecting a name server is if it does a lookup
>> for a domain that's lamely delegated to genieweb.com, and then caches
>> the 'com' reply.
>>
>> I've already left voicemail for the genieweb people.
>>
>>
>> --
>> Sean R. Lynch <seanl@literati.org>
>
>Attachment Converted: "D:\PCNMAIL\ATT16935.ATT"
>

>> But it does bring up an interesting point.... is it that easy to create
>> chaos? They are so far down the food chain, and yet....
>
>BIND 4.9.5-P1 and later (which is 4.9.6 and all versions of 8.*) is not
>susceptible to this corruption. see ftp://ftp.isc.org/isc/bind/src.

Two of the servers that I maintain were running BIND 4.9.5-P1 (now 8.1.1,
thanks isc) and were corrupted.

Michael

> >BIND 4.9.5-P1 and later (which is 4.9.6 and all versions of 8.*) is not
> >susceptible to this corruption. see ftp://ftp.isc.org/isc/bind/src.
>
> Two of the servers that I maintain were running BIND 4.9.5-P1 (now 8.1.1,
> thanks isc) and were corrupted.

i have not been able to reproduce this. when reporting bugs, either here
or to the bind-bugs@isc.org address, please provide a reproducable example.

Paul A Vixie wrote:
>
> > >BIND 4.9.5-P1 and later (which is 4.9.6 and all versions of 8.*) is not
> > >susceptible to this corruption. see ftp://ftp.isc.org/isc/bind/src.
> >
> > Two of the servers that I maintain were running BIND 4.9.5-P1 (now 8.1.1,
> > thanks isc) and were corrupted.
>
> i have not been able to reproduce this. when reporting bugs, either here
> or to the bind-bugs@isc.org address, please provide a reproducable example.

amazing, a technical, apolitical, useful, non assaulting piece of
email ;)

>> >BIND 4.9.5-P1 and later (which is 4.9.6 and all versions of 8.*) is not
>> >susceptible to this corruption. see ftp://ftp.isc.org/isc/bind/src.
>>
>> Two of the servers that I maintain were running BIND 4.9.5-P1 (now 8.1.1,
>> thanks isc) and were corrupted.
>
>i have not been able to reproduce this. when reporting bugs, either here
>or to the bind-bugs@isc.org address, please provide a reproducable example.

Paul..

I apologize for this.. I really did want to get a dump of the database, but
my priorities lay in making my servers functional as soon as possible. I was
merely trying to inform you, as well as the others here who might be interested
that I had also seen the problem in 4.9.5-P1.

Thanks!

Michael