I repeat what I said at the beginning:
I think this is a good idea. If it had an upper bound.
On 14. 07. 26 15:20, Philip Homburg wrote:
No. We already have protocol to protection for those who care - sign
your zones. This proposal adds a signal which cannot be signed so the
traditional answer (DNSSEC) is not applicable. That's why I ask about
the upper limit.
Do you agree that for unsigned zones, there is essentially no additional
attack vector. Therefore, software can limit the error TTL the same way
the TTL of normal record data is limited. No need to say anything
about it.
Agreed, but when client receives this error it might not even be
possible to distinguish if a zone is signed or not. (Even if it were,
why should upper bound be different for signed and unsigned?)
DNSSEC is indeed different. However, DNSSEC cannot prevent bad data being
cached in various parts of the DNS system. DNSSEC can prevent treating
bad data as authentic. But bad data can still lead to a DoS.
Yes. And these bad data have, so far, were very limited in how long they
can stay around and cause problems.
In particular validators that are part of forwarders tend to have almost
no way to prevent a DoS if they get fed bad data.
Indeed, on-path attacker always wins. I don't we need to rehash that.
Forwarding/on-path is no the only scenario. Right now BIND caches
validation failures for 1 second at most - currently. If attacker
manages to spoof single answer for a signed zone, say 'com DNSKEY', it
will get caches for 1 second and retried.
What I don't like is proposal to allow upstream to override this 1
second hard-coded value with unsigned value without an upper bound.
If this logic was acceptable for the WG then RFC 9520 authors _would not
have_ to pick a value.
The unique thing about RFC 9520 is that the authors had to decide what to
do in the absence of any information from the upstream DNS server.
We are basically in the same situation here. The information cannot be
trusted, it might have been even fabricated by an attacker. Thus my ask
for an upper bound.
What is different now is that the client receives a TTL from the server
and can treat that like any other information received from other servers.
That said. If we decide that 5 minutes is enough then we can just drop this
draft and move on. Though in that case, I don't understand previous
discussions about the impact of 'NS .' or returning SERVFAIL in
case of DELEG-only delegations.
I don't understand.
Having upper bound and flexibility in what auth side/upstream sends as
preferred value is different than hard-coding a value, isn't it?
Perhaps we need to discuss this over a drink in Vienna!
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
