Mailinglist Archive: opensuse-security (520 mails)

["Reckhard, Tobias" <tobias.reckhard@xxxxxxxxxxx>]

Hi list

I thought this post from the DNS mailing list might be interesting.

Tobias

> -----Original Message-----
> From: Mrs. Brisby [mailto:mrs.brisby@xxxxxxxx] 
> Sent: Wednesday, July 03, 2002 15:28
> To: dns@xxxxxxxxxxxxx
> Subject: Re: Packet reconstructioni
> 
> 
> On Wed, 2002-07-03 at 08:29, Lars Uffmann wrote:
> > Laurent G. Bercot wrote:
> > >>I'm wondering this topic isn't discussed more in-depth on 
> this list. 
> > > 
> > > 
> > >  Why should it be ? it's off-topic.
> > >  This list is about BIND replacements for Unix ; the 
> problem lies within
> > > the BIND DNS client library. End of matter.
> > 
> > Sure. But CERT *recommends* usage of bind9 as a solution to 
> the buggy 
> > resolver library vulnerability. Earlier in this thread there was a 
> > dispute wether a caching nameserver (ie. dnscache) can 
> protect clients 
> > at all. I would like to know wether this is true or not. I 
> assume there 
> > are many people having the necessary expertise to answer 
> this question 
> > on this list, so it's not completely off-topic, IHMO.
> 
> So CERT is wrong. whoopie. If CERT recommends you jump off a bridge,
> then I won't cry if you actually do it... Irregardless of the pressure
> from your "security staff"
> 
> CERT recommends that you ignore the RFC's pertaining to DNS; 
> i've always
> suspected the ISC corrupts CERT... but at least CERT can 
> pretend they're
> doing "the right thing" by still giving the right answer:
> 
> <<Upgrade to a corrected version of the DNS resolver libraries>>
> 
> a caching nameserver should _not_ attempt to decode the underlying
> responses (rrdata) of the answer section for a request it didn't
> originate. IF IT DID, dnscache would have to be updated [or have a
> rulefile] for each RR that __could__ be sent.
> 
> This is impossible to do without breaking RFC 1123, 1035 and 
> 1034 (type
> extensibility: dan has a good article about this at
> http://cr.yp.to/djbdns/newtypes.html )
> 
> 
> if you simply need time and have to upgrade hundreds of 
> machines, simply
> cut off users from talking DNS to the outside world (yes: kill
> dnscache).
> 
> Set up tinydns for your intranet so they can use "mail" and 
> "proxy" and
> all that good stuff, and only permit them to use http proxies 
> (the HTTP
> protocol puts the name of the host in the query when doing 
> "HTTP PROXY")
> 
> And congrats are in order: You've successfully avoided 
> replacing the DNS
> resolver on all the broken machines by cutting off their privleges. As
> they become compliant and decide, okay, we'll do it the right way, add
> them to your dnscache $ROOT/ip/
> 
>