Hi all A late review (I'm sorry I've not been paying much attention here).
[snip]
> Abstract
> This document describes a technique to generate a signed DNS response
> on demand for a non-existent name by claiming that the name exists
> but doesn't have any data for the queried record type. Such answers
> require only one minimal NSEC record, allow online signing servers to
> minimize signing operations and response sizes, and prevent zone
> content disclosure.
I suggest updating the abstract (though it is only a blurb) to indicate
that only one minimal NSEC record is better somehow, i.e, "Such answers
require only one minimal NSEC record rather than many..."
[snip]
> 1. Introduction and Motivation
[snip]
> This document describes an alternative technique, "Compact Denial of
> Existence" or "Compact Answers", to generate a signed DNS response on
> demand for a non-existent name by claiming that the name exists but
> has no resource records associated with the queried type, i.e. it
> returns a NODATA response rather than an NXDOMAIN response. A NODATA
> response, which has a response code (RCODE) of NOERROR and an empty
> ANSWER section, requires only one NSEC record matching the queried
> name. This has two advantages: the DNS response size is smaller, and
> it reduces the online cryptographic work involved in generating the
> response.
I suggest adding another sentence here or rewriting the last sentence to
explicitly mention that multiple NSEC RRs with different owner names
need multiple covering RRSIGs, and it is their computation that is more
expensive than using this compact scheme.
[snip]
> 5. Operational Implications
> For DNSSEC enabled queries, a signed zone at an authoritative server
> implementing Compact Answers will never return a response with a
> response code of NXDOMAIN, unless they have implemented the optional
> response code restoration feature described in Section 4.1.
> Similarly, resolvers not implementing this feature will also not be
> able to return NXDOMAIN. In the absence of this, tools that rely on
> accurately determining non-existent names will need to infer them
> from the presence of the NXNAME RR type in the type bitmap of the
> NSEC record in NODATA responses from these servers.
The authors should clearly state that this draft breaks existing DNS
behavior and returns NOERROR (NODATA) where NXDOMAIN should be returned,
and that is why there are these operational implications. I strongly
suggest including such text that states the issue clearly.
[snip]
> Protocol optimizations that permit DNS resolvers to synthesize
> NXDOMAIN responses, like [RFC8020] and [RFC8198], cannot be realized
> with zones using Compact Denial of Existence. In general, no online
> signing scheme (including this one) that employs minimally covering
> NSEC records permits RFC 8198 style NXDOMAIN synthesis.
> Additionally, this protocol also precludes RFC 8020 style NXDOMAIN
> synthesis for DNSSEC enabled responses.
Is the use of RFC 8198 fine with traditional "covering" NSEC responses
from a zone which also returns compact responses of this draft for
different queries, if some implementation wants to do it? Is there
anything in the protocol that prevents mixed ("covering" as well as this
draft's "compact" scheme) NSEC answers from a single zone? The above
text says "cannot be used with zones", perhaps it can be rewritten to:
".. cannot be realized from Compact Denial of Existence responses."
[snip]
> 7. Implementation Status
> Cloudflare, NS1, and Amazon Route53 currently implement the Compact
> Denial of Existence method.
This current draft appears to be deployed e.g. by Cloudflare, which
trickles down from my resolver as a NOERROR with TYPE128 in the NSEC
bitmap:
[muks@fugu ~]$ dig +dnssec nonexistent.cloudflare.com
; <<>> DiG 1.1.1.20241113133025.476ab2bf87 <<>> +dnssec
nonexistent.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63196
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;nonexistent.cloudflare.com. IN A
;; AUTHORITY SECTION:
cloudflare.com. 300 IN SOA ns3.cloudflare.com.
dns.cloudflare.com. 2359273303 10000 2400 604800 300
cloudflare.com. 300 IN RRSIG SOA 13 2 300 20241211050151
20241209030151 34505 cloudflare.com.
XkLVkEKV14m4KnJ4ed0+/VH8+Ixbd5xvJqHxoqoLwQUCNk+wHcFIBjmU
DYcmDCui5zfodg8eoQKA8fQpHGJsow==
nonexistent.cloudflare.com. 300 IN NSEC
\000.nonexistent.cloudflare.com. RRSIG NSEC TYPE128
nonexistent.cloudflare.com. 300 IN RRSIG NSEC 13 3 300 20241211050151
20241209030151 34505 cloudflare.com.
X0eA7wqAyfGt+bFr42djfk5tz/E6JXYUvRrHjwTGkRu4WZcvXC0Rr8ge
FLsbUDH7dlxXdEIxI9BMHSUijVmqng==
;; Query time: 58 msec
;; SERVER: 144.76.148.97#53(144.76.148.97)
;; WHEN: Tue Dec 10 04:01:51 GMT 2024
;; MSG SIZE rcvd: 380
[muks@fugu ~]$
This signalling is a little unexpected/confusing even to a human who is
expecting an NXDOMAIN rcode. The software will be updated to convert the
TYPE128 to the mnemonic NXNAME, but still, the syntax of the message is
non-intuitive. There may not be a way to do anything about this other
than rewrite the RCODE, or display a message near the RCODE that this is
indeed an NXDOMAIN response.
[snip]
> 8. Security Considerations
[snip]
> scheme will help recover NXDOMAIN visibility for these tools. Note
> that the DNS header is not cryptographically protected, so the
> response code field cannot be authenticated. Thus inferring the
> status of a response from signed data in the body of the DNS message
> is actually more secure. These tools could be enhanced to recognize
> the (signed) NXNAME signal.
The signed NXNAME signal appears to be a side-effect of this design,
rather than a desired requirement. The way this text is written
describes the advantage, but the big disadvantage is that it breaks
existing behavior.
[snip]
At a high level, it is uncomfortable that such changes to the DNS
protocol be merged that change existing basic behavior (removing an
important signal such as NXDOMAIN in existing protocol that deployed
implementations use, requiring updation of at least resolvers to
implement NXNAME -> rcode=NXDOMAIN to "fix" things). Yet this draft is
in last call, which may imply most people here are ok with it.
IMO, as a general guideline this sort of change should be discouraged
though I concede in specific cases behavioral changes to DNS protocol
may be necessary. Are this draft's proposed changes necessary for DNS?
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
