forked from shuque/id-dnssec-compact-lies
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-huque-dnsop-compact-lies.txt
392 lines (231 loc) · 13.8 KB
/
draft-huque-dnsop-compact-lies.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
Internet Engineering Task Force S. Huque
Internet-Draft Salesforce
Intended status: Standards Track C. Elmerot
Expires: 31 August 2023 Cloudflare
27 February 2023
Compact Denial of Existence in DNSSEC
draft-huque-dnsop-compact-lies-00
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 NSEC record and allow online signing servers to
minimize signing operations and response sizes.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 August 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Huque & Elmerot Expires 31 August 2023 [Page 1]
Internet-Draft Compact Denial of Existence in DNSSEC February 2023
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Distinguishing NXDOMAIN from Empty Non-Terminal Names . . . . 3
3. Responses for Non-Existent Names . . . . . . . . . . . . . . 3
4. Responses for Wildcard Matches . . . . . . . . . . . . . . . 4
5. Responses for Empty Non-Terminals . . . . . . . . . . . . . . 4
6. Operational Implications . . . . . . . . . . . . . . . . . . 4
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
11.1. Normative References . . . . . . . . . . . . . . . . . . 5
11.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction and Motivation
One of the functions of the Domain Name System Security Extensions
(DNSSEC) [RFC4033] [RFC4034] [RFC4035] [RFC5155] is "Authenticated
Denial of Existence", i.e. proving that a DNS name or record type
does not exist. Normally, this is done by means of signed NSEC or
NSEC3 records. In the precomputed signature model, these records
chain together existing names, or cryptographic hashes of them in the
zone. In the online signing model, described in NSEC and NSEC3
"White Lies" [RFC4470] [RFC7129], they are used to dynamically
compute an epsilon function around the queried name. A 'type bitmap'
in the data field of the NSEC or NSEC3 record asserts which resource
record types are present at the name.
The response for a non-existent name requires upto 2 signed NSEC
records or up to 3 signed NSEC3 records (and for online signers, the
associated cryptographic computation), to prove that (1) the name did
not explicitly exist in the zone, and (2) that it could not have been
synthesized by a wildcard.
This document describes an alternative technique, "Compact Lies", 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
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.
Huque & Elmerot Expires 31 August 2023 [Page 2]
Internet-Draft Compact Denial of Existence in DNSSEC February 2023
2. Distinguishing NXDOMAIN from Empty Non-Terminal Names
Since NODATA responses are generated for non-existent names, and
there are no defined record types for the name, the NSEC type bitmap
in the response will only contain "NSEC" and "RRSIG". Tools that
need to accurately identify non-existent names in responses cannot
rely on this specific type bitmap because Empty Non-Terminal (ENT)
names (which positively exist) also have no record types at the name
and will return exactly the same type bitmap.
Today, some specific implementations of Compact Lies avoid the
NXDOMAIN identification problem by synthesizing the NSEC type bitmap
for ENTs to include all record types supported except for the queried
type. This has the undesirable effect of no longer being able to
reliably determine the existence of ENTs.
This document defines the use of a synthetic Resource Record type to
signal the presence of an Empty Non-Terminal name. The mnemonic for
this RR type is "ENT" and its type code is [TBD]. This RR type is
added to the NSEC type bitmap for responses to ENTs. No special
handling of this RR type is needed on the part of DNS resolvers.
3. Responses for Non-Existent Names
When an authoritative server implementing Compact Lies receives a
query for a non-existent name in a zone that it serves, a NODATA
response (response code NOERROR, empty Answer section) is generated
with a dynamically constructed NSEC record with the owner name
matching the queried name (QNAME).
The next name SHOULD be set to the immediate lexicographic successor
of the QNAME. The generated NSEC record's type bitmap MUST have only
the RRSIG and NSEC bits set.
For example, a request for the non-existing name a.example.com would
cause the following NSEC record to be generated (in DNS presentation
format):
a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC
The NSEC record MUST have corresponding RRSIGs generated.
Huque & Elmerot Expires 31 August 2023 [Page 3]
Internet-Draft Compact Denial of Existence in DNSSEC February 2023
4. Responses for Wildcard Matches
For wildcard matches, a Compact Lies implementation will typically
provide a dynamically signed response that claims that the queried
name exists explicitly. This obviates the need to include an NSEC
record in the Additional section of the response that shows that no
closer match than the wildcard was possible.
Similarly, Wildcard NODATA responses (where the queried name matches
a wildcard but no data for the queried type exists), a response akin
to a regular NODATA is returned. The Answer section is empty, and
the Additional section contains a single NSEC record that matches the
query name with a type bitmap representing the list of types
available at the wildcard.
5. Responses for Empty Non-Terminals
When an authoritative server implementing Compact Lies receives a
query for an Empty Non-Terminal name, it generates a NODATA response
in the usual way, except that it adds the additional Empty Non-
Terminal distinguisher RR type code in the NSEC type bitmap field.
Corresponding RRSIG signature record(s) MUST also be generated.
ent1.example.net. 3600 IN NSEC \000.ent.example.net. RRSIG NSEC ENT
Note that this RR type only appears in the type bitmap of an NSEC
record in response to a query for an Empty Non-Terminal name. It
causes no special processing on the part of validating resolvers.
Queries for the ENT RR type itself at an actual Empty Non-Terminal
MUST also elicit the response described in this section.
6. Operational Implications
A signed zone at an authoritative server implementing Compact Lies
will never return a response with a response code of NXDOMAIN. Tools
that rely on accurately determining non-existent names will need to
infer them from the NSEC type bitmap pattern of "NSEC RRSIG".
Address lookup functions typically invoked by applications won't see
a practical impact from this indistinguishability. For a non-
existent name, the getaddrinfo() function for example will return an
exit code of EAI_NODATA rather than EAI_NONAME. But either way the
effect on the caller is the same: it will obtain a response with a
non-zero exit code and no available addresses.
Huque & Elmerot Expires 31 August 2023 [Page 4]
Internet-Draft Compact Denial of Existence in DNSSEC February 2023
7. Implementation Status
Cloudflare, NS1, and Amazon Route53 currently implement the base
Compact Lies scheme. NS1 additonally implements the Empty Non-
Terminal distinguisher in the NSEC type bitmap, using the private RR
type code 65281.
8. Security Considerations
Online signing of DNS records requires authoritative servers for the
DNS zone to have access to the private signing keys. Exposing
signing keys on Internet reachable servers makes them more vulnerable
to attack.
Additionally, generating signatures on-demand is more computationally
intensive than returning pre-computed signatures. Although the
Compact Lies scheme reduces the number of online signing operations
compared to previous techniques like White Lies, it still may make
authoritative servers more vulnerable to computational denial of
service attacks than pre-computed signatures. The use of signature
algorithms (like those based on Elliptic Curves) that have a
comparatively low cost for signing is recommended.
9. Acknowledgements
The Compact Lies technique (then called "Black Lies") was originally
proposed in [COMPACT-LIES] by F. Valsorda and O. Gudmunsson, and
implemented by Cloudflare. The Empty Non-Terminal distinguisher RR
type was originally proposed in [ENT-SENTINEL] by S. Huque.
10. IANA Considerations
IANA is requested to allocate a new DNS Resource Record type code for
the Empty Non-Terminal distinguisher in the DNS parameters registry:
ENT [TBD] Empty Non-Terminal Distinguisher for Compact Lies
11. References
11.1. Normative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
Huque & Elmerot Expires 31 August 2023 [Page 5]
Internet-Draft Compact Denial of Existence in DNSSEC February 2023
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
and DNSSEC On-line Signing", RFC 4470,
DOI 10.17487/RFC4470, April 2006,
<https://www.rfc-editor.org/info/rfc4470>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>.
11.2. Informative References
[COMPACT-LIES]
Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
Existence or Black Lies", <https://tools.ietf.org/html/
draft-valsorda-dnsop-black-lies>.
[ENT-SENTINEL]
Huque, S., "Empty Non-Terminal Sentinel for Black Lies",
<https://www.ietf.org/archive/id/draft-huque-dnsop-
blacklies-ent-01.html>.
Authors' Addresses
Shumon Huque
Salesforce
415 Mission Street, 3rd Floor
San Francisco, CA 94105
United States of America
Email: [email protected]
Huque & Elmerot Expires 31 August 2023 [Page 6]
Internet-Draft Compact Denial of Existence in DNSSEC February 2023
Christian Elmerot
Cloudflare
101 Townsend St.
San Francisco, CA 94107
United States of America
Email: [email protected]
Huque & Elmerot Expires 31 August 2023 [Page 7]