Re: dns cache beyond ttl - viasat / exede

On 10/7/2019 3:23 PM, William Herrin wrote: You don't happen to have some documented examples of this do you? I could use examples of stuff that broke and was hard to diagnose and fix due to unexpected proxying behavior for an argument I'm having elsewhere. I'll see what I can dig up from

Re: dns cache beyond ttl - viasat / exede

On Tue, Oct 8, 2019 at 4:22 AM Tony Finch wrote: > William Herrin wrote: > > Depending on the implementation, DNS pinned browsers may not recognize a > > change to your IP address until the browser is stopped and restarted. > > I thought DNS pinning was only for the lifetime of the web page, so

Re: dns cache beyond ttl - viasat / exede

William Herrin wrote: > > You may be looking at a web browser "feature" called "DNS pinning." This is > used to defeat the "DNS rebinding" attack on javascript that would allow a > web site to instruct a browser to scan the interior behind its user's > firewall by having an attacker rotate the IP

Re: dns cache beyond ttl - viasat / exede

On 10/7/19 9:08 AM, Mike wrote: >    I am wondering if perhaps this is due to some kind of (known?) > bug in the embedded dns cache/client in the client satellite modem, or > if there is another plausible explanation I am not seeing. It compounds > my problem slightly since I have to continue

Re: dns cache beyond ttl - viasat / exede

On Mon, Oct 7, 2019 at 11:56 AM Brielle wrote: > On 10/7/2019 12:15 PM, William Herrin wrote: > > This is the action of the TCP accelerator. TCP has a "long fat pipe" > > problem where high-delay links (like a trip to geostationary orbit and > > back) demolish throughput. To combat this,

Re: dns cache beyond ttl - viasat / exede

On 10/7/2019 12:15 PM, William Herrin wrote: On Mon, Oct 7, 2019 at 10:13 AM Brielle > wrote: * Responding to three way handshake before the other end actually does (nmap -sT remote host ends up with every port being 'open' but closing connection right away)

Re: dns cache beyond ttl - viasat / exede

On Mon, Oct 7, 2019 at 10:13 AM Brielle wrote: > * Responding to three way handshake before the other end actually does > (nmap -sT remote host ends up with every port being 'open' but closing > connection right away) > This is the action of the TCP accelerator. TCP has a "long fat pipe"

Re: dns cache beyond ttl - viasat / exede

On Mon, Oct 7, 2019 at 9:08 AM Mike wrote: > My dns TTL's are all 300 seconds, and I have noticed that once I > update the A records with the new addresses, most (but not all) web > clients begin using the new address within 5 minutes or so. However, > there is a persistent set of stragglers

Re: dns cache beyond ttl - viasat / exede

Hi Mike, The UT uses a combination of caching, prefetching, and spoofing to accelerate web traffic for users. On the terrestrial side, there is a cluster of accelerators that also take part in that process. What is the "lag" time that you have observed? Also, do you know if your clients are

Re: dns cache beyond ttl - viasat / exede

On 10/7/2019 10:08 AM, Mike wrote:    I am wondering if perhaps this is due to some kind of (known?) bug in the embedded dns cache/client in the client satellite modem, or if there is another plausible explanation I am not seeing. It compounds my problem slightly since I have to continue

Re: dns cache beyond ttl - viasat / exede

I've seen similar issues (years ago) where some ISPs didn't honour DNS TTLs, and would instead cache the results a LOT longer. On Mon, Oct 7, 2019 at 9:08 AM Mike wrote: > Hello, > > > I am moving a number of web sites from one colo to another, > re-numbering them in the process, and I

dns cache beyond ttl - viasat / exede

Hello,     I am moving a number of web sites from one colo to another, re-numbering them in the process, and I have run into an interesting issue I'd like to solicit feedback on.     My dns TTL's are all 300 seconds, and I have noticed that once I update the A records with the new addresses,