An inadvertent DNS change was made on one of our domains yesterday. While the rest of the ISP world seems to be working correctly after propagation for the fix, I can not get Comcast / Xfinity to clear the stale records. Anyone have suggestions or experience in moving them along?
This was sorted in record time. Thank you both very much!
On Feb 13, 2016, at 7:26 AM, Chris Garrett <chris@aperturefiber.com> wrote:
An inadvertent DNS change was made on one of our domains yesterday. While the rest of the ISP world seems to be working correctly after propagation for the fix, I can not get Comcast / Xfinity to clear the stale records.
Anyone have suggestions or experience in moving them along?
----- Original Message -----
From: "Chris Garrett" <chris@aperturefiber.com>
An inadvertent DNS change was made on one of our domains yesterday. While the rest of the ISP world seems to be working correctly after propagation for the fix, I can not get Comcast / Xfinity to clear the stale records.
Anyone have suggestions or experience in moving them along?
This has been a not altogether infrequent request for a couple decades, all the way back to the time when I was the one who got bit in 96, and a *phone call to NetSol* was the prescription. :-) But -- especially in a world where the people who operate eyeball network DNS customer resolver servers hold the shape of the Internet in their hands, and have been known to monkey with it (by, eg, flooring TTLs on records to times much longer than you set, simply to reduce their own machine load) -- am I the only one who thinks that it might be time for a more formal solution to this problem? Certainly the technology isn't *that* hard to manage/deploy/invent at this late date... Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
We define a new DNS opcode FLUSH and a EDNS FLUSH option. The recursive server send a FLUSH option with a 64 bit cookie computed from a client secret, the server address and zone the QNAME is being looked up in. The answering server stores these along with arrival address provided they arrive over TCP or with a valid EDNS Server Cookie flushing them after X seconds or on a LRU basis if they are consuming too many resources. Answers to this query are also capped at X seconds. This means there has been a 3 way handshake to get put onto the list initially. A server can only flush namespace it has returned answers for. When a flush needs to occur a FLUSH message with the namespace to be flushed is sent to each server in the list with the EDNS FLUSH option that was recorded using the source address address recorded with it. If the EDNS FLUSH option verifies (stripping labels to get the matching domain name used to generate the cookie) then the server flushes the namespace and generates downstream FLUSH messages using its list of clients. Mark In message <1993603000.201301.1455806695384.JavaMail.zimbra@baylink.com>, "Jay R. Ashworth" writes:
----- Original Message -----
From: "Chris Garrett" <chris@aperturefiber.com>
An inadvertent DNS change was made on one of our domains yesterday. While t he rest of the ISP world seems to be working correctly after propagation for t he fix, I can not get Comcast / Xfinity to clear the stale records.
Anyone have suggestions or experience in moving them along?
This has been a not altogether infrequent request for a couple decades, all the way back to the time when I was the one who got bit in 96, and a *phone call to NetSol* was the prescription. :-)
But -- especially in a world where the people who operate eyeball network DNS customer resolver servers hold the shape of the Internet in their hands, and have been known to monkey with it (by, eg, flooring TTLs on records to times much longer than you set, simply to reduce their own machine load) -- am I the only one who thinks that it might be time for a more formal solution to this problem?
Certainly the technology isn't *that* hard to manage/deploy/invent at this late date...
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.co m Designer The Things I Think RFC 210 0 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DI I St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 127 4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (3)
-
Chris Garrett -
Jay R. Ashworth -
Mark Andrews