DNS Caching Asus Stock / Merlin?

[Authority]

It's at Parental control > DNS Filtering

Intersting thanks. Not an intuitive place to put it from a technical perspective, but I guess that makes sense. Thanks so much.

Note this still doesn't answer why I'm getting so many lookups hitting my DNS servers when, if I understand correctly, dnsmasq should be resolving? See screenshot a couple threads back.

Thanks again.

 

[ColinTaylor]

The only way I can think of that would cause that would be if you had put something in the following fields:

LAN > DHCP Server > DNS and WINS Server Setting > DNS Server 1 or 2

 

[Authority]

I agree, and I haven't done that. I also haven't checked that box to pass on DNS requests to upstream DNS server (presumably bypassing dnsmasq).

When I check my devices, they indicate the router IP as their DNS servers.

So yeah...

 

[ColinTaylor]

The vast majority of the traffic (and the only one identified in the screenshot) is coming from Sonic which might imply that it's something specific to this device. Maybe try rebooting/resetting that and see if it makes a difference. Perhaps it's hanging onto some old DNS setting from way back.

Are you seeing any other devices being named in the report?

 

[RMerlin]

Another thing to keep in mind is that DNS caching is controlled by the TTL of a record. Once a record expires due to its TTL, another query must be sent upstream to refetch a fresh record.

 

[Authority]

The vast majority of the traffic (and the only one identified in the screenshot) is coming from Sonic which might imply that it's something specific to this device. Maybe try rebooting/resetting that and see if it makes a difference. Perhaps it's hanging onto some old DNS setting from way back.

Are you seeing any other devices being named in the report?

Hi - sorry if that's unclear. SONIC is my ISP and the name I assigned to my network. That screen shot is all the traffic coming from my LAN (X-Box, Sonos, Macs, Windows, Android, Dropcam, etc.).

 

[Authority]

Another thing to keep in mind is that DNS caching is controlled by the TTL of a record. Once a record expires due to its TTL, another query must be sent upstream to refetch a fresh record.

That's probably the answer then, is there out of curiosity a way to override/ignore the TTL and use the cache?

 

[Nullity]

That's probably the answer then, is there out of curiosity a way to override/ignore the TTL and use the cache?

https://github.com/RMerl/asuswrt-merlin/wiki/Custom-config-files

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

 

[RMerlin]

That's probably the answer then, is there out of curiosity a way to override/ignore the TTL and use the cache?

It's usually not a good idea to override a TTL. The zone owner can have a very good reason to enforce a shorter TTL. For example, when I know I'm going to have to change one of my customer's DNS entries (change of ISP, moving to a new hosting provider, etc...), then I will reduce the TTL to 5 or 10 minutes, and bring it back to 4 hours once the move is completed.

 

[Authority]

It's usually not a good idea to override a TTL. The zone owner can have a very good reason to enforce a shorter TTL. For example, when I know I'm going to have to change one of my customer's DNS entries (change of ISP, moving to a new hosting provider, etc...), then I will reduce the TTL to 5 or 10 minutes, and bring it back to 4 hours once the move is completed.

I hear you... but look at these numbers for less than a day. Crazy no? 3000 lookups in half a day? Hard to see these and believe cache is working.

I just turned on the parental controls thing lets see if it changes. If it does, it means dnsmasq wasn't on right?

 

[RMerlin]

I hear you... but look at these numbers for less than a day. Crazy no? 3000 lookups in half a day? Hard to see these and believe cache is working.

Just to see if dnsmasq's own cache isn't getting overwhelmed by having too many requests (it defaults to 1500 entries), see this post here on how to monitor cache recycling:

http://www.snbforums.com/threads/dns-servers.23828/#post-177346

I just turned on the parental controls thing lets see if it changes. If it does, it means dnsmasq wasn't on right?

Dnsmasq always runs as the DNS proxy and resolver on Asuswrt, it's not tied to parental control.

 

[Authority]

OK you win... (no surprise)

Aug 3 22:55:15 dnsmasq[2524]: cache size 1500, 0/7582 cache insertions re-used unexpired cache entries.

Aug 3 22:55:15 dnsmasq[2524]: queries forwarded 2458, queries answered locally 1829

But still doesn't explain the thousands of uncached. Think it's a TTL? It has to be super short to get thousands in half a day.

 

[ColinTaylor]

I think the only way to know for sure what's going on is to try my suggestion from post #13. But be warned that it writes a lot of information to syslog which can make internet responses sluggish.

# killall dnsmasq
# dnsmasq -q --log-async
# tail -f /tmp/syslog.log
Aug  4 12:57:03 dnsmasq[2311]: query[A] crl.microsoft.com from 192.168.1.55
Aug  4 12:57:03 dnsmasq[2311]: cached crl.microsoft.com is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: forwarded crl.microsoft.com to 194.168.4.100
Aug  4 12:57:03 dnsmasq[2311]: forwarded crl.microsoft.com to 194.168.8.100
Aug  4 12:57:03 dnsmasq[2311]: reply crl.microsoft.com is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: reply crl.www.ms.akadns.net is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: reply a1363.dscg.akamai.net is 62.253.72.89
Aug  4 12:57:03 dnsmasq[2311]: reply a1363.dscg.akamai.net is 62.253.72.81
Aug  4 12:57:03 dnsmasq[2311]: query[A] www.microsoft.com from 192.168.1.55
Aug  4 12:57:03 dnsmasq[2311]: forwarded www.microsoft.com to 194.168.4.100
Aug  4 12:57:03 dnsmasq[2311]: reply www.microsoft.com is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: reply toggle.www.ms.akadns.net is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: reply www.microsoft.com-c.edgekey.net is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: reply www.microsoft.com-c.edgekey.net.globalredir.akadns.net is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: reply e10088.dspb.akamaiedge.net is 23.195.58.125
Aug  4 12:57:03 dnsmasq[2311]: query[A] pki.google.com from 192.168.1.55
Aug  4 12:57:03 dnsmasq[2311]: cached pki.google.com is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: forwarded pki.google.com to 194.168.4.100
Aug  4 12:57:03 dnsmasq[2311]: reply pki.google.com is <CNAME>
Aug  4 12:57:03 dnsmasq[2311]: reply www3.l.google.com is 62.253.72.178
Aug  4 12:57:03 dnsmasq[2311]: reply www3.l.google.com is 62.253.72.148
Aug  4 12:57:03 dnsmasq[2311]: reply www3.l.google.com is 62.253.72.168
Aug  4 12:57:03 dnsmasq[2311]: reply www3.l.google.com is 62.253.72.158

 

[Authority]

Stats for yesterday attached. Around 20K lookups for "A" records, 3K of which are Rhapsody alone.

Interesting numbers, I realize it doesn't really matter but I find it curious why caching doesn't address that. Guessing TTL. Will try suggestion above to get more data.

Thank you all.

 

[Nullity]

I think caching is meant more for large networks, partly because the cache gets refreshed often. In a large network, they would possibly get 75% of all users resolving the same host within ~30min.

What I mean is, are you sure the cache is not working properly? Perhaps the cache simply refreshes often, causing it to be less useful than expected. I know back when I used DynDNS I was pissed at my ISP's DNS for caching stuff too (imo) long. I dunno how Google's DNS seems to be synced within minutes after a change.



Regarding Rhapsody, my SmartTV constantly (~1/sec) ARPs the LAN gateway, and my Roku pings the gateway every second. The IoT things seem to abuse DNS/ARP/ICMP. They seem to use the proto as more of a keep-alive or simply as a way to watch something closely. IoT is gonna be a pain in the butt...

 

[System Error Message]

the DNS server in routerOS drops expired entries from the cache and does the DNS query if it is not in the cache once only when it is requested.

In routerOS the same NAT rules can be used on ICMP as a way to reduce ping abuse going outside your network and you can set a rate limit accompanied by another rule to drop or do something else with it. You can always redirect the packets to the problematic device for fun in routerOS.

 

[ColinTaylor]

Stats for yesterday attached. Around 20K lookups for "A" records, 3K of which are Rhapsody alone.

Well I did a bit more investigation, turning on query logging for dnsmasq and using "dig". Caching appears to be working fine.

The "problem" is that whilst direct.rhapsody.com has a TTL of 300 seconds (quite a common setting), it is just a CNAME for e11751.b.akamaiedge.net which is set at 20 seconds. So that's 4320 upstream requests a day, assuming your Sonos box is just spamming the internet all day.

 

[Authority]

Well I did a bit more investigation, turning on query logging for dnsmasq and using "dig". Caching appears to be working fine.

The "problem" is that whilst direct.rhapsody.com has a TTL of 300 seconds (quite a common setting), it is just a CNAME for e11751.b.akamaiedge.net which is set at 20 seconds. So that's 4320 upstream requests a day, assuming your Sonos box is just spamming the internet all day.

Wow THANKS! Curious, do you think that's a mistake or by design? If I am understanding correctly, the TTL is preventing caching?

Is it possible to force a TTL of like 3600 in dnsmasq? It seems like that'd be so much more efficient and unlikely to break anything. Thoughts? That one site would drop from 4320 requests per day to 24.

 

[ColinTaylor]

Wow THANKS! Curious, do you think that's a mistake or by design? If I am understanding correctly, the TTL is preventing caching?

I wouldn't say that it's not caching, it is. It's just that the cache entry only lasts for 20 seconds.

Is it a mistake? I don't know, it's not really my area of knowledge. But given that Akamai is a content delivery network I might speculate that it is by design. If the server that you're connected to (i.e. e11751.b.akamaiedge.net), or the route to it, gets congested then they can change the CNAME of direct.rhapsody.com to point to another, less congested, server. That process is probably automatic. This would be important for a streaming service so as to minimise disruptions. You wouldn't want to wait for 5 minutes (let alone an hour) for the service to resume because 1 route went down.

Is it possible to force a TTL of like 3600 in dnsmasq right? It seems like that'd be so much more efficient and unlikely to break anything.

Nullity earlier linked to the dnsmasq doc's which suggest you can force a minimum TTL time, but everything I've read about that says it's generally considered a bad idea.

 

[kvic]

If I correctly understand OP’s chart on #34, Sonos is probably the guy with room for improvement.

Over 24 hours, 3567 requests to direct.rhapsody.com. That’s average 2.48 request per min. Apparently Sonos engineers are polling the server for something rather than using more intelligent techniques.

If you try CollinTaylor’s suggestion, and force min cache ttl in dnsmasq to 300s, you save half of the requests. If you increase to 3600 as you wanted (btw, coincidentally that’s the max allowed by dnsmasq), you save by a factor of 24, you end up with about 150 requests everyday.

Each day 150 or 3567 requests make no difference for a single user like yourself. Shouldn’t be terribly worried about the issue. But good to experiment if you have the time and report back your numbers.

One of the key take-aways seems to me is that if people are worried, they probably should throw away their Sonos. The issue might have demonstrated how poolrly Sonos is engineered inside. Who knows what other stupid stuff their engineers are doing under the hood.

3567 requests per box per day is fine on its own. What if one day Sonos starts selling like hot cakes, my goodness.

(Now I think of Apple)