CoreDNS and Caching best practices?

keyser

I'm playing with CoreDNS and I really like the features so far (its a VERY advanced DNS forwarder ;-)

However, one thing eludes me: If I elect to setup CoreDNS as the default and only DNS service on my pfSense and have forwarding to say 8.8.8.8 in the default group, does CoreDNS do lookup caching adhering to received TTL to speed up subsequent lookups of the same name?

I guess I'm asking if Resolver is needed as a backend to CoreDNS to gain DNS caching?

johnpoz

@keyser why would you think a forwarder would not cache? If you want to validate - do a query for something. Then check the ttl a few seconds later, and then again etc.. you will see the ttl counting down.

You would need to use a dns tool that shows this, dig, or nslookup in debug mode.

I am not aware of a single forwarder that does not cache - they would be pointless if they didn't, might as well just point your client to where you are forwarding.

keyser

@johnpoz Good point, but I don't have any clients yet, just playing when the UI.

EDIT: Also CoreDNS is not just a forwarder, as it also has individual block settings pr. group, so it might be more of a "filter" before forwarding than being a DNS forwarder with caching.

One particular reason for the question is that coreDNS would have to be very specific about using multiple individual caches - One for each CoreDNS Group.
Otherwise contamination between groups will happen - IE: names that exist on one forwarding server can at times be found using another group where it's not supposed to because of the forwarding server used in that group.

johnpoz

@keyser agree - if you are going to point to multiple upstream ns that might filter and return or fail to return stuff differently. Then you would for sure need to have a way to have different caches and a method to determine which client uses which cache/filter.

This for sure can be problematic when forwarding to multiple upstream name servers. When you never know which ns would be used, or if they filter the exact same stuff, etc.

Personally I see no point to forwardering - the only possible benefit would be leveraging their filtering - so why would you pick different ns that might filter differently in the first place, etc.

But yeah for example if you want to leverage something like opendns filtering of categories.. You would need a way to make sure your clients you want use this, and its cache. And then other clients be able to use say a more open dns and no filtering. And still benefit from a local cache..

I have not played with this new coredns stuff yet - but does seem like a move to a more robust set of features you will be able to leverage for different use cases.

SteveITS

@keyser said in CoreDNS and Caching best practices?:

forwarding to say 8.8.8.8

adhering to received TTL

This isn't answering your direct question, but because I (somehow) just found out about this, Google DNS truncates TTL to a maximum of 6 hours. (and Quad9 to 12, and Cloudflare does not).

johnpoz

@SteveITS yeah that came up in another thread as well - While not fan of it, at least its manipulation that shouldn't be an issue.. Caching something shorter than the soa intended while still not in line with netizen standards.. Shouldn't cause resolution issues for the end user getting an old expired record.

Simple solution - just resolve ;) not sure of the point of handing all my dns to some service.. Any manipulation of a owners intended ttl I will do myself.. I for example have a min ttl of 3600 vs these stupid 60 or 300 second ones.

SteveITS

@johnpoz I expect it was my comment. Forcing it shorter isn't a technical problem for the user, but it's a "problem" for the domain if its DNS provider has a queries-per-month limit.

Forcing it longer can be if the web site/service is moving. I learned to also block access by firewall rule.

Just wanted to call it out again in the context of OP's comments. I'll stop now. :)

johnpoz

@SteveITS yeah no need stop talking about ttl length is for sure in line with the question about caching.

I also question why dns service would lower the ttl, if some owner of a record wants their ttl to be 24 hours, or a week even. Why would the service running dns want to shorten that to 6 or 12 hours? All that will do is generate more traffic to their service - which off the top seems like want they want.. I mean a 60 second or even 300 second ttl makes no sense.. Unless you were right about ready to move your record to point to a different IP.

Or you are working with dynamic records where the ip could change whenever.

If the service is wanting to generate more traffic - why not take that owners ttl and make it only 1 hour? Or 30 minutes?

The proper thing to do if you ask me is not mess with an owners ttl - if they want to hand out 24 hours, then cache it for 24 hours..

If you want to force users hosting their domains at your authoritative NS to use specific length hey that is their call. But messing with a ttl that you just are a middle man for yeah should honor what the owner has set.. What the user does is up to the user, sorry for example - I don't buy your want/need for a 60 second ttl.. I have been changing them for years and years - and the only issue I have run into is my dns does less queries than you would want it too :)

SteveITS

@johnpoz said in CoreDNS and Caching best practices?:

question why

Best I've got is:

Google wants to say "it's not our fault" sooner
(though they do have a web page to flush a domain from their cache)
Google wants to have slightly better data for how often the domain was queried...how popular it is

Not sure of Quad9's goal. How often a malicious domain is queried?
https://quad9.net/support/faq/#data_collection

keyser

@SteveITS I don’t know how you ended up hijacking this thread to discuss truncating TTL, but I hope someone wiill still be able to answer the original question:

Does CoreDNS do caching or not, and if it does, does it separate caches for each CoreDNS group to prevent cross name resolution polution?

Gertjan

@SteveITS said in CoreDNS and Caching best practices?:

Google DNS truncates TTL to a maximum of 6 hours.

Of course they do.
Why ? Short answer : you would do the same thing (if you worked for them).
Google (8.8.8.8) prefers that you have to come back as much a possible for fresh DNS info. This gives them a very important info : they start to know in quasi real time where and when go visit something. That info will be thrown in the 'profiler' just for 'you' so adds can be sold with an even higher price.

If there wasn't a local cache in the forwarder like pfSense, neither in the end users device, then for every DNS request the DNS server has to be consulted. I won't be surprised that the DNS will start to 'throttle' your requests. There is probably a sweet spot, but 0 TTL would for sure create problems.

Ok, my answer has some in it, but I'm pretty sure I'm not wrong.