[要約] RFC 5625は、DNSプロキシの実装ガイドラインであり、DNSトラフィックの効率的な処理とセキュリティを向上させることを目的としています。要約すると、このRFCはDNSプロキシの設計と実装に関する指針を提供しています。
Network Working Group R. Bellis
Request for Comments: 5625 Nominet UK
BCP: 152 August 2009
Category: Best Current Practice
DNS Proxy Implementation Guidelines
DNSプロキシ実装ガイドライン
Abstract
概要
This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices.
このドキュメントは、ブロードバンドゲートウェイやその他の同様のネットワークデバイスに見られるように、DNSプロキシの実装に関するガイドラインを提供します。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The Transparency Principle ......................................3
4. Protocol Conformance ............................................4
4.1. Unexpected Flags and Data ..................................4
4.2. Label Compression ..........................................4
4.3. Unknown Resource Record Types ..............................4
4.4. Packet Size Limits .........................................4
4.4.1. TCP Transport .......................................5
4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
4.4.3. IP Fragmentation ....................................6
4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
5. DHCP's Interaction with DNS .....................................7
5.1. Domain Name Server (DHCP Option 6) .........................7
5.2. Domain Name (DHCP Option 15) ...............................8
5.3. DHCP Leases ................................................8
6. Security Considerations .........................................9
6.1. Forgery Resilience .........................................9
6.2. Interface Binding .........................................10
6.3. Packet Filtering ..........................................10
7. Acknowledgements ...............................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
Research has found ([SAC035], [DOTSE]) that many commonly used broadband gateways (and similar devices) contain DNS proxies that are incompatible in various ways with current DNS standards.
研究により、多くの一般的に使用されているブロードバンドゲートウェイ（および同様のデバイス）が現在のDNS標準とさまざまな方法で互換性のないDNSプロキシが含まれていることが研究（[SAC035]、[Dotse]）が含まれています。
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.
これらのプロキシは通常、単純なDNSフォワーダーですが、通常、キャッシュ機能はありません。プロキシは、LAN上のクライアントの便利なデフォルトのDNSリゾルバーとして機能しますが、再帰的なDNSルックアップを実行するために、上流のリゾルバー（ISPなど）に依存しています。
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.
完全なDNSプロトコルの相互運用性を確保するために、クライアントスタブリゾルバーは、可能な限りフルフェアチュア、上流の再帰リゾルバーと直接通信することが推奨されます。
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.
それにもかかわらず、このドキュメントは、発見された非互換性について説明し、クライアントがブロードバンドゲートウェイのDNSプロキシを使用する必要がある場合に、より良い相互運用性を提供する方法に関する実装者にガイドラインを提供します。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
It is not considered practical for a simple DNS proxy to implement all current and future DNS features.
単純なDNSプロキシがすべての現在および将来のDNS機能を実装することは実用的ではありません。
There are several reasons why this is the case:
これが事実である理由はいくつかあります：
o Broadband gateways usually have limited hardware resources.
o ブロードバンドゲートウェイには、通常、ハードウェアリソースが限られています。
o Firmware upgrade cycles are long, and many users do not routinely apply upgrades when they become available.
o ファームウェアのアップグレードサイクルは長く、多くのユーザーは利用可能になったときに日常的にアップグレードを適用しません。
o No one knows what those future DNS features will be or how they might be implemented.
o これらの将来のDNS機能が何であるか、またはそれらがどのように実装されるかは誰にもわかりません。
o Doing so would substantially complicate the configuration user interface (UI) of the device.
o そうすることで、デバイスの構成ユーザーインターフェイス（UI）が大幅に複雑になります。
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.
さらに、一部の最新のDNSプロトコル拡張（以下のEDNS0を参照）は、「ホップバイホップ」メカニズムとして使用することを目的としています。DNSプロキシが解像度チェーンのこのような「ホップ」と見なされる場合、それが正しく機能するには、そのようなすべてのメカニズムに完全に準拠する必要があります。
[SAC035] 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.
[SAC035]は、プロキシがDNSプロトコルに積極的に参加するほど、DNSクライアントと上流の再帰リゾルバーの間のメッセージの流れを何らかの形で妨害する可能性が高いことを示しています。
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.
したがって、プロキシの役割は、LAN側のクライアントからDNSリクエストを受信し、それらの逐語的な上流の再帰リソースバーの1つにWAN側の既知の上流の再帰リソースバーに転送し、応答全体が逐語的に返されることを確認すること以上のものでなければなりません。元のクライアントに。
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 resolvers, thereby bypassing the proxy altogether. In this case, the gateway SHOULD NOT modify the DNS request or response packets in any way.
アクティブなセキュリティまたはネットワークポリシーを実施する必要がある場合を除き（承認前の「壁に囲まれた庭」を維持するなど）、エンドユーザーはDNSクエリを指定された上流のリゾルバーに送信し、それによりプロキシを完全にバイパスできるはずです。この場合、ゲートウェイはDNS要求または応答パケットをいかなる方法で変更してはなりません。
The Transparency Principle above, when combined with Postel's Robustness Principle [RFC0793], suggests that DNS proxies should not arbitrarily reject or otherwise drop requests or responses based on perceived non-compliance with standards.
上記の透明性の原則は、Postelの堅牢性[RFC0793]と組み合わせると、DNSプロキシが標準の認識されていない違反に基づいてarbitrarily意的に拒否したり、要求または応答をドロップしたりするべきではないことを示唆しています。
For example, some proxies have been observed to drop any packet containing either the "Authentic Data" (AD) or "Checking Disabled" (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] 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.
たとえば、一部のプロキシは、DNSSEC [RFC4035]から「Authentic Data」（AD）または「Checking Disabled」（CD）ビットを含むパケットをドロップすることが観察されています。これは、[RFC1035]が元々、これらの未使用の「Z」フラグビット」がゼロでなければならないことを指定したためかもしれません。ただし、これらのフラグビットは常に将来の使用のために予約されることを目的としていたため、これらのフラグを含むパケットをプロキシを拒否することは拒否されます（これらのフラグの使用が実際に定義されているため）は適切ではありません。
Therefore, proxies MUST ignore any unknown DNS flags and proxy those packets as usual.
したがって、プロキシは、未知のDNSフラグを無視し、通常どおりにそれらのパケットをプロキシする必要があります。
Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
[RFC1035]のセクション4.1.4に従って、ラベルの圧縮はオプションです。
Proxies MUST forward packets regardless of the presence or absence of compressed labels therein.
プロキシは、その中の圧縮ラベルの有無に関係なく、パケットを転送する必要があります。
[RFC3597] requires that resolvers MUST handle Resource Records (RRs) of unknown type transparently.
[RFC3597]は、リゾルバーが未知のタイプのリソースレコード（RR）を透過的に処理する必要があることを要求しています。
All requests and responses MUST be proxied regardless of the values of the QTYPE and QCLASS fields.
すべてのリクエストと応答は、QTYPEおよびQCLASSフィールドの値に関係なく提案する必要があります。
Similarly, all responses MUST be proxied regardless of the values of the TYPE and CLASS fields of any Resource Record therein.
同様に、すべての応答は、その中のリソースレコードのタイプフィールドとクラスフィールドの値に関係なく、プロキシ化する必要があります。
[RFC1035] 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
[RFC1035]は、UDPパケットのDNSペイロードの最大サイズが512オクテットであることを指定しています。応答の必要部分がその制限内に収まらない場合、DNSサーバーは
"TrunCation" (TC) bit in the DNS response header to indicate that truncation has occurred. There are however two standard mechanisms (described in Sections 4.4.1 and 4.4.2) for transporting responses larger than 512 octets.
DNS応答ヘッダーの「切り捨て」（TC）ビットは、切り捨てが発生したことを示します。ただし、512オクテットを超える応答を輸送するための2つの標準メカニズム（セクション4.4.1および4.4.2で説明）があります。
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.
多くのプロキシは、512オクテットですべての応答を切り捨てることが観察されており、他のプロはWAN MTUに関連するパケットサイズで、どちらの場合でも、TCビットを正しく設定せずにそうしています。
Other proxies have been observed to remove the TC bit in server responses that correctly had the TC bit set by the server.
他のプロキシは、サーバーによってTCビットを正しく設定したサーバー応答でTCビットを削除することが観察されています。
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.
DNS応答が切り捨てられているが、TCビットが設定されていない場合、クライアントの障害が生じる可能性があります。特に、ナイーブなDNSクライアントライブラリは、実際に受信したデータの終わりを超えて読み取りのためにクラッシュに苦しむ可能性があります。
Since UDP packets larger than 512 octets are now expected in normal operation, proxies SHOULD NOT truncate UDP packets that exceed that size. See Section 4.4.3 for recommendations for packet sizes exceeding the WAN MTU.
512を超えるオクテットが通常の操作で512を超えるオクテットが予想されるため、プロキシはそのサイズを超えるUDPパケットを切り捨てるべきではありません。WAN MTUを超えるパケットサイズの推奨事項については、セクション4.4.3を参照してください。
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.
プロキシが応答を一方的に切り捨てなければならない場合、プロキシはTCビットを設定する必要があります。同様に、プロキシは応答からTCビットを削除してはなりません。
Should a UDP query fail because of truncation, the standard fail-over mechanism is to retry the query using TCP, as described in Section 6.1.3.2 of [RFC1123].
UDPクエリが切り捨てのために失敗した場合、[RFC1123]のセクション6.1.3.2で説明されているように、標準のフェイルオーバーメカニズムはTCPを使用してクエリを再試行することです。
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.
TCPトランスポートは厳密に必須ではありませんが、スタブリゾルバーと再帰サーバーの大部分によってサポートされています。プロキシでのサポートの欠如は、このフェイルオーバーメカニズムが機能するのを防ぎます。
DNS proxies MUST therefore be prepared to receive and forward queries over TCP.
したがって、DNSプロキシは、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.
既に切り捨てられたUDP応答を受け取っていない限り、クライアントがTCPを介してリクエストを送信する可能性は低いことに注意してください。一部の「スマート」プロキシは、TCPを介して受け取ったリクエストを最初にUDPを介して上流のリゾルバーに転送することが観察されていますが、応答が切り捨てられ、プロキシがTCPで再試行されます。このような動作は、最初のUDP要求が失敗する運命にあるため、ネットワークトラフィックを増加させ、DNS解像度の遅延を引き起こします。
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.
したがって、プロキシがTCPを介してリクエストを受信するときはいつでも、プロキシはTCPを介してクエリを転送する必要があり、最初にUDPを介して同じクエリを試みてはなりません。
The "Extension Mechanism for DNS" [RFC2671] was introduced to allow the transport of larger DNS packets over UDP and also to allow for additional request and response flags.
「DNSの拡張メカニズム」[RFC2671]が導入され、UDPを介したより大きなDNSパケットの輸送を可能にし、追加のリクエストと応答フラグを可能にしました。
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.
クライアントは、リクエストの追加セクションにOPTリソースレコード（OPT RR）を送信して、特定の受信バッファサイズをサポートすることを示すことができます。OPT RRには、DNSSECが使用する「DNSSEC OK」（DO）フラグも含まれており、DNSSEC関連のRRをクライアントに返却する必要があることを示します。
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 Section 4.1, proxies MUST NOT refuse to proxy such packets.
ただし、一部のプロキシは、OPT RRを含むパケットを拒否するか（FOMERR応答コードを使用して）拒否するか、ブラックホールのいずれかで観察されています。セクション4.1によると、プロキシはそのようなパケットのプロキシを拒否してはなりません。
Support for UDP packet sizes exceeding the WAN MTU depends on the gateway's algorithm for handling fragmented IP packets. Several methods are possible:
WAN MTUを超えるUDPパケットサイズのサポートは、断片化されたIPパケットを処理するためのゲートウェイのアルゴリズムに依存します。いくつかの方法が可能です：
1. Fragments are dropped.
1. フラグメントがドロップされます。
2. Fragments are forwarded individually as they're received.
2. フラグメントは、受信されたときに個別に転送されます。
3. Complete packets are reassembled on the gateway and then re-fragmented (if necessary) as they're forwarded to the client.
3. 完全なパケットはゲートウェイで再組み立てされ、クライアントに転送されると（必要に応じて）再び詰まっています。
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 RFC 2671 does recommend that the path MTU should be taken into account when using EDNS0.
上記の方法1は、DNSクライアントがIPヘッダーのサイズが少ないWAN MTUに制限されたEDNS0バッファーサイズを宣伝するように構成されていない限り、EDNS0と互換性の問題を引き起こします。RFC 2671は、EDNS0を使用する場合はPATH MTUを考慮する必要があることを推奨していることに注意してください。
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.
また、EDNS0仕様により最大65535オクテットのバッファサイズが可能になりますが、最も一般的なDNSサーバーの実装は4096オクテットを超えるバッファサイズをサポートしていません。
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.
したがって（上記の方法のどれに関係なく）、プロキシは、少なくとも4096オクテットのペイロードサイズにUDPパケットを転送できるはずです。
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.
NB：理論的には、LAN MTUがWAN MTUよりも小さい場合、IPの断片化も発生する可能性がありますが、著者は住宅ブロードバンドサービスでそのような構成を観察していません。
[RFC2845] defines TSIG, which is a mechanism for authenticating DNS requests and responses at the packet level.
[RFC2845]は、パケットレベルでDNS要求と応答を認証するメカニズムであるTSIGを定義します。
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.
TSIGに署名したクエリまたは応答パケットのDNS部分（クエリIDを除く）に変更された変更は、TSIG認証障害を引き起こします。
DNS proxies MUST implement Section 4.7 of [RFC2845] and either forward packets unchanged (as recommended above) or fully implement TSIG.
DNSプロキシは、[RFC2845]のセクション4.7を実装し、変化しない（上記のように）転送パケットを実装するか、TSIGを完全に実装する必要があります。
As per Section 4.3, DNS proxies MUST be capable of proxying packets containing TKEY [RFC2930] Resource Records.
セクション4.3によると、DNSプロキシは、TKEY [RFC2930]リソースレコードを含むパケットをプロキシできる必要があります。
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.
NB：すべてのDNSクエリを透過的にインターセプトし、署名されたクエリへの符号なしの応答を返すDNSプロキシ（WiFiホットスポット「壁の庭園」によく見られるようなものなど）は、TSIG認証障害を引き起こします。
Whilst this document is primarily about DNS proxies, most consumers rely on DHCP [RFC2131] 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.
このドキュメントは主にDNSプロキシに関するものですが、ほとんどの消費者はDHCP [RFC2131]に依存してネットワーク構成設定を取得しています。このような設定には、クライアントマシンのIPアドレス、サブネットマスク、デフォルトゲートウェイが含まれますが、DNS関連の設定も含まれます。
It is therefore appropriate to examine how DHCP affects client DNS configuration.
したがって、DHCPがクライアントDNS構成にどのように影響するかを調べることが適切です。
Most gateways default to supplying their own IP address in the DHCP "Domain Name Server" option [RFC2132]. 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.
ほとんどのゲートウェイは、DHCP「ドメインネームサーバー」オプション[RFC2132]に独自のIPアドレスを提供することを義務付けています。最終的な結果は、明示的な再構成がなければ、多くのDNSクライアントがデフォルトでゲートウェイのDNSプロキシにクエリを送信することです。これは、正しい上流の設定が通常ブート時に知られていないことを考えると、理解できる動作です。
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.
ほとんどのゲートウェイは、WANインターフェイスを介してDHCPまたはPPPを介してISPによって提供される値を介して、独自のDNS設定を学習します。ただし、多くのゲートウェイではデバイス管理者がそれらの値をオーバーライドすることができますが、一部のゲートウェイは、提供された値のみを使用してプロキシ独自の転送機能に影響を与え、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.
このようなデバイスを使用する場合、DNSプロキシの使用を避ける唯一の方法は、クライアントオペレーティングシステムの必要な値をハードコードすることです。これはデスクトップシステムでは許容される場合がありますが、多くの異なるネットワークで定期的に使用されているモバイルデバイスには不適切です。
As per Section 3, 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.
セクション3によると、エンドユーザーはDNSクエリを指定された上流のリゾルバーに直接送信できるはずです。
It is therefore RECOMMENDED that gateways SHOULD support device-administrator configuration of values for the "Domain Name Server" DHCP option.
したがって、Gatewaysは、「ドメイン名サーバー」DHCPオプションの値のデバイスと管理者の構成をサポートすることをお勧めします。
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.
DNSルート名サーバーへのかなりの量のトラフィックは、無効なトップレベルドメイン名のためのものであり、そのトラフィックの一部は、ファームウェアがこのDHCPオプションを特定の値にデフォルトする特定の機器ベンダーに起因する可能性があります。
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.
「ローカル」スコープドメイン名の接尾辞の標準は存在しないため、このオプションのデフォルト値は空になり、値が構成されていない場合はクライアントに送信してはなりません。
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.
ブロードバンドゲートウェイの一部のDHCPサーバーは、デフォルトでは「ドメイン名サーバー」オプション（上記のように）の独自のIPアドレスを提供しますが、上流のサーバーのアドレスを自動的に開始して、学習したら自動的に開始します。WANインターフェイス。
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.
一般に、この動作は非常に望ましいものですが、エンドユーザーの効果は、使用される設定がWANリンクの前後にDHCPリースが確立された後に得られたかどうかによって異なることです。
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.
WANリンクがダウンしている間にDHCPリースが取得された場合、DHCPクライアント（したがってDNSクライアント）は、DHCPリースが更新されるまで正しい値を受け取りません。
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.
ここでは具体的な推奨事項はありませんが、ベンダーはDHCPリースの長さと、DHCPリースの更新を強制するためのいくつかのメカニズムが適切かどうかを考慮したい場合があります。
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.
もう1つの可能性は、学習した上流の値が非揮発性メモリで持続する可能性があるため、再起動時に同じ値をDHCPを介して自動的に提供できるようにすることです。ただし、これは、デバイスが別の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.
あるいは、DHCPサーバーは、WANリンクがダウンしている間、非常に短い（つまり、60秒）リースのみを発行する場合があり、WANリンクがアップして上流のDNSサーバーがわかっている場合にのみ、より典型的なリース長に戻ります。実際、このような構成により、ブロードバンドゲートウェイにDNSプロキシ関数を実装する必要性を回避することが可能かもしれません。
This document introduces no new protocols. However, there are some security-related recommendations for vendors that are listed here.
このドキュメントでは、新しいプロトコルは導入されていません。ただし、ここにリストされているベンダーに関するセキュリティ関連の推奨事項がいくつかあります。
Whilst DNS proxies are not usually full-feature resolvers, they nevertheless share some characteristics with them.
DNSプロキシは通常、フル機能のリゾルバーではありませんが、それでもいくつかの特性を共有しています。
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.
透明性に関する上記の推奨事項にもかかわらず、多くのDNSプロキシが、アウトバウンドリクエストの新しいクエリIDを選択して、応答が正しいクライアントに向けられるようにすることが観察されます。
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.
NB：TSIG署名計算は、TSIG RRに掲載されている元のメッセージIDに基づいているため、クエリIDを変更することは受け入れられ、TSIGに署名されたパケットのプロキシと互換性があります。
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.
各DNSクエリがランダムに生成されたクエリIDを使用する必要があることは、長年にわたって標準的なガイダンスでした。ただし、多くのプロキシが、連続したリクエストのためにシーケンシャルクエリIDを選択することが観察されています。
It is strongly RECOMMENDED that DNS proxies follow the relevant recommendations in [RFC5452], particularly those in Section 9.2 relating to randomisation of Query IDs and source ports. This also applies to source port selection within any NAT function.
DNSプロキシは、[RFC5452]の関連する推奨事項、特にクエリIDおよびソースポートのランダム化に関連するセクション9.2の推奨事項に従うことを強くお勧めします。これは、NAT機能内のソースポート選択にも適用されます。
If a DNS proxy is running on a broadband gateway with NAT that is compliant with [RFC4787], then it SHOULD also follow the recommendations in Section 10 of [RFC5452] concerning how long DNS state is kept.
DNSプロキシが[RFC4787]に準拠しているNATを使用してブロードバンドゲートウェイで実行されている場合、DNS状態の期間に関する[RFC5452]のセクション10の推奨事項にも従う必要があります。
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 [RFC5358].
一部のゲートウェイは、内部（LAN）と外部（WAN）インターフェイスの両方でDNSプロキシをリスニングすることが観察されています。この構成では、[RFC5358]に記載されているように、プロキシをリフレクター攻撃の取り付けに使用することが可能です。
The DNS proxy in a gateway SHOULD NOT, by default, be accessible from the WAN interfaces of the device.
ゲートウェイのDNSプロキシは、デフォルトのデバイスのWANインターフェイスからアクセスできないはずです。
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 無効な圧縮ポインター（つまり、現在のパケットの外側を指すもの、または解析ループを引き起こす可能性があるもの）
o incorrect counts for the Question, Answer, Authority, and Additional Sections (although care should be taken where truncation is a possibility)
o 質問、回答、権限、および追加セクションの間違ったカウントがあります（ただし、切り捨てが可能な場合は注意が必要です）
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.
これらの状況では、プロキシは、パケットを完全に削除する代わりに、クライアント（つまり、サーブファイル）に対する適切なDNSエラー応答を合成する必要があります。これにより、クライアントはすぐにエラーを検出できます。
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.
著者は、特に、コアコンピテンスのリサフィファーの支援を認めたいと考えています。さらに、著者は、DNSEXTワーキンググループのメンバーからのフィードバックに感謝しています。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] Eastlake、D。、「DNSの秘密の鍵設立（TKEY RR）」、RFC 2930、2000年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、2003年9月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル修正」、RFC 4035、2005年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F。およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
[RFC5358] Damas、J。およびF. Neves、「リフレクター攻撃での再帰的な名前の使用の防止」、BCP 140、RFC 5358、2008年10月。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5452] Hubert、A。およびR. Van Mook、「Forged Answersに対してDNSをより回復力のあるものにするための対策」、RFC 5452、2009年1月。
[DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband Routers", February 2008, <http://www.iis.se/docs/Routertester_en.pdf>.
[Dotse] Ahlund and Wallstrom、「消費者ブロードバンドルーターのDNSSECテスト」、2008年2月、<http://www.iis.se/docs/routertester_en.pdf>。
[SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on Broadband Routers and Firewalls", September 2008, <http://www.icann.org/committees/security/sac035.pdf>.
[SAC035] Bellis、R。およびL. Phifer、「テストレポート：ブロードバンドルーターとファイアウォールへのDNSSECの影響」、2008年9月<http://www.icann.org/committees/security/sac035.pdf>。
Author's Address
著者の連絡先
Ray Bellis Nominet UK Edmund Halley Road Oxford OX4 4DQ United Kingdom
レイ・ベリス・ノミネット英国エドマンド・ハレー・ロード・オックスフォード・オックス4 4DQイギリス
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/