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<mailto:internet-dra...@ietf.org>
Date: 2024-01-02 14:42
To: Peng Zuo<mailto:zuop...@cnnic.cn>; Zhiwei Yan<mailto:y...@cnnic.cn>
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<https://www.ietf.org/archive/id/draft-zuo-dnsop-delegation-confirmation-00.txt>
Status:
https://datatracker.ietf.org/doc/draft-zuo-dnsop-delegation-confirmation/<https://datatracker.ietf.org/doc/draft-zuo-dnsop-delegation-confirmation/>
HTMLized:
https://datatracker.ietf.org/doc/html/draft-zuo-dnsop-delegation-confirmation<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
