Hello,
Not sure where to point this... I was wondering if anybody knows an inroad
to reach AT&T and Verizon systems people to flush their caches for "
proofpoint.com"?
Any help is greatly appreciated!
Steven Briggs
The generally accepted and scalable way to accomplish this is to advertise your freshness preferences using the SOA record of your domain. It would be pretty tricky to make this work with a swivel chair type system for every domain and host on the internet. You would have to contact every user and ask them to invalidate the caches, after asking their recursing server operator to do the same.
-Laszlo
Yeah...I know. Unfortunately, the domain was "mishandled" by our
registrar, who imposed their own TTLs on our zone, THEN turned it back over
to us with a 48HR TTL. Which is very bad.
I really appreciate all of your help, guys!
Been discussed and nothing has been done:
http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf
https://www.dns-oarc.net/files/workshop-201005/DNS-Emergency-Alert-System.pdf
Will keep happening until someone decides to act.
-Hank
Seems like the DNS protocol already addresses this issue with TTLs. The issue is that people sometimes regret the TTLs they chose (or their service provider chose for them). Any reason registrars commonly choose a 2 day TTL? Would they be just as well off with a 1 day TTL (my guess is that they would)?
--Blake
Hank Nussbacher wrote the following on 4/16/2014 11:32 AM:
That's almost calling for a name-and-shame.
Looks to be godaddy. No surprise then.
Be grateful it is only 48 hours. Verzion (not Verizon Wireless) frequently has multi-week outages affecting multiple customers in the NYC area.
One of the DS3s some customer circuits ride only works when there is no usage. Once there is usage massive errors occur. This has been going on for 6 - 8 weeks. Circuit usually comes back up when they test it. They admit there is a problem, they have no clue what it might be. All these customers are served out of the same CO.
It's not hard to use WHOIS to lookup the registrar of each of the
nameservers for proofpoint.com
(ns1.proofpoint.us, ns3.proofpoint.us).
Long TTLS are appropriate for a production zone, but in my
estimation, it is improper for
a registrar to impose or select by default a TTL longer than 1 hour,
for a newly published or newly changed zone.
The TTL can and should be reasonably low initially and
automatically increased gradually over time,
only after the zone has aged with no record changes and confidence is
increased
that the newly published zone is correct.
There was a study on an unrelated topic a presented at a NANOG or ARIN
meeting a few years back. I don't recall the exact details. The
interesting bit was the analysis they did on DNS caching to see the
impact from varying the TTL. I don't remember the exact numbers, but
short TTLs exhibited only a small increase in query rate over long
ones.
There's really no driving need to set the TTL higher than 1 hour,
ever, under any circumstances.
-Bill
The default TTL should be 300 secs, esp with everyone switching A records
to cloud providers, imho.
That way, who ever is the SOA and the zone master, can update it based on
design scale or sla of that provider.
DNS needs a protocol refresh anyways.
Dennis B.