[Dnsmasq-discuss] Two questions about the cache and how dnsmasq forwards queries

Simon Kelley simon at thekelleys.org.uk
Mon Feb 15 11:04:22 GMT 2010


SamLT wrote:
> Hello
> 
>>> This also happen for almost every other query. Especially, every domains
>>> that I _really_ would like dnsmasq to use its cache for seems to suffer
>> >from this problem. But it looks like only those CNAMEs have this
>>> TTL of 1s, the NAMEs
>>> (eg: www.l.google.com) have a more reasonnable TTL.
>> Can you try sending test queries direct to the upstream
>> nameserver(s), bypassing dnsmasq. This is starting to look like a
>> problem there:
>>
>> dig @196.32.200.12 www.google.com
>>
>> Send the whole result of doing that: there's also a possibility that
>> the answer is confusing dnsmasq's "answer extraction" code, so
>> seeing the whole thing would be good.
>>
>>
> 
> Sure:
> 
> 	dig @196.32.200.12 www.google.com
> 	
> 	; <<>> DiG 9.6.1-P3 <<>> @196.32.200.12 www.google.com
> 	; (1 server found)
> 	;; global options: +cmd
> 	;; Got answer:
> 	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54385
> 	;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0
> 	
> 	;; QUESTION SECTION:
> 	;www.google.com.                        IN      A
> 	
> 	;; ANSWER SECTION:
> 	www.google.com.         0       IN      CNAME   www.l.google.com.
> 	www.l.google.com.       258     IN      A       74.125.159.147
> 	www.l.google.com.       258     IN      A       74.125.159.99
> 	www.l.google.com.       258     IN      A       74.125.159.103
> 	www.l.google.com.       258     IN      A       74.125.159.104
> 	www.l.google.com.       258     IN      A       74.125.159.105
> 	www.l.google.com.       258     IN      A       74.125.159.106
> 	
> 	;; AUTHORITY SECTION:
> 	google.com.             194344  IN      NS      ns4.google.com.
> 	google.com.             194344  IN      NS      ns1.google.com.
> 	google.com.             194344  IN      NS      ns2.google.com.
> 	google.com.             194344  IN      NS      ns3.google.com.
> 	
> 	;; Query time: 3448 msec
> 	;; SERVER: 196.32.200.12#53(196.32.200.12)
> 	;; WHEN: Mon Feb 15 11:09:42 2010
> 	;; MSG SIZE  rcvd: 220
> 
> 
> 

So there's your problem, the TTL of the first CNAME in the chain is zero,

www.google.com.         0       IN      CNAME   www.l.google.com.>


Strange, when I do the same thing (via my ISPs server) I get
;; ANSWER SECTION:
www.google.com.		9620	IN	CNAME	www.l.google.com.
www.l.google.com.	220	IN	CNAME	www-tmmdi.l.google.com.
www-tmmdi.l.google.com.	53	IN	A	66.102.9.99

Maybe your ISPs DNS server is playing games?

> 
> 
> 
> 
> 
>> If you can increase the retry time in the client's resolvers, that
>> would help a lot, so would speeding up the downstream nameserver.
>> There may be nothing you can do about that, but one thing to look at
>> is any traffic shaping you have on your connection. My home internet
>> connection is via a cable modem, and when my ISP applies "traffic
>> shaping" it uses a simple leaky-bucket filter which causes the
>> latency on the uplink to go very high, and performance gets very
>> laggy. I use traffic-shaping to limit the upstream traffic to just
>> less then the cap, and things work much better. The recipe   I
>> followed is here:
>>
>> http://www.greenend.org.uk/rjk/2004/tc.html
>>
> 
> 
>>> Doesn't dnsmasq keep a list of forwarded queries? As I can see on the log,
>>> it often forwards several times the same query instead of waiting for
>>> either a reply or a given timeout.
>> No, it doesn't, to keep the memory footprint down. Even if it did,
>> it would have to forward retries. DNS traffic is mainly UDP, and
>> there's nothing dnsmasq can send back to a client to say "I'm
>> working on it, just wait". The client will launch queries onto the
>> net and either get a reply, or timeout and fail.
>>
> 
> Touching client's configuration isn't an ideal solution for me, I could
> 'rate-limit' on the LAN side the NEW udp port 53 packets (with iptables),
> but this is still far from ideal. I'd rather only 'rate-limit' similar dns
> queries. Any idea?
> 
> And thanks for the tc link, I will certainly do some traffic-shaping at some
> point.
> 
> 
>> So, either speed up the upstream servers (maybe by unloading your
>> link) or increase the timeout in your clients. (1 second is low, for
>> Unix systems, it may be the default for Windows.)
>>
>> Cheers,
>>
>> Simon.
>>
>>
> 


A nameserver which takes less than three seconds to answer would solve 
all your problems. If that's caused by latency in the link to your ISP, 
traffic shaping will help a lot. If the problem is with the server (and 
it's messing with TTLs too), then either shout at your ISP or maybe use 
openDNS or Google's public DNS service?


Cheers,

Simon.



More information about the Dnsmasq-discuss mailing list