Eyeball Networks and DNS (was: Re: Xfinity stale DNS)

Thu Feb 18 23:17:03 UTC 2016

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 at baylink.com>, "Jay 
R. Ashworth" writes:
> ----- Original Message -----
> > From: "Chris Garrett" <chris at 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 at 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 at isc.org