Re: dnscache and oversized answers

I recommend against using this patch, as is.  Having the recursor fall
back to TCP in this case doesn't fix the problem, since the oversize
response (now obtained via TCP) must still be sent to the client via
UDP.  So its a waste to fall back to TCP, here; and there is also no
reason to think the oversized packet, while technically a violation of
spec, is actually incorrect.

It might be reasonable to truncate the packet and send it truncated to 
the client, of course setting the truncate bit.

I think the rule, 'be liberal in what you accept, conservative in what
you send' applies here.

		--Dean

On 6 Oct 2008, John Levine wrote:

> >On Mon, Oct 06, 2008 at 10:55:12 -0000, John Levine wrote:
> >> One of my users noticed that MX lookups for xo.net were timing out.
> >> The problem turns out to be that XO's name servers are putting in too
> >> many additional section records and are returning oversized answers of
> >> about 540 bytes, which dnscache then throws away.
> >
> >Try this.
> >
> >--- dns_transmit.c~	2008-01-09 00:50:09.559806518 +0200
> >+++ dns_transmit.c	2008-10-06 14:16:28.539802762 +0300
> >@@ -352,7 +352,7 @@ have sent query to curserver on UDP sock
> >       if (errno == error_connrefused) if (d->udploop == 2) return 0;
> >       return nextudp(d);
> >     }
> >-    if (r + 1 > sizeof udpbuf) return 0;
> >+    if (r + 1 > sizeof udpbuf) return firsttcp(d);
> > 
> >     if (irrelevant(d,udpbuf,r)) return 0;
> >     if (serverwantstcp(udpbuf,r)) return firsttcp(d);
> 
> Thanks, that works great.
> 
> From a security point of view, it'd probably be better to check the
> irrelevant bit before falling back to TCP, but that seems like a minor
> bug since at worst it'd provoke redundant lookups to the real server.
> 
> R's,
> John
> 
> 

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