>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. 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. In particular validators that are part of forwarders tend to have almost no way to prevent a DoS if they get fed bad data. >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. 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. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
