[DNSOP] Re: Add TTLs to DNS errors (draft-homburg-dnsop-de ttl-00.txt)

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]