[dnsext] Ghost domain names

[Edward Lewis <[e-mail]>]

I looked briefly at the paper 
(http://www.isc.org/files/imce/ghostdomain_camera.pdf) and don't see 
this as a "vulnerability" but rather a result of a lack of revocation 
in the protocol.  (The paper says as much.)  Adding revocation isn't 
going to be easy.

The IETF has never published a detailed document on how a cache 
should be managed.  It's never been an "interoperability issue." 
(This came up at NANOG 54 again, as a result of 
http://www.nanog.org/meetings/nanog54/abstracts.php?pt=MTkwOCZuYW5vZzU0&nm=nanog54.)

My assumption, and perhaps this is just an assumption, is that caches 
clip the TTL to be 1 week.  At least that is what BIND was measured 
as doing at some time in the past.  With this, anyone can then assume 
about a 1 week "fuzz" in the deletion of a domain name.

Beyond that, it's going to get complicated.

When this issue has come up in the path, it eventually goes into - 
what do you do about applications that persist in use of the data 
that has expired.  Like an open SSH connection that lasts days and 
days when the AAAA record used to start it had a TTL of an hour?  Or 
an open web page from which links are clicked.  DNS-based data will 
get stale, the one control element we have is the TTL.

I'd just write this:

A general purpose DNS cache SHOULD limit the TTL of any record set it 
accepts to 1 week.  An application using DNS data is RECOMMENDED to 
refresh the DNS data at least once per week.

Why a week?  It's convenient to write.  A better time span would be 
to ask the TLD's what they are willing to accept as a "fuzz" factor 
when deactivating a domain name - and how long are they willing to 
retain historical registration records.  But a week, otherwise, just 
seems good.

I don't think this is a DNSEXT issue, I don't think a protocol change looms.

Oh, and as far as TTL "stretching" aka, refreshing the set in the 
cache, this is a toss up.  If a recursor is reacting to a referral, 
it won't have to look at any NS set unless it does not find the set 
in the cache.  Maybe here the TTL of what's in the cache matters - 
I'd only consider fetching the NS set again if I think I'll need it 
before the currently held set TTLs out.  With DNSSEC, I'd want to 
pre-fetch long enough I that I have a newly validated set in time to 
plop on top of the old set.  I guess I'd never "stretch" a TTL, I'd 
get ready to bring on a new copy before losing the previous one. 
(Analogous to the process of re-freshing signatures in DNSSEC.)

The issue seems to be - traceability and replaceability.  Once a 
delegation is removed we need to continue to tie the delegation to 
the source until no cache has it around anymore.  And we need to see 
all of the old delegation for a name to "go away" before reviving the 
name.  I think that's the ultimately the goal.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext