I forgot to include the referred to work. Corrected inline below.
Op 17-03-2025 om 15:58 schreef Willem Toorop:
Op 17-03-2025 om 15:37 schreef Petr Špaček:If it would be up to me it is not meant to be completely optional. Either you SHOULD do this, or otherwise SHOULD do one of the other measures.On 3/17/25 14:18, Willem Toorop wrote:If this draft is meant to be completely optional I propose to change it to "Intended Status: Informational", prequotetty please.Op 17-03-2025 om 13:45 schreef Ralf Weber:On 17 Mar 2025, at 17:53, Shumon Huque wrote:I couldn't remember exactly what text we put in. Looks like section 8.3 (Other Considerations) 2nd paragraph acknowledges the existence of parent centric implementations, but yes, that is not the same as saying optionally not doing it. I think this text was put in after consultation with RalfWeber.In this thread alone we have heard 3 implementations stating they are not going to do it vs 1 implementation which already it. That ratio with clear message from implementers does not seem like good candidate for a standard to me.There are some good reasons to strongly recommend it. It improves security and excludes certain types of attacks [1] and [2].
[1] Klein, A., Shulman, H., and M. Waidner, "Internet-Wide Study of DNS Cache Injections", n.d., <https://ieeexplore.ieee.org/abstract/document/8057202>.
[2] https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf
A SHOULD also means. If you do not do it, explain why not and what alternate methods you have in place to counter these issues.Also, re-querying the addresses of the names in the root NS RRset, as Knot resolver's priming implementation is doing, should not be trivialized. If more resolvers would at least agree to do that, then that would already be worth it.Correct and this is the only section of the draft that the Akamai resolvers comply with in this draft. The draft also mentions ZONEMD and local root, which supply a better protection for root and the TLD level (as almost allYes, local root in combination with ZONEMD provides equal protection where it counts most (as mentioned in the draft), but NS revalidation is more generic, and doesn't require more that just DNS queries. It is easy to just comment out `harden-referral-path: yes` in unbound.conf (as Redhat Enterprise Linux has done for example).TLDs are signed currently) then trying to do what this draft proposes.>From an implementation perspective I stand by my argument that the increased complexity in resolver operations caused by this draft does not outweigh the perceived benefit of it. With perceived benefit I mean is that DNSSEC is supposed to detect data forgery and for that it does not matter if I get the correct data from the wrong server, or to paraphrase Geoff Houston you can pick up your DNSSEC answer from the street and still validate it.But many zones are still not DNSSEC signed. Making sure that responses are answered by the correct authoritative name servers (NS revalidation), protects the unsigned zones and the non-validating resolvers as well, and as such improves the security of the internet as a whole. The more resolvers do this, the better.It looks like other implementers (Knot) came to the same conclusion.Well, maybe not intentional, but Knot resolver does revalidate the priming query. They practice NS revalidation where it counts the most of all right now and have been doing so since 2017.This is from my Knot Resolver days so I think I can comment. The code you reference came from this:https://gitlab.nic.cz/knot/knot-resolver/-/issues/220 https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/391As you can see, this was meant to implement root priming, and indeed it is special-coded for root priming and nothing else. It does not handle disappearing zone cuts and other stuff like that mentioned in the draft. It hardly can count as 'implementation' of this draft.It is doing precisely what this drafts suggests, but restricted to only the root (where it count the most of all). The internet would already be in a better shape if more resolvers would start doing this. Even if it is only the root._______________________________________________ DNSOP mailing list --dnsop@ietf.org To unsubscribe send an email todnsop-le...@ietf.org
OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
