<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Difference between cacheing B data and I
data</title></head><body>
<div>Referring to the thread that started with this message:</div>
<div><br></div>
<div
>https://lists.dns-oarc.net/pipermail/dns-operations/2008-November/00<span
></span>3362.html</div>
<div><br></div>
<div>And focusing on the question of "why is data that is
demonstrated to be invalid after obtaining a complete collection of
relevant RR sets (that is "Bad" or "Bogus" data
treated differently than data for which there is an failure in
obtaining all needed RR sets to make a validation
determination?"</div>
<div><br></div>
<div>In other words, why is Bad/Bogus data treated differently than
Indeterminate data in caches?</div>
<div><br></div>
<div>The reason for my verbosity is that Florian has a point in this
message:</div>
<div><br></div>
<div
>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg02183.ht<span
></span>ml</div>
<div><br></div>
<div>(BTW, finding this message triggered a bug report to the archive
master...yet more of a long story that needn't be retold here.)</div>
<div><br></div>
<div>In my opinion, not vetted obviously by the DNSEXT WG (as no one
else seems to have chimed in), the terms Bad and Bogus are equivalent
in the document. The difference in terminology dates back to the
introduction of Bogus into the document late in the team's editing
process.</div>
<div><br></div>
<div>So, focus back on bad vs. indeterminate.</div>
<div><br></div>
<div>I've had experience in a similar area - that is in testing
delegations. Lame servers refers to servers that are not
authoritative for a domain of the question received and they respond
indicating that. A server that is not responsive, has no address
record, etc., is not lame, it is unresponsive. The difference is
that a lame server is telling you clearly that it should not be
consulted with the question. A lack of a response could indicate
any number of network related errors - the fix might be in
reconnecting a device, adjusting routing, lengthening a timeout,
restarting a process, and so on and so on. The troubleshooting
of each is quite different, as well as the mean time to repair.
(And "mean time to miracle" referring to problems that seem
to take care of themselves.)</div>
<div><br></div>
<div>Back to DNSSEC data. Bad or bogus is determined by relying
on a pile of "good" records, these records aren't in need of
an update until their individual TTLs expire. So there's no need
to go back and ask again. Now, if the RR set you are testing
fails validation, there's little chance the outcome will change
anytime soon. The time it is held in the bad/bogus state might
as well be the same as the NXDOMAIN TTL as it's essentially the same
state of the data.</div>
<div><br></div>
<div>I'd add a caveat to this. If a query is issued and a
response comes that fails validation, my gut is that the recipient
ought not give up listening until the timeout for an unanswered query
expires or another response is heard that is accepted.</div>
<div><br></div>
<div>Indeterminate data is different. The rationale for not
caching it as bad for the same TTL is based on the reasons why it
failed to be validated. The reason for the failure might be
transitory and unrelated to any server authoritative for any piece of
the trust "chain." For this reason, asking again might
clear things up.</div>
<div><br></div>
<div>In re-examining the message from Florian, this is the penultimate
paragraph, diced up to try to interpret it:</div>
<div><br></div>
<div># My conclusion is that validators forwarding to non-validating
caches</div>
<div># just don't work and should be deprecated.</div>
<div><br></div>
<div>Issue 1 - we can't deprecate this because the distinction can't
be made.</div>
<div><br></div>
<div># This also means that indeterminate answers are relegated to an
odd</div>
<div># corner case, and once that has happened, key rollovers and
redelegation</div>
<div># with key changes become much less daunting: If the involved
zone</div>
<div># operators make a mistake, RRsets may end up in the BAD cache
described</div>
<div># in RFC 4035, which should be a rather temporary
situation.</div>
<div><br></div>
<div>I really can't figure this out. Indeterminate answers are a
product of the use of UDP. We can't rule them out, even if they
are rare in healthy networking environments (healthy as in low packet
loss).</div>
<div><br></div>
<div># On top of that, lack of a response from a name server for a
query which</div>
<div># should result in a response with Secure data could mean that
the</div>
<div># (unsigned) referral has been tampered with, so a cache can be
expected</div>
<div># to periodically recheck the delegation chain.</div>
<div><br></div>
<div>It is possible that the query was dropped on the way out, the
response dropped on the way back. I think leaping to the
conclusion that there was a tampering is wrong. If anything, an
inserted response will come sooner. If tampering is happening,
it's probably systemic and there would be no way "around"
the tampering anyway (so just give up).</div>
<div><br></div>
<div># This will actually improve operator experience because mistakes
are</div>
<div># fixed much quicker.<br>
</div>
<div>Mistakes are not the same as attacks. DNSSEC isn't there to
help with mistakes, entering the wrong key is going to be an
ongoing error, not something retries will fix. That is, a key
with the wrong value (or DS or RRSIG) is going to feed a bad/bogus
state which is a hard error until someone changes the data. But
if the server with the data is up and down, then we will have
indeterminate when it is down and that will pass with retries.</div>
<div><br></div>
<div>As a PS - someone privately added that Florian's idea was a good
one. It might be that I am still missing the point. What I
have read is an assessment of the perils of treating bad/bogus
differently than indeterminate. What I haven't seen is what
would be an improvement. I'm not trying to be confrontational,
I'm trying to understand the proposal.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
NeuStar</div>
<div><br></div>
<div>Never confuse activity with progress. Activity pays
more.</div>
</body>
</html>