Thanks for pointing out the attack of using random NS RRSets ("NS
$RANDOM.victim.example") with zero TTL. However, I believe this is still
mitigated well by RFC 9520 Section 3.2: "When an incoming query matches a
cached resolution failure, the resolver MUST NOT send any corresponding
outgoing queries until after the cache entries expire.".
An attacker might be able to bypass this cache by using a different AAAA QNAME
each time to initiate the attack. Excluding DNSSEC, this would still only
result in at most minor amplification due to the resolver's NS limit. (The
attacker must emit two packets in each round (the query and a large NS
response), whereas the victim must emit K small NXDOMAIN responses, where K is
the resolver's NS limit.)
We should be able to measure the actual amplification achieved by this attack
in modern recursive resolver implementations. If it is large, then we should
consider possible mitigations.
--Ben
________________________________
From: zuop...@cnnic.cn <zuop...@cnnic.cn>
Sent: Sunday, January 7, 2024 1:59 AM
To: Ben Schwartz <bem...@meta.com>; dnsop <dnsop@ietf.org>
Subject: Re: Re: [DNSOP] Fw: New Version Notification for
draft-zuo-dnsop-delegation-confirmation-00.txt
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
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
ZjQcmQRYFpfptBannerEnd
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<mailto:bemasc=40meta....@dmarc.ietf.org>
Date: 2024-01-03 23:49
To: zuop...@cnnic.cn<mailto:zuop...@cnnic.cn>; dnsop<mailto:dnsop@ietf.org>
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<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
