i think offering more than one wire encoding to get the same outcome
would be the opposite of simplicity. if the ietf were to decide that
dnssec had been a mistake and universal deployment was no longer to be
sought, then we would want to look carefully at the features it had
contained and consider other ways to get them.
if it helps, imagine that the lifetime total cost of an "if" statement
in an open source program is about $10,000.00.
re:
Zhiwei Yan wrote on 2024-01-19 00:42:
Hello, Paul,
Simplicity and ease of use are fundamental features that enable the
large-scale deployment of a protocol. You are right, everyone hopes for
the widespread deployment of DNSSEC to mitigate various security risks.
While, this draft addresses two key aspects: on one hand, we aim to
delve into the security vulnerabilities associated with delegation, and
on the other hand, propose corresponding solutions that can be achieved
through extending DNS, or assuming DNSSEC and simpler optimizations
based on DNSSEC.
BR,
Zhiwei
在 2024/1/7 18:01, Paul Vixie 写道:
zuop...@cnnic.cn wrote on 2024-01-06 22:59:
...
Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –like
attack, because it allows a DNSSEC-validating resolver to generate
negative answers within a range. ...
have you looked at dns rrl?
... But if a NSEC3 RR has an Opt-Out flag, it can’t be used for
aggressive negative caching. In addition, DNSSEC adoption rate
remains low in some area and this situation may not change
significantly over a long period of time for policy reasons.
i think as long as we keep adding features that are only necessary
because dnssec lacks certain features or is not universally deployed
or both, then dnssec will lack certain features or not be universally
deployed or both. please be careful what you wish for.
Compared to DNSSEC, the draft is relatively simple, it uses OPT RR
option to confirm NS record only when a resolver is requesting
address (Glue record) of delegation points. And it is compatible with
current DNS protocol.
it will always be within our powers to add complexity. google for "dns
camel" to find out one author's thoughts about how to use that power
more wisely.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
