Subject: Re: [dnsext] perhaps we should reintroduce "resimprove"

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Feb 2012 09:44:39 +0100

On Thu, Feb 09, 2012 at 03:09:26PM +0000,
 paul vixie <[email-masked]> wrote 
 a message of 34 lines which said:

> remove (B) and section 3, 

Why? It seems fine to me (even if He-Who-Must-Not-Be-Named disagrees).

> progress it not as an improvement but as a security and resiliency
> requirement (so, a proposed standard) in the face of the "ghost domain"
> problem.

It seems to me that this draft does not currently address the ghost
domain problem. It mandates revalidation at the parent when the
records expire, but it does not say anything about the rules that
allow an authoritative server to overwrite the old TTL with a new
value, thus preventing expiration.

Would it be a better idea to use this draft as a starting point to
work on the issues proposed by the ghost domains paper? (Replacing >=
by > in the credibility rules and other measures.)
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: paul vixie <[email-masked]>
Date: Fri, 10 Feb 2012 09:01:04 +0000

> Why? It seems fine to me (even if He-Who-Must-Not-Be-Named disagrees).

because arguing those merits will take time, and the other parts of the
proposal which are less controversial should not have to wait while
those arguments complete.

> by > in the credibility rules and other measures.)

i think there's some editorial flaw that leads to the above observation.
perhaps an explicit reference to RFC 2181 and some examples about how NS
replacement will work in light of credibility rules, would help explain
why this draft obviates the ghost domain problem.

for example the ghost problem appears to be about glue names (A/AAAA
RRsets referred to by NS RRs) whereas the resimprove solution set seems
to be only about the NS RRsets. but the effect of removing the NS RRsets
due to revalidation will be to purge the cache of any glue names which
were subdomains of those zone apexes.

paul

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 10 Feb 2012 10:17:51 +0100

Hi Stephane,

> by > in the credibility rules and other measures.)

This replacement is wrong.  We must have '=' in >= to pick up zone
changes from the same server.  We must have revalidation at the parent
for the ghost-domain problem, it is simply a case of having the NS TTL
expire (i.e. meaning, the NS RRset can be replaced with a newer one but
the NS TTL does not increase).

Best regards,
   Wouter

---

From: Florian Weimer <[email-masked]>
Date: Fri, 10 Feb 2012 15:50:06 +0100

> the NS TTL does not increase).

This is correct for the immediate delegation.  However, it does not
help if there is yet another delegation.  This one would have
attacker-controlled TTLs in the parent (child) and child (grandchild).

Therefore, I fear that an approach which just picks up the data from
the child while keeping the TTL from the parent does not actually
address the issue of crafted TTLs.  Some sort of recursive,
tree-dependent approach appears to be required.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Feb 2012 10:23:34 -0500

On 10/02/2012 04:17, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Stephane,
>
>> work on the issues proposed by the ghost domains paper? (Replacing>=
>> by>  in the credibility rules and other measures.)
>
> This replacement is wrong.  We must have '=' in>= to pick up zone

<no-hat>

Strictly speaking when a resolver gets a RRset there are 4 different 
actions it can take:
	
Store: Applicable when the RRset does not exist
Replace: Applicable when there is a prior set
Ignore: always an option
Delete: This says that the resolver has lost confidence in the cached.

For Credibility Greater ">"  the following options make sense
	Store, Replace

For Credibility Equal "="   the following options make sense
	Ignore, Delete

For Credibility Less "<"
	Ignore

If you do Replace on NS on "=" you get ghost domains, because
NS set and Glue are the only data that resolver will see in an answer 
that it potentially has in cache.
If you insist on allowing "Replace" on equal then you MUST implement 
"Fetch NS from child" and "Fetch all glue" to combat the ghost domains 
and still have Kaminsky defense.

	Olafur

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 10 Feb 2012 07:58:11 -0800

On Feb 10, 2012, at 7:23 AM, Olafur Gudmundsson wrote:
> NS set and Glue are the only data that resolver will see in an answer that it potentially has in cache.
> If you insist on allowing "Replace" on equal then you MUST implement "Fetch NS from child" and "Fetch all glue" to combat the ghost domains and still have Kaminsky defense.

One other option:
replace-with-min-TTL:  A replacement cache entry's new TTL is min(current TTL on the entry, new TTL).

The problem with ghosted domains is not changing the NS RRSET, its that changing the NS RRSET is also resetting the TTL.  Yet given "Newer vs older data of the same credibility", isn't newer more meaningful (apart from the stickyness problem)?

But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new.

And overall, I think replace-with-min-TTL should be standardized. Because even "Credibility > replace" can have a problem:  The parent wants a deliberate shorter TTL for the NS set, but the child can override it.  

For example, .com wants a 2 day TTL, but the child overrides it with a 7 day TTL, which still gives a 7-day 'no-revocation' window for any preseeded domains.  This could be even worse for various dynamic DNS services which allow delegation.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 10 Feb 2012 19:27:28 +0000

> One other option: replace-with-min-TTL:  A replacement cache entry's new
> TTL is min(current TTL on the entry, new TTL).

This is the approach we're taking in BIND 9, at present.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Feb 2012 15:08:00 -0500

<still no-hat>
> The problem with ghosted domains is not changing the NS RRSET, its that changing the NS RRSET is also resetting the TTL.  Yet given "Newer vs older data of the same credibility", isn't newer more m…
TTL stretching was a REAL BAD idea, and must be stamped out.

> But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new.

I prefer that resolver perform Delete rather than this, that forces the 
resolver to reevaluate the delegation.
In the case of resolver that does "Fetch NS" upon seeing the referral 
and adheres to RFC2181 credibility rules, it will always ignore NS set 
in authority section.

If a zone wants changes to propagate quickly it should use a smaller 
TTL. Resolvers should implement a MAX TTL both to purge old data faster, 
and to adopt faster to changes.

>
>
> And overall, I think replace-with-min-TTL should be standardized. Because even "Credibility>  replace" can have a problem:  The parent wants a deliberate shorter TTL for the NS set, but the child can override it.
>
well in the case of TLD's the TTL on referrals ranges from 600 (10min) 
to 345600 (4 days)  with 1 day as the median value and most common one.
Based on a sample of 180 google.<TLD> domains out of 310 TLD's.

Do you want everyone that has a parent with 600-3600 TTL on parent side 
NS records to force that policy on all their children?

	Olafur

---

From: "Blacka, David" <[email-masked]>
Date: Fri, 10 Feb 2012 22:58:40 +0000

> TTL stretching was a REAL BAD idea, and must be stamped out.

What do you mean by "TTL stretching"?  Are you inventing new DNS terms?

> I prefer that resolver perform Delete rather than this, that forces the resolver to reevaluate the delegation.

So, every time a zone operator modifies the apex NS RRset, resolvers around the world instantly (as they query the zone for positive answers) invalidate the cached NSs and go back to the parent.  That seems like suboptimal behavior to me.

> In the case of resolver that does "Fetch NS" upon seeing the referral and adheres to RFC2181 credibility rules, it will always ignore NS set in authority section.

Fair enough, but why do I have to do that extra query in order to solve this problem?

> If a zone wants changes to propagate quickly it should use a smaller TTL. Resolvers should implement a MAX TTL both to purge old data faster, and to adopt faster to changes.

Agreed.  However, I don't think there is any advice what a good max TTL value should be.  2 days? 7 days?

> well in the case of TLD's the TTL on referrals ranges from 600 (10min) to 345600 (4 days)  with 1 day as the median value and most common one.
> Do you want everyone that has a parent with 600-3600 TTL on parent side NS records to force that policy on all their children?

I don't, at least.  I'd like to preserve as much of the current DNS behavior here as we can (thus, I really don't like the bailiwick rule that the paper authors recommend, since it will force all zones to be parent-centric, which is a major change to current behavior.)

I would think that if the rule was:

Credibility >
   Replace, update TTL
Credibility ==
   Replace, keeping existing TTL

then you would get the desired behavior.  That is, the first NS RRset from the child would update the RRset as normal, allowing the child to have a different NS RRset and whatever TTL they choose.  And when the child changes their NS RRset, it propagates at the same speed it does today (faster than the TTL expiration).  But the resolver will always revaluate the parent delegation after at most 2 TTL intervals.

--
David Blacka                          <[email-masked]> 
Principal               Verisign Infrastructure Engineering

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 13 Feb 2012 12:18:38 -0500

<still no-hat>

> What do you mean by "TTL stretching"?  Are you inventing new DNS terms?
Well I have been using this for a while, and I do recall where the 
definition originated. The issue this term is describing:

When a resolver sees an RRset in an response, that it has in its cache,
it compares the RRset's and if identical it updates the TTL to reflect 
the RRset in the response.

> So, every time a zone operator modifies the apex NS RRset, resolvers around the world instantly (as they query the zone for positive answers) invalidate the cached NSs and go back to the parent.  T…

I wish you would not use the word: optimal
as that is setting a value judgment without explicitly saying what you 
are optimizing.
In the past trying to do the optimal (packet count) thing vs the safest 
thing has got us in problems and I do not want to see that again.

What happens depends both on the behavior of the resolver and the 
authoritative server that is asked.
For example if the authoritative server is using Minimal-answer (i.e. no 
authority section on positive answers).
Then the resolver does not see a new version of the NS set and is denied 
the opportunity to following ``optimizations''
	- discover that the NS set has changed
	- Stretch the TTL on the NS set

> Fair enough, but why do I have to do that extra query in order to solve this problem?

Again here you are using value judgment as what is better:
	fewer queries vs safety
If all resolvers in 2007 had implemented "Fetch NS" and applied 
credibility rules Kaminsky attack would never have become an issue.

Similarly when authoritative severs use minimal answers the resolver 
only has the parent side NS set, what should the resolver do?
keep the parent side NS or lookup the Childs NS set.

> Agreed.  However, I don't think there is any advice what a good max TTL value should be.  2 days? 7 days?

Personally I think 1 day if a fine upper bound.

> Credibility>

Of the two alternatives, I like "Fetch NS" much better than the logic above.
Having said that I also like "Minimal answers" for authoritative servers 
as that forces resolvers to act more predictably :-)

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Feb 2012 13:58:50 -0500

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 +1-571-434-5468

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

---

From: "Blacka, David" <[email-masked]>
Date: Mon, 13 Feb 2012 18:59:27 +0000

On Feb 13, 2012, at 12:18 PM, Olafur Gudmundsson wrote:

> Well I have been using this for a while, and I do recall where the definition originated. The issue this term is describing:

Did you mean "I don't recall"?

> it compares the RRset's and if identical it updates the TTL to reflect the RRset in the response.

OK.  I agree this is a bad idea.  Although, in various implementation's defense, *why* it is a bad idea isn't necessarily obvious.  If you are thinking about improving the cache efficiency of your implementation, and not thinking about "cache pinning" problems, TTL stretching seems like a good idea.

> as that is setting a value judgment without explicitly saying what you are optimizing.
> In the past trying to do the optimal (packet count) thing vs the safest thing has got us in problems and I do not want to see that again.

In the past, doing overly aggressive things have caused serious problem, too.  My concern with the use of "Delete" it that is has the potential for creating packet storms when a busy zone changes its apex NS RRset.

> What happens depends both on the behavior of the resolver and the authoritative server that is asked.
> For example if the authoritative server is using Minimal-answer (i.e. no authority section on positive answers).
> Then the resolver does not see a new version of the NS set and is denied the opportunity to following ``optimizations''

Sure, minimal-answer does solve a set of problems, but I don't understand the consequences of widespread use of that feature.

> Again here you are using value judgment as what is better:

No, I'm suggesting that both are important.

> If all resolvers in 2007 had implemented "Fetch NS" and applied credibility rules Kaminsky attack would never have become an issue.
> 
> Similarly when authoritative severs use minimal answers the resolver only has the parent side NS set, what should the resolver do?

I don't know what they "should" do.  I suspect they keep the parent side NS, as that it what the resolution algorithm will naturally lead.

> Personally I think 1 day if a fine upper bound.

What??? And disenfranchise the millions of 2 day TTLs??

> Of the two alternatives, I like "Fetch NS" much better than the logic above.

Why?  I'll admit to not really understanding exactly what "Fetch NS" entails.  When does the resolver decide to issue the NS queries?

> Having said that I also like "Minimal answers" for authoritative servers as that forces resolvers to act more predictably :-)

Clearly, you think that the current DNS behavior of returning the apex NS RRset in the authority section provides no value.  My position is that I don't know that it doesn't, and thus would not like to throw that protocol feature away unnecessarily.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 13 Feb 2012 14:24:00 -0500

> Did you mean "I don't recall"?

Yes I meant "don't Recall"

> In the past, doing overly aggressive things have caused serious problem, too.  My concern with the use of "Delete" it that is has the potential for creating packet storms when a busy zone changes i…

What I wrote originally was the resolver could do one of two things: 
Ignore or Delete.

If it does ignore the NS RRset will time out and at some point after 
that the resolver will find out about the change.

> Sure, minimal-answer does solve a set of problems, but I don't understand the consequences of widespread use of that feature.

The main consequence is that large set of resolvers will use the Parent 
side NS record.

> What??? And disenfranchise the millions of 2 day TTLs??

Number is up for discussion and should be configurable, but for the 
record this is what the current version of Unbound does.
I suspect that most TTL decisions consist of pulling numbers out of a 
hat or looking at what someone else is doing because they know better :-)

> Why?  I'll admit to not really understanding exactly what "Fetch NS" entails.  When does the resolver decide to issue the NS queries?

The only time Resolver is required to do  "Fetch NS" is when it 
discovers the existence of the delegations by getting a referral from 
the parent.

> Clearly, you think that the current DNS behavior of returning the apex NS RRset in the authority section provides no value.  My position is that I don't know that it doesn't, and thus would not lik…

I would phrase it differently "Currently having the apex NS RRset 
included in authority section of positive answers provides ability for 
badly written resolvers to misbehave to the determent of the Internet"

Background: I have been researching how to do Domain Name Transfers when 
DNSSEC is enabled on the domain. In doing that I realized that not all 
resolvers are following the protocol. The first thing I needed to 
educate myself was that using the word "Transfer" was a bad idea.
So I now call it "changing the DNS operator".
One of the questions to answer was when can the old operator turn off 
service ?
everyone's first guess is "NS TTL"
To that the followup question: which NS ?
second guess is "max of the two NS's TTL"
but that fails for the resolvers that stretch the TTL and have strong 
affinity for the domain going through the operator change, except when 
the old operator is doing "minimal answers" and the resolvers can not 
cheat.

	Olafur

---

From: Florian Weimer <[email-masked]>
Date: Mon, 13 Feb 2012 23:04:22 +0100

> in the protocol.  (The paper says as much.)  Adding revocation isn't

I think before we could do that, we'd need to know how quickly the
revocation needs to take effect.  If the time period is rather short,
this rules out many potential approaches.

I'm also not sure if this is an actual problem.  For a couple of
years, we had unremovable names in COM & NET due to the way those
zones were provisioned, and while this was abused, very likely not
even intentionally, the world didn't end.  (Verisign fixed this prior
to the introduction of DNSSEC.)
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext