Peplink DNS Caching Not respecting TTLs?

Hey Guys!

I was recently running a training off of a peplink MAX BR2 Pro 5G and we started to run into an issue with a web app failing to load.

nslookups and pcaps from client devices showed that we were being served stale DNS records only behind the peplink (which is configured to DNS cache and to use 8.8.8.8 & 1.1.1.1 as it’s upstream DNS servers).

I flipped over to a cellphone mobile hotspot and had zero issues with the web app. So, I disabled the Peplink DNS cache and our web app failures disappeared.

The web app dev team confirmed that

  • DNS records (with a 60s TTL) were pointed towards a new instance IP ~45mins before they shut down the old instance (and released the old IP).
  • The time of the web app failing directly correlates with the shutdown of the old instance

My question here is, Is the “DNS Caching” option in incontrol ALSO configuring the DNS cache to enforce a minimum TTL and if so what is it?

If peplink is performing aggressive DNS caching, the min TTL default value should…

  • Be made publicly made known.
  • Be made configurable

There’s a huge difference between

  • Enabling DNS caching
  • Potentially serving stale DNS records by not respecting RFC1035

Aggressive caching can royally screw up web applications, this issue almost threw our training off the rails…