I’m noticing the drop box and YouTube have certain characteristics that make me suspicious that they are not following DNS time to live protocols. For instance, a drop box audio link that I listen to occasionally in a web browser will hang up if I resume it after the browser has been sitting idle for a while. I have to reload the dropbox page to get it to start playing again. I’m also seeing that YouTube on safari will also hang up after a certain amount of time and not play until the page is re loaded. Check it out guys.
This is a good topic, I will use this response to expand on that with additional context.
TTL (time to live) is a concept we find in many places in technology and in DNS, in particular.
Due to the nature of DTTS® (Don’t Talk To Strangers®), we re-write the publicly-offered TTL based on the needs of the local network.
For example, without adam:ONE, using the dig command line to query for www.youtube.com:
dig @8.8.8.8 www.youtube.com
will yield something similar to:
;; ANSWER SECTION:
www.youtube.com. 6714 IN CNAME youtube-ui.l.google.com.
youtube-ui.l.google.com. 187 IN A 172.217.164.238
youtube-ui.l.google.com. 187 IN A 172.217.165.14
youtube-ui.l.google.com. 187 IN A 172.217.0.238
youtube-ui.l.google.com. 187 IN A 172.217.1.174
youtube-ui.l.google.com. 187 IN A 172.217.1.14
youtube-ui.l.google.com. 187 IN A 172.217.164.206
However, on a network with adam:ONE:
dig www.youtube.com
will yield the following with YouTube filtering enabled:
;; ANSWER SECTION:
www.youtube.com. 120 IN A 216.239.38.119
Alternatively, will yield the following with YouTube being unfiltered:
;; ANSWER SECTION:
www.youtube.com. 120 IN A 172.217.1.174
www.youtube.com. 120 IN A 172.217.1.14
www.youtube.com. 120 IN A 172.217.164.206
www.youtube.com. 120 IN A 172.217.164.238
www.youtube.com. 120 IN A 172.217.165.14
The number before IN is the TTL offered to the DNS client. Even if Google offers a TTL of 6714 as in the example, above, if the query is made via adam:ONE, the TTL is over-written to a maximum of 120. If endpoints are not honouring the TTL of 120, that is possible. Our experience in Google Chrome browser is that when the TTL expires, it does re-query. That is not the case with macOS Safari, for example, nor with built-in macOS apps, including the AppStore app itself. As much as we like the smaller footprint and performance of Safari, we support and recommend Chrome and Chromium-based browsers only.
I trust the above answers your question/comment on website TTL. It is a function of the app/browser and OS vs a function of the website you’re visiting.
Does this mean that the browsers dont respect the TTL from the gateway? What other TTL are they given? And how does safari get away with not requerying? BTW the issues I described are appearing on Chrome for PC.
It would require a deeper dive in your specific scenario, and Chrome does offer great tools if you use the address bar for chrome://net-internals/#dns for example. Google’s full kb article is at https://support.google.com/chrome/a/answer/6271171?hl=en
We drink our own lemonade and don’t experience anything on Chrome on any platform, broadly speaking of this nature, unless there is some method of Chrome getting DNS answers from somewhere else, such as:
- multi-homed device (say you have wifi as well as ethernet, and it gets its DNS preferentially from a non-adam:ONE network adaptor, but default route is via adam:ONE)
- host is using DoT and able to get DNS answers (but DTTS it preventing actual communication to IPs looked up via alternate DNS method)
- browser is defaulting to DoH and able to get DNS answers, but also not able to use those destinations because of DTTS
If none of these scenarios apply to you, I’d suggest the Google Chrome net-internals for troubleshooting your specific browser settings.