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
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Network Working Group R. Bellis
Request for Comments: 5625 Nominet UK
BCP: 152 August 2009
Category: Best Current Practice
<span class="h1">DNS Proxy Implementation Guidelines</span>
Abstract
This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
<span class="grey">Bellis Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. The Transparency Principle ......................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Protocol Conformance ............................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Unexpected Flags and Data ..................................<a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. Label Compression ..........................................<a href="#page-4">4</a>
<a href="#section-4.3">4.3</a>. Unknown Resource Record Types ..............................<a href="#page-4">4</a>
<a href="#section-4.4">4.4</a>. Packet Size Limits .........................................<a href="#page-4">4</a>
<a href="#section-4.4.1">4.4.1</a>. TCP Transport .......................................<a href="#page-5">5</a>
<a href="#section-4.4.2">4.4.2</a>. Extension Mechanisms for DNS (EDNS0) ................<a href="#page-6">6</a>
<a href="#section-4.4.3">4.4.3</a>. IP Fragmentation ....................................<a href="#page-6">6</a>
<a href="#section-4.5">4.5</a>. Secret Key Transaction Authentication for DNS (TSIG) .......<a href="#page-7">7</a>
<a href="#section-5">5</a>. DHCP's Interaction with DNS .....................................<a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. Domain Name Server (DHCP Option 6) .........................<a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Domain Name (DHCP Option 15) ...............................<a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. DHCP Leases ................................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Forgery Resilience .........................................<a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. Interface Binding .........................................<a href="#page-10">10</a>
<a href="#section-6.3">6.3</a>. Packet Filtering ..........................................<a href="#page-10">10</a>
<a href="#section-7">7</a>. Acknowledgements ...............................................<a href="#page-10">10</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-11">11</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-11">11</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Research has found ([<a href="#ref-SAC035" title=""Test Report: DNSSEC Impact on Broadband Routers and Firewalls"">SAC035</a>], [<a href="#ref-DOTSE" title=""DNSSEC Tests of Consumer Broadband Routers"">DOTSE</a>]) that many commonly used
broadband gateways (and similar devices) contain DNS proxies that are
incompatible in various ways with current DNS standards.
These proxies are usually simple DNS forwarders, but typically do not
have any caching capabilities. The proxy serves as a convenient
default DNS resolver for clients on the LAN, but relies on an
upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
Note that to ensure full DNS protocol interoperability it is
preferred that client stub resolvers should communicate directly with
full-feature, upstream recursive resolvers wherever possible.
That notwithstanding, this document describes the incompatibilities
that have been discovered and offers guidelines to implementors on
how to provide better interoperability in those cases where the
client must use the broadband gateway's DNS proxy.
<span class="grey">Bellis Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The Transparency Principle</span>
It is not considered practical for a simple DNS proxy to implement
all current and future DNS features.
There are several reasons why this is the case:
o Broadband gateways usually have limited hardware resources.
o Firmware upgrade cycles are long, and many users do not routinely
apply upgrades when they become available.
o No one knows what those future DNS features will be or how they
might be implemented.
o Doing so would substantially complicate the configuration user
interface (UI) of the device.
Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0
below) are intended to be used as "hop-by-hop" mechanisms. If the
DNS proxy is considered to be such a "hop" in the resolution chain,
then for it to function correctly, it would need to be fully
compliant with all such mechanisms.
[<a id="ref-SAC035">SAC035</a>] shows that the more actively a proxy participates in the DNS
protocol, the more likely it is that it will somehow interfere with
the flow of messages between the DNS client and the upstream
recursive resolvers.
The role of the proxy should therefore be no more and no less than to
receive DNS requests from clients on the LAN side, forward those
verbatim to one of the known upstream recursive resolvers on the WAN
side, and ensure that the whole response is returned verbatim to the
original client.
It is RECOMMENDED that proxies should be as transparent as possible,
such that any "hop-by-hop" mechanisms or newly introduced protocol
extensions operate as if the proxy were not there.
Except when required to enforce an active security or network policy
(such as maintaining a pre-authentication "walled garden"), end-users
SHOULD be able to send their DNS queries to specified upstream
<span class="grey">Bellis Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
resolvers, thereby bypassing the proxy altogether. In this case, the
gateway SHOULD NOT modify the DNS request or response packets in any
way.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Conformance</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Unexpected Flags and Data</span>
The Transparency Principle above, when combined with Postel's
Robustness Principle [<a href="./rfc0793" title=""Transmission Control Protocol"">RFC0793</a>], suggests that DNS proxies should not
arbitrarily reject or otherwise drop requests or responses based on
perceived non-compliance with standards.
For example, some proxies have been observed to drop any packet
containing either the "Authentic Data" (AD) or "Checking Disabled"
(CD) bits from DNSSEC [<a href="./rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>]. This may be because [<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>]
originally specified that these unused "Z" flag bits "MUST" be zero.
However, these flag bits were always intended to be reserved for
future use, so refusing to proxy any packet containing these flags
(now that uses for those flags have indeed been defined) is not
appropriate.
Therefore, proxies MUST ignore any unknown DNS flags and proxy those
packets as usual.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Label Compression</span>
Compression of labels as per <a href="./rfc1035#section-4.1.4">Section 4.1.4 of [RFC1035]</a> is optional.
Proxies MUST forward packets regardless of the presence or absence of
compressed labels therein.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Unknown Resource Record Types</span>
[<a id="ref-RFC3597">RFC3597</a>] requires that resolvers MUST handle Resource Records (RRs)
of unknown type transparently.
All requests and responses MUST be proxied regardless of the values
of the QTYPE and QCLASS fields.
Similarly, all responses MUST be proxied regardless of the values of
the TYPE and CLASS fields of any Resource Record therein.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Packet Size Limits</span>
[<a id="ref-RFC1035">RFC1035</a>] specifies that the maximum size of the DNS payload in a UDP
packet is 512 octets. Where the required portions of a response
would not fit inside that limit, the DNS server MUST set the
<span class="grey">Bellis Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
"TrunCation" (TC) bit in the DNS response header to indicate that
truncation has occurred. There are however two standard mechanisms
(described in Sections <a href="#section-4.4.1">4.4.1</a> and <a href="#section-4.4.2">4.4.2</a>) for transporting responses
larger than 512 octets.
Many proxies have been observed to truncate all responses at 512
octets, and others at a packet size related to the WAN MTU, in either
case doing so without correctly setting the TC bit.
Other proxies have been observed to remove the TC bit in server
responses that correctly had the TC bit set by the server.
If a DNS response is truncated but the TC bit is not set, then client
failures may result. In particular, a naive DNS client library might
suffer crashes due to reading beyond the end of the data actually
received.
Since UDP packets larger than 512 octets are now expected in normal
operation, proxies SHOULD NOT truncate UDP packets that exceed that
size. See <a href="#section-4.4.3">Section 4.4.3</a> for recommendations for packet sizes
exceeding the WAN MTU.
If a proxy must unilaterally truncate a response, then the proxy MUST
set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
responses.
<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>. TCP Transport</span>
Should a UDP query fail because of truncation, the standard fail-over
mechanism is to retry the query using TCP, as described in <a href="./rfc1123#section-6.1.3.2">Section</a>
<a href="./rfc1123#section-6.1.3.2">6.1.3.2 of [RFC1123]</a>.
Whilst TCP transport is not strictly mandatory, it is supported by
the vast majority of stub resolvers and recursive servers. Lack of
support in the proxy prevents this fail-over mechanism from working.
DNS proxies MUST therefore be prepared to receive and forward queries
over TCP.
Note that it is unlikely that a client would send a request over TCP
unless it had already received a truncated UDP response. Some
"smart" proxies have been observed to first forward any request
received over TCP to an upstream resolver over UDP, only for the
response to be truncated, causing the proxy to retry over TCP. Such
behaviour increases network traffic and causes delay in DNS
resolution since the initial UDP request is doomed to fail.
<span class="grey">Bellis Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
Therefore, whenever a proxy receives a request over TCP, the proxy
SHOULD forward the query over TCP and SHOULD NOT attempt the same
query over UDP first.
<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Extension Mechanisms for DNS (EDNS0)</span>
The "Extension Mechanism for DNS" [<a href="./rfc2671" title=""Extension Mechanisms for DNS (EDNS0)"">RFC2671</a>] was introduced to allow
the transport of larger DNS packets over UDP and also to allow for
additional request and response flags.
A client may send an OPT Resource Record (OPT RR) in the Additional
Section of a request to indicate that it supports a specific receive
buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
by DNSSEC to indicate that DNSSEC-related RRs should be returned to
the client.
However, some proxies have been observed to either reject (with a
FORMERR response code) or black-hole any packet containing an OPT RR.
As per <a href="#section-4.1">Section 4.1</a>, proxies MUST NOT refuse to proxy such packets.
<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>. IP Fragmentation</span>
Support for UDP packet sizes exceeding the WAN MTU depends on the
gateway's algorithm for handling fragmented IP packets. Several
methods are possible:
1. Fragments are dropped.
2. Fragments are forwarded individually as they're received.
3. Complete packets are reassembled on the gateway and then re-
fragmented (if necessary) as they're forwarded to the client.
Method 1 above will cause compatibility problems with EDNS0 unless
the DNS client is configured to advertise an EDNS0 buffer size
limited to the WAN MTU less the size of the IP header. Note that <a href="./rfc2671">RFC</a>
<a href="./rfc2671">2671</a> does recommend that the path MTU should be taken into account
when using EDNS0.
Also, whilst the EDNS0 specification allows for a buffer size of up
to 65535 octets, most common DNS server implementations do not
support a buffer size above 4096 octets.
Therefore (irrespective of which of the above methods is in use),
proxies SHOULD be capable of forwarding UDP packets up to a payload
size of at least 4096 octets.
<span class="grey">Bellis Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
NB: in theory, IP fragmentation may also occur if the LAN MTU is
smaller than the WAN MTU, although the author has not observed such a
configuration in use on any residential broadband service.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Secret Key Transaction Authentication for DNS (TSIG)</span>
[<a id="ref-RFC2845">RFC2845</a>] defines TSIG, which is a mechanism for authenticating DNS
requests and responses at the packet level.
Any modifications made to the DNS portions of a TSIG-signed query or
response packet (with the exception of the Query ID) will cause a
TSIG authentication failure.
DNS proxies MUST implement <a href="./rfc2845#section-4.7">Section 4.7 of [RFC2845]</a> and either
forward packets unchanged (as recommended above) or fully implement
TSIG.
As per <a href="#section-4.3">Section 4.3</a>, DNS proxies MUST be capable of proxying packets
containing TKEY [<a href="./rfc2930" title=""Secret Key Establishment for DNS (TKEY RR)"">RFC2930</a>] Resource Records.
NB: any DNS proxy (such as those commonly found in WiFi hotspot
"walled gardens") that transparently intercepts all DNS queries and
that returns unsigned responses to signed queries, will also cause
TSIG authentication failures.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. DHCP's Interaction with DNS</span>
Whilst this document is primarily about DNS proxies, most consumers
rely on DHCP [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>] to obtain network configuration settings.
Such settings include the client machine's IP address, subnet mask,
and default gateway, but also include DNS-related settings.
It is therefore appropriate to examine how DHCP affects client DNS
configuration.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Domain Name Server (DHCP Option 6)</span>
Most gateways default to supplying their own IP address in the DHCP
"Domain Name Server" option [<a href="./rfc2132" title=""DHCP Options and BOOTP Vendor Extensions"">RFC2132</a>]. The net result is that
without explicit re-configuration many DNS clients will, by default,
send queries to the gateway's DNS proxy. This is understandable
behaviour given that the correct upstream settings are not usually
known at boot time.
<span class="grey">Bellis Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
Most gateways learn their own DNS settings via values supplied by an
ISP via DHCP or PPP over the WAN interface. However, whilst many
gateways do allow the device administrator to override those values,
some gateways only use those supplied values to affect the proxy's
own forwarding function, and do not offer these values via DHCP.
When using such a device, the only way to avoid using the DNS proxy
is to hard-code the required values in the client operating system.
This may be acceptable for a desktop system but it is inappropriate
for mobile devices that are regularly used on many different
networks.
As per <a href="#section-3">Section 3</a>, end-users SHOULD be able to send their DNS queries
directly to specified upstream resolvers, ideally without hard-coding
those settings in their stub resolver.
It is therefore RECOMMENDED that gateways SHOULD support device-
administrator configuration of values for the "Domain Name Server"
DHCP option.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Domain Name (DHCP Option 15)</span>
A significant amount of traffic to the DNS Root Name Servers is for
invalid top-level domain names, and some of that traffic can be
attributed to particular equipment vendors whose firmware defaults
this DHCP option to specific values.
Since no standard exists for a "local" scoped domain name suffix, it
is RECOMMENDED that the default value for this option SHOULD be
empty, and that this option MUST NOT be sent to clients when no value
is configured.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. DHCP Leases</span>
It is noted that some DHCP servers in broadband gateways offer, by
default, their own IP address for the "Domain Name Server" option (as
described above) but then automatically start offering the upstream
servers' addresses once they've been learnt over the WAN interface.
In general, this behaviour is highly desirable, but the effect for
the end-user is that the settings used depend on whether the DHCP
lease was obtained before or after the WAN link was established.
If the DHCP lease is obtained whilst the WAN link is down, then the
DHCP client (and hence the DNS client) will not receive the correct
values until the DHCP lease is renewed.
<span class="grey">Bellis Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
Whilst no specific recommendations are given here, vendors may wish
to give consideration to the length of DHCP leases and to whether
some mechanism for forcing a DHCP lease renewal might be appropriate.
Another possibility is that the learnt upstream values might be
persisted in non-volatile memory such that on reboot the same values
can be automatically offered via DHCP. However, this does run the
risk that incorrect values are initially offered if the device is
moved or connected to another ISP.
Alternatively, the DHCP server might only issue very short (i.e., 60
second) leases while the WAN link is down, only reverting to more
typical lease lengths once the WAN link is up and the upstream DNS
servers are known. Indeed, with such a configuration it may be
possible to avoid the need to implement a DNS proxy function in the
broadband gateway at all.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document introduces no new protocols. However, there are some
security-related recommendations for vendors that are listed here.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Forgery Resilience</span>
Whilst DNS proxies are not usually full-feature resolvers, they
nevertheless share some characteristics with them.
Notwithstanding the recommendations above about transparency, many
DNS proxies are observed to pick a new Query ID for outbound requests
to ensure that responses are directed to the correct client.
NB: changing the Query ID is acceptable and compatible with proxying
TSIG-signed packets since the TSIG signature calculation is based on
the original message ID, which is carried in the TSIG RR.
It has been standard guidance for many years that each DNS query
should use a randomly generated Query ID. However, many proxies have
been observed picking sequential Query IDs for successive requests.
It is strongly RECOMMENDED that DNS proxies follow the relevant
recommendations in [<a href="./rfc5452" title=""Measures for Making DNS More Resilient against Forged Answers"">RFC5452</a>], particularly those in <a href="#section-9.2">Section 9.2</a>
relating to randomisation of Query IDs and source ports. This also
applies to source port selection within any NAT function.
If a DNS proxy is running on a broadband gateway with NAT that is
compliant with [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>], then it SHOULD also follow the
recommendations in <a href="./rfc5452#section-10">Section 10 of [RFC5452]</a> concerning how long DNS
state is kept.
<span class="grey">Bellis Best Current Practice [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Interface Binding</span>
Some gateways have been observed to have their DNS proxy listening on
both internal (LAN) and external (WAN) interfaces. In this
configuration, it is possible for the proxy to be used to mount
reflector attacks as described in [<a href="./rfc5358" title=""Preventing Use of Recursive Nameservers in Reflector Attacks"">RFC5358</a>].
The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
the WAN interfaces of the device.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Packet Filtering</span>
The Transparency and Robustness Principles are not entirely
compatible with the deep packet-inspection features of security
appliances such as firewalls, which are intended to protect systems
on the inside of a network from rogue traffic.
However, a clear distinction may be made between traffic that is
intrinsically malformed and that which merely contains unexpected
data.
Examples of malformed packets that MAY be dropped include:
o invalid compression pointers (i.e., those that point outside of
the current packet or that might cause a parsing loop)
o incorrect counts for the Question, Answer, Authority, and
Additional Sections (although care should be taken where
truncation is a possibility)
Dropped packets will cause the client to repeatedly retransmit the
original request, with the client only detecting the error after
several retransmit intervals.
In these circumstances, proxies SHOULD synthesise a suitable DNS
error response to the client (i.e., SERVFAIL) instead of dropping the
packet completely. This will allow the client to detect the error
immediately.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The author would particularly like to acknowledge the assistance of
Lisa Phifer of Core Competence. In addition, the author is grateful
for the feedback from the members of the DNSEXT Working Group.
<span class="grey">Bellis Best Current Practice [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC0793">RFC0793</a>] Postel, J., "Transmission Control Protocol", STD 7,
<a href="./rfc793">RFC 793</a>, September 1981.
[<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<a id="ref-RFC1123">RFC1123</a>] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, <a href="./rfc1123">RFC 1123</a>, October 1989.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2131">RFC2131</a>] Droms, R., "Dynamic Host Configuration Protocol",
<a href="./rfc2131">RFC 2131</a>, March 1997.
[<a id="ref-RFC2132">RFC2132</a>] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", <a href="./rfc2132">RFC 2132</a>, March 1997.
[<a id="ref-RFC2671">RFC2671</a>] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
<a href="./rfc2671">RFC 2671</a>, August 1999.
[<a id="ref-RFC2845">RFC2845</a>] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", <a href="./rfc2845">RFC 2845</a>, May 2000.
[<a id="ref-RFC2930">RFC2930</a>] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", <a href="./rfc2930">RFC 2930</a>, September 2000.
[<a id="ref-RFC3597">RFC3597</a>] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", <a href="./rfc3597">RFC 3597</a>, September 2003.
[<a id="ref-RFC4035">RFC4035</a>] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", <a href="./rfc4035">RFC 4035</a>, March 2005.
[<a id="ref-RFC4787">RFC4787</a>] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>,
<a href="./rfc4787">RFC 4787</a>, January 2007.
[<a id="ref-RFC5358">RFC5358</a>] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", <a href="https://www.rfc-editor.org/bcp/bcp140">BCP 140</a>, <a href="./rfc5358">RFC 5358</a>,
October 2008.
<span class="grey">Bellis Best Current Practice [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5625">RFC 5625</a> DNS Proxy Implementation Guidelines August 2009</span>
[<a id="ref-RFC5452">RFC5452</a>] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", <a href="./rfc5452">RFC 5452</a>, January 2009.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-DOTSE">DOTSE</a>] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
Routers", February 2008,
<<a href="http://www.iis.se/docs/Routertester_en.pdf">http://www.iis.se/docs/Routertester_en.pdf</a>>.
[<a id="ref-SAC035">SAC035</a>] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
Broadband Routers and Firewalls", September 2008,
<<a href="http://www.icann.org/committees/security/sac035.pdf">http://www.icann.org/committees/security/sac035.pdf</a>>.
Author's Address
Ray Bellis
Nominet UK
Edmund Halley Road
Oxford OX4 4DQ
United Kingdom
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: <a href="http://www.nominet.org.uk/">http://www.nominet.org.uk/</a>
Bellis Best Current Practice [Page 12]
</pre>
|
