Thanks for your valuable comment !
negative caching (RFC 2308) and failure caching (RFC 9520) can mitigate
NXNSAttack–like attack to some extent, but I don’t think they are sufficient
enough, because for a resolver that adopts these 2 RFCs only caches failure
answer for a single record at a time, it can't avoid queries for a large number
of random NS records.
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. 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.
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.
zuop...@cnnic.cn
From: Ben Schwartz
Date: 2024-01-03 23:49
To: zuop...@cnnic.cn; dnsop
Subject: Re: [DNSOP] Fw: New Version Notification for
draft-zuo-dnsop-delegation-confirmation-00.txt
Thanks for this proposal. I note the following text on the motivation in
Section 1.3:
If a malicious Delegated Zone specifies a large amount of
fake NS pointing to victim zones, much more queries from recursive
DNS to victim zones will be triggered. This protocol vulnerability
can be abused to launch new types of attacks, such as NXNSAttack.
Current mitigation measures against such attacks are based on
optimizing DNS software implementations, such as limiting the number
of outgoing queries for NS glue.
I think this is a helpful description of the motivation, but it omits some
additional mitigations that already exist, such as negative caching (RFC 2308),
failure caching (RFC 9520), and Aggressive NSEC (RFC 8198). I don't see any
argument in this draft that the current mitigations are insufficient, or are
likely to fail in the future.
This draft adds a significant amount of complexity to the DNS protocol. I
don't think it makes sense to add complexity if our current mitigations are
sufficient.
--Ben Schwartz
From: DNSOP <dnsop-boun...@ietf.org> on behalf of zuop...@cnnic.cn
<zuop...@cnnic.cn>
Sent: Tuesday, January 2, 2024 2:35 AM
To: dnsop <dnsop@ietf.org>
Subject: [DNSOP] Fw: New Version Notification for
draft-zuo-dnsop-delegation-confirmation-00.txt
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
ZjQcmQRYFpfptBannerEnd
Hi all,
We submitted a draft about DNS delegation confirmation. In the
current DNS delegation mechanism, a delegated zone/child zone can specify any
NS records at the zone apex without requiring confirmation from the zone
maintaining Glue records of these NS record. This could be exploited to lunch
new types of attacks such as NXNSattack. This draft suggests a lightweight
and backward-compatible mechanism to mitigate the risk of these attacks.
Any comments are welcome!
zuop...@cnnic.cn
From: internet-drafts
Date: 2024-01-02 14:42
To: Peng Zuo; Zhiwei Yan
Subject: New Version Notification for
draft-zuo-dnsop-delegation-confirmation-00.txt
A new version of Internet-Draft draft-zuo-dnsop-delegation-confirmation-00.txt
has been successfully submitted by Zhiwei Yan and posted to the
IETF repository.
Name: draft-zuo-dnsop-delegation-confirmation
Revision: 00
Title: A lightweight DNS delegation confirmation protocol
Date: 2024-01-01
Group: Individual Submission
Pages: 13
URL:
https://www.ietf.org/archive/id/draft-zuo-dnsop-delegation-confirmation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-zuo-dnsop-delegation-confirmation/
HTMLized:
https://datatracker.ietf.org/doc/html/draft-zuo-dnsop-delegation-confirmation
Abstract:
Delegation occurs when an NS record is added in the parent zone for
the child origin. In the current DNS delegation mechanism, a
delegated zone/child zone (see Section1.1 for definition of delegated
zone) can specify any NS records at the zone apex without requiring
confirmation from the zone maintaining Glue records of the NS record.
Recently, new types of attacks that exploit this flaw have been
discovered. This draft suggests a protocol-level solution for DNS
delegation confirmation to reduce the risk of these attacks.
The IETF Secretariat
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
