AT&T / Verizon DNS Flush?
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 On Apr 16, 2014, at 6:15 AM, Steven Briggs <stevenbriggs@gmail.com> wrote:
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 ᐧ
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! ᐧ On Wed, Apr 16, 2014 at 10:14 AM, Laszlo Hanyecz <laszlo@heliacal.net>wrote:
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
On Apr 16, 2014, at 6:15 AM, Steven Briggs <stevenbriggs@gmail.com> wrote:
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 ᐧ
On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said:
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.
That's almost calling for a name-and-shame.
Looks to be godaddy. No surprise then. On Wed, 16 Apr 2014 12:56:59 -0400 Valdis.Kletnieks@vt.edu wrote:
On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said:
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.
That's almost calling for a name-and-shame.
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. On Apr 16, 2014 7:30 PM, "John Peach" <john-nanog@peachfamily.net> wrote:
Looks to be godaddy. No surprise then.
On Wed, 16 Apr 2014 12:56:59 -0400 Valdis.Kletnieks@vt.edu wrote:
On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said:
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.
That's almost calling for a name-and-shame.
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. -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, April 16, 2014 12:57 PM To: Steven Briggs Cc: nanog@nanog.org Subject: Re: AT&T / Verizon DNS Flush? On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said:
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.
That's almost calling for a name-and-shame.
On Wed, Apr 16, 2014 at 11:56 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said:
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.
That's almost calling for a name-and-shame.
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. -- -JH
On Wed, Apr 16, 2014 at 2:25 PM, Jimmy Hess <mysidia@gmail.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (8)
-
Dennis B -
Eric Wieling -
Jimmy Hess -
John Peach -
Laszlo Hanyecz -
Steven Briggs -
Valdis.Kletnieks＠vt.edu -
William Herrin