Re: Dishonest Forks? | Was - Re: [Namedroppers-honest] Brian Smith asks: Who is Dean Anderson?

Good points. I stand corrected.  

It still takes 26 million packets to succeed.  The security of highly
classified information is not obtained by finding a safe that can't ever
be broken, but ensuring that the safe can't be broken in less time than
the security guards pass by on their rounds. If the security guards
check every 15 minutes, you need a 15 minute safe.  Likewise, a
intrusion detection system ought to easily notice a 26 million packet
attack before it is successful.

Still, the cases you cite can be mitigated to some extent.

Case 1 can be fixed by discarding the authority records in the SOA.  
(information only)  I can't think of any time SOA queries are used by
non-sysadmins except for zone transfers (TCP, no worries) and in
self-priming scenarios, and self-priming seems like a dead issue to me.  
What is the harm in a spoofed, uncached SOA with no useful glue? (which
probably can't be spoofed before the real server replies?) An excess or
delayed zone transfer?

Case 2 seems a problem.  Perhaps nodata should be cached.

I think Case 3 & 4 can be fixed by actually looking for complete set of
ANY matching records in cache.

I'd be OK with these changes, applied to 1.05.

		--Dean

On Thu, 11 Mar 2010, Matthew Dempsky wrote:

> On Thu, Mar 11, 2010 at 5:03 PM, Dean Anderson <[email protected]> wrote:
> > Sending more queries of the x1.av8.net name are answered out of cache,
> 
> A query for "A? x1.av8.net" will be answered out of cache, because
> x1.av8.net has an NXDOMAIN response.  But an attacker won't issue an
> "A? x1.av8.net" query, because there are other queries he can issue
> that dnscache *won't* answer out of cache.
> 
> Try a few of these queries against an installation of dnscache, and
> you'll notice that each of them results in dnscache sending a query to
> an authoritative server instead of answering out of cache:
> 
> 1. dig -t soa google.com @$DNSCACHEIP
> 2. dig -t cname google.com @$DNSCACHEIP
> 3. dig -t any ipv6.l.google.com @$DNSCACHEIP
> 4. dig -t any _jabber._tcp.google.com @$DNSCACHEIP
> 
> Explanations:
> 
> For #1, dnscache simply never caches SOA records.  Any SOA query will
> *always* be sent upstream.
> 
> For #2, dnscache doesn't cache NODATA CNAME responses; if a domain
> name *does not* have a CNAME record, then an explicit CNAME query will
> result in a CNAME query being sent upstream.
> 
> For #3 and #4, when dnscache receives an ANY query, it only checks the
> cache for NXDOMAIN or CNAME, NS, PTR, MX, and A records.  If a domain
> name exists but does not have any of these records (e.g.,
> ipv6.l.google.com only has AAAA records and _jabber._tcp.google.com
> only has SRV records), then an explicit ANY query will result in an
> ANY query being sent upstream.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494