ネットワークワーキンググループ R. Bellis RFC: 5625 Nominet UK BCP: 152 2009年8月 分類: 現状の最良の方法(Best Current Practice) DNSプロキシーの実装ガイドライン 要旨 本文書は、ブロードバンドゲートウェイや他の類似したネットワーク 機器で見受けられる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. 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. Bellis Best Current Practice [Page 1] RFC 5625 DNS Proxy Implementation Guidelines August 2009 目次 1. はじめに ........................................................2 2. 用語 ............................................................3 3. 透過性の原則 ....................................................3 4. プロトコルへの適合性 ............................................4 4.1. 予期しないフラグとデータ ...................................4 4.2. ラベル圧縮 .................................................4 4.3. 未知のリソースレコードタイプ ...............................4 4.4. パケットサイズの上限 .......................................4 4.4.1. TCPトランスポート ...................................5 4.4.2. DNSの拡張方式(EDNS(0)) ..............................6 4.4.3. IPフラグメンテーション ..............................6 4.5. DNSにおける秘密鍵に基づくトランザクション認証(TSIG) ........7 5. DHCPとDNSの相互作用 .............................................7 5.1. DNSサーバー(DHCPオプション6) ...............................7 5.2.ドメイン名(DHCPオプション15) ................................8 5.3. DHCPリース .................................................8 6. セキュリティに関する考慮点 ......................................9 6.1. 偽造への耐性 ...............................................9 6.2. インターフェースとの対応付け ..............................10 6.3. パケットのフィルタリング ..................................10 7. Acknowledgements ...............................................10 8. References .....................................................11 8.1. Normative References ......................................11 8.2. Informative References ....................................12 1. はじめに 研究([SAC035], [DOTSE])により、一般的に使用されている多数のブロード バンドゲートウェイ(や類似の機器)に含まれるDNSプロキシー機能は、 さまざまな点で現行のDNS標準と非互換であることがわかった。 これらのプロキシーは、通常の場合単純なDNSフォワーダーだが、典型的には キャッシュ機能を持たない。プロキシーは、LAN上のクライアント向けの 便利なデフォルトDNSリゾルバーとして動作するが、DNSの再帰検索を実行する ために上流の(例えばISPの)リゾルバーに依存する。 全DNSプロトコルとの相互運用性を保証するためには、それが可能であるなら、 クライアントのスタブリゾルバーがすべての機能を備えた上流の再帰リゾルバーと 直接通信すべきであり、その方が望ましいことに注意せよ。 それでもなお、本文書は、発見された非互換な点を記述し、クライアントが ブロードバンドゲートウェイのDNSプロキシーを使用しなければならない 状況において、より良い相互運用性をどのように提供するかに関して、 実装者に向けたガイドラインを提示する。 Bellis Best Current Practice [Page 2] RFC 5625 DNS Proxy Implementation Guidelines August 2009 2. 用語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、 "しないものとする(SHALL NOT)"、"すべきである(SHOULD)"、 "すべきでない(SHOULD NOT)"、"推奨される(RECOMMENDED)"、 "してもよい/することができる(MAY)"、"任意である(OPTIONAL)"等は、 [RFC2119]の記述どおりに解釈されるものとする。 3. 透過性の原則 シンプルなDNSプロキシーが現行及び将来のDNS機能すべてを実装することは 現実的ではないと考えられる。 その理由を以下に幾つか提示する。 ・ ブロードバンドゲートウェイは通常限られたハードウェアリソースしか 持たない。 ・ ファームウェアのアップグレードサイクルが長く、多くのユーザーは アップグレードが利用可能になっても、定期的な適用をしない。 ・ 将来のDNS機能がどのようになるか、それがどのように実装されるかに ついては誰もわからない。 ・ DNS機能すべてを実装すると、機器の設定に関するユーザー インターフェース(UI)が相当複雑になる。 更に、幾つかの最新のDNSプロトコル拡張(例えば後述のEDNS0参照)は、 "ホップバイホップ"の仕組みとして使用されるように意図されている。 DNSプロキシーが名前解決に関わる一連の処理機器に含まれる一つの "ホップ"であると見なされるのであれば、DNSプロキシーが適正に機能 するには、そのような仕組みすべてに完全に準拠する必要があるだろう。 [SAC035]は、プロキシーがより積極的にDNSプロトコルに参加していることを 示している。具体的に、DNSクライアントと上流の再帰リゾルバーの間で やりとりされるメッセージフローに何らかの干渉をすることが多い。 従って、プロキシーの役割は、LAN側のクライアントからDNSリクエストを 受信し、それをそのままWAN側の既知の上流再帰リゾルバーの一つに転送し、 その応答をそのままオリジナルのクライアントに返すことだけにすべきである。 プロキシーは可能な限り透過的であるべきこと、具体的に、あらゆる"ホップ バイホップ"の仕組みや新たに導入されたプロトコル拡張が、プロキシーが 存在していないかのように動作すべきことが推奨される(RECOMMENDED)。 アクティブなセキュリティポリシーやネットワークポリシーを実施するため (例えば、事前認証を伴う"ウォールドガーデン"(限定された利用者向けアクセス 環境)を維持するため)にプロキシーの使用が要求される場合)を除き、 エンドユーザーは自身の発行するDNS問い合わせを指定された上流のリゾルバーに 送信することで、プロキシーを迂回できるようにすべき(SHOULD)である。 Bellis Best Current Practice [Page 3] RFC 5625 DNS Proxy Implementation Guidelines August 2009 その場合、ゲートウェイはDNSリクエストまたは応答パケットをどのような 形であれ変更すべきではない(SHOULD NOT)。 4. プロトコルへの適合性 4.1. 予期しないフラグとデータ 上記の透過性の原則をPostelのロバストネス原則[RFC0793]と組み合わせると、 リクエストまたは応答が標準に準拠していないことにDNSプロキシーが気づいた としても、それを自分の裁量で拒否または破棄すべきではないことが示唆される。 例えば、あるプロキシーは、DNSSEC[RFC4035]で導入されたAD(Authentic Data) ビットまたはCD(Checking Disabled)ビットのどちらかを含むパケットは 何であれ破棄することが観測されている。この理由は恐らく、[RFC1035]が 当初これら未使用の"Z"フラグビットはゼロでなければ"ならない(MUST)"と 規定したからだろう。しかし、これらのフラグは以前より将来の利用のための 予約であることが意図されていたので、これらのフラグを含むあらゆるパケット (今日ではこれらのフラグの使用法は確かに定義されている)のプロキシー処理を 拒否することは不適切である。 従って、プロキシーは未知のDNSフラグは何であれ無視し、それらを含む パケットを通常通りにプロキシー処理しなければならない(MUST)。 4.2. ラベル圧縮 [RFC1035]のセクション4.1.4記載の通り、ラベル圧縮は任意である。 プロキシーは圧縮されたラベルがパケット内に存在していてもいなくても 関係なく、そのパケットを転送しなければならない(MUST)。 4.3. 未知のリソースレコードタイプ [RFC3597]は、リゾルバーは未知のタイプのリソースレコード(RR)を透過的に 扱えなければならない(MUST)と要求している。 すべてのリクエストと応答は、QTYPE、QCLASSフィールドの値にかかわらず プロキシー処理されなければならない(MUST)。 同様に、すべての応答は、そこに含まれるリソースレコードのTYPE、CLASS フィールドの値にかかわらずプロキシー処理されなければならない(MUST)。 4.4. パケットサイズの上限 [RFC1035]は、UDPパケットにおけるDNSペイロードの最大サイズは512オクテット であると規定している。応答の必須の部分がこの上限内に収まらない場合、 DNSサーバーはDNS応答ヘッダーで"切り詰め(TrunCation)"(TC)ビットを設定し、 切り詰めが発生したことを提示しなければならない(MUST)。 Bellis Best Current Practice [Page 4] RFC 5625 DNS Proxy Implementation Guidelines August 2009 しかし、512オクテットを越える応答を転送するにあたり、二つの標準的な 仕組み(それぞれセクション4.4.1、4.4.2に記述される)が存在する。 プロキシーがすべての応答を切り詰めるにあたり、多くのものは512オクテットで、 あるものはWAN MTUに関連した値で切り詰めるが、いずれの場合においても TCビットを適切に設定しないまま切り詰めを実行するものが観測されている。 それ以外に、サーバーによって設定されたTCビットを適正に保持する サーバー応答からTCビットを除去するプロキシーが観測されている。 DNS応答が切り詰められているがTCビットが設定されていない場合、クライアント 障害が発生するかもしれない。具体的に、よく考えずに作られたDNSクライアント ライブラリは、実際に受信したデータの最後尾を超えてデータを読み込む ことによるクラッシュに苦しむ可能性がある。 今日では、通常の処理でも512オクテットを超えるUDPパケットが予期される ため、プロキシーはそのサイズを超えるUDPパケットを切り詰めるべきでは ない(SHOULD NOT)。WAN MTUを超えるパケットサイズに対して推奨される処理 については、セクション4.4.3参照のこと。 プロキシーが一方的に応答を切り詰めなければならない場合、プロキシーは TCビットを設定しなければならない(MUST)。同様に、プロキシーは応答から TCビットを除去してはならない(MUST NOT)。 4.4.1. TCPトランスポート [RFC1123]のセクション6.1.3.2に記述されているように、切り詰めが原因で UDPの問い合わせが失敗した場合、標準的な障害回避の仕組みはTCPを使用した 問い合わせのリトライである。 TCPトランスポートは厳密には必須ではないが、この仕組みはスタブ リゾルバーと再帰サーバーの大部分でサポートされている。プロキシーによる サポートの欠如は、この障害回避の仕組みの動作を阻害する。 従って、DNSプロキシーは、TCPで問い合わせを受信し転送する用意を しておかなければならない(MUST)。 クライアントが切り詰められたUDP応答を既に受信済みでない限り、 クライアントがTCPでリクエストを送信することはあり得ないことに注意せよ。 ある種の"賢い"プロキシーは、TCPで受信したあらゆるリクエストを、まず UDPで上流のリゾルバーに転送し、応答が切り詰められた場合にだけTCPで リトライを発生させることが観測されている。そのような振る舞いは ネットワークトラフィックを増加させ、DNSの名前解決の遅延を生じさせる。 初めのUDPリクエストは失敗する運命にあるからである。 Bellis Best Current Practice [Page 5] RFC 5625 DNS Proxy Implementation Guidelines August 2009 従って、プロキシーがTCPでリクエストを受信した場合、常にその 問い合わせをTCPで転送すべき(SHOULD)であり、同じ問い合わせを初めにUDPで 試みるべきではない(SHOULD NOT)。 4.4.2. DNSの拡張方式(EDNS(0)) "DNSの拡張方式"[RFC2671]は、UDPでより大きなDNSパケットの転送を 可能にすると共に、付加的なリクエスト、応答フラグを使用可能にするために 導入された。 クライアントは、特定の受信バッファーサイズをサポートしていることを提示 するために、リクエストの付加情報部でOPT RRを送信してもよい。またOPT RRは、 DNSSECによって使用されるDO(DNSSEC OK)フラグを含むことで、DNSSEC関連の RRがクライアントに返されるべきであることを提示する。 しかし、幾つかのプロキシーはOPT RRを含むあらゆるパケットを拒否する (FORMERR応答コードを返す)か、通知無しに破棄する(black hole)ことが 観測されている。セクション4.1記載のように、プロキシーはそのような パケットのプロキシー処理を拒否してはならない(MUST NOT)。 4.4.3. IPフラグメンテーション WAN MTUを越えるUDPパケットサイズのサポートは、フラグメンテーション されたパケットを扱うゲートウェイのアルゴリズムに依存する。以下に示す 幾つかの方法が考えられる。 1. フラグメントは破棄される。 2. フラグメントは、受信されたままの状態で個々に転送される。 3. ゲートウェイ上で完全なパケットを再構成し、クライアントに転送する際に (必要であれば)改めてフラグメンテーション処理を行う。 上に記した方法1は、DNSクライアントが広報するEDNS0バッファーサイズを WAN MTUからIPヘッダーを引いた値に制限するよう設定されていない限り 互換性の問題が発生する。RFC 2671は、EDNS0を使用する際にパスMTUを 考慮すべきであると推奨していることに注意せよ。 また、EDNS0仕様はバッファーサイズを最大65535オクテットまで許容するが、 大半の一般的なDNS実装は4096オクテットを超えるバッファーサイズを サポートしていない。 従って、(上記に示した方法のどれを使用するかに関係なく)プロキシーは 少なくとも4096オクテットのペイロードサイズのUDPパケットを転送する能力を 持つべき(SHOULD)である。 Bellis Best Current Practice [Page 6] RFC 5625 DNS Proxy Implementation Guidelines August 2009 注：理論上は、WAN MTUよりLAN MTUが小さい場合にもIPフラグメンテーションは 発生するだろう。しかし、どのような家庭用ブロードバンドサービスであれ、 そのような構成が使用されているのを著者は見たことがない。 4.5. DNSにおける秘密鍵に基づくトランザクション認証(TSIG) [RFC2845]はTSIGを定義している。これはパケットレベルでDNSリクエスト、 応答を認証する仕組みである。 TSIGで署名された問い合わせまたは応答パケットのDNS部へのいかなる変更 (ただし問い合わせIDは除く)もTSIG認証を失敗させる。 DNSプロキシーは[RFC2845]のセクション4.7を実装し、(先に推奨した ように)パケットを変更しないまま転送するか、TSIGを完全に実装するかの どちらかを行わなければならない(MUST)。 セクション4.3記載のように、DNSプロキシーはTKEYリソースレコード[RFC2930] を含むパケットをプロキシー処理する能力を持たなければならない(MUST)。 注：(WiFiホットスポットの"ウォールドガーデン"で一般に見つかるような) 透過的にすべてのDNS問い合わせを横取りし、署名付きの問い合わせに対して 未署名の応答を返すあらゆるDNSプロキシーは、やはりTSIG認証を失敗させる。 5. DHCPとDNSの相互作用 本文書は主としてDNSプロキシーに関するものだが、大半の消費者は ネットワーク環境設定を取得するためにDHCP[RFC2131]に依存している。 そのような設定は、クライアントマシンのIPアドレス、サブネットマスク、 デフォルトゲートウェイに加えて、DNS関連の設定も含んでいる。 従って、DHCPがどのようにクライアントDNSの設定に影響するかを 調査することは妥当である。 5.1. DNSサーバー(DHCPオプション6) 大半のゲートウェイは、DHCPの"DNSサーバー(Domain Name Server)" オプション[RFC2132]の中で、自身のIPアドレスをデフォルトで提供する。 その結果、明示的に再設定しない限り、多数のDNSクライアントは デフォルト設定に従い、問い合わせをゲートウェイのDNSプロキシーに 送信するようになる。通常の場合、ブート時には正しい上流の設定情報が 不明であることを考えれば、これは当然の振る舞いである。 Bellis Best Current Practice [Page 7] RFC 5625 DNS Proxy Implementation Guidelines August 2009 大半のゲートウェイは、自身が使用するDNSの設定を、DHCPまたはPPP経由で ISPからWAN側インターフェースに提供される値によって学習する。しかし、 多くのゲートウェイは機器の管理者によってこれらの値を上書きできるのに 対し、一部のゲートウェイはプロキシーの転送機能を設定する際にISPから 提供された値だけしか使用せず、またその値をDHCP経由では提供しない。 そのような機器を使用する場合、DNSプロキシーの使用を回避する唯一の 方法は、クライアントのオペレーティングシステムにおいて必要な値を ハードコードすることである。これはデスクトップシステムでは許容される かもしれないが、定常的に異なる多数のネットワークで使用される モバイル機器では不適切である。 セクション3記載のように、エンドユーザーは指定された上流のリゾルバーに、 理想的にはスタブリゾルバーでハードコード化された設定をすることなく、 DNS問い合わせを直接送信できるようにすべきである(SHOULD)。 従って、ゲートウェイは、DHCPの"DNSサーバー"オプションの値を 機器管理者が設定できる機能をサポートすべき(SHOULD)であり、そのように することが推奨される(RECOMMENDED)。 5.2. ドメイン名(DHCPオプション15) DNSルートネームサーバーへのかなりの量のトラフィックは、不正なトップ レベルドメイン名に対するものである。そのようなトラフィックの一部は、 このDHCPオプションのデフォルト値を特定の値にしている特定の機器ベンダー に起因すると言ってよい。 "local"スコープのドメイン名サフィックスに関しては何も標準が存在しない ため、このオプションのデフォルト値は空であるべき(SHOULD)であり、 そのようにすることが推奨される(RECOMMENDED)。また、値が何も設定されて いない場合、このオプションが送信されてはならない(MUST NOT)。 5.3. DHCPリース ブロードバンドゲートウェイのある種のDHCPサーバーは(上述の通り) デフォルトでは"DNSサーバー"オプションで自身のIPアドレスを提供するが、 一旦WANインターフェースから上流のサーバーのアドレスを学習すると、 自動的にそのアドレスの提供を開始する。 一般に、この振る舞いは極めて望ましいものだが、エンドユーザーへの 影響は、使用環境でDHCPリースが取得されるのがWANリンクが確立される 前なのか後なのかに依存する。 WANリンクがダウンしている間にDHCPリースが取得される場合、DHCP クライアント(つまりDNSクライアント)はDHCPリースが更新されるまで 正しい値を受信しないだろう。 Bellis Best Current Practice [Page 8] RFC 5625 DNS Proxy Implementation Guidelines August 2009 ここで特定の推奨を与えるわけではないが、ベンダーはDHCPリースの 長さの考慮や、DHCPリースの更新を適切に行うことを強制する何らかの 仕組みを望むかもしれない。 もう一つの可能性として、リブート時にも同じ値をDHCP経由で自動的に 提供できるようにするため、学習した上流の値が不揮発性のメモリで 維持されるかもしれない。しかし、装置が移動されたり別のISPに接続 されたりした場合、不適切な値が初めに提供されるリスクがある。 あるいは、DHCPサーバーはWANリンクがダウンしている間は極めて短い (60秒といった)リースだけを発行し、WANリンクがアップして上流の DNSサーバーが既知となった後にだけ、より一般的なリース期間長に 復帰するといった振る舞いもあり得るかもしれない。実際、そのような 設定を使用すると、ブロードバンドゲートウェイにおいてDNSプロキシー 機能を実装する必要性を完全に回避できるかもしれない。 6. セキュリティに関する考慮点 本文書は新しいプロトコルを何も導入しない。しかし、以下に列挙される ような、ベンダーに向けたセキュリティに関連する推奨が幾つか存在する。 6.1. 偽造への耐性 DNSプロキシーは、通常の場合すべての機能を備えたリゾルバーではないが、 それでも幾つかの特徴を共有する。 上述した透過性に関する推奨にもかかわらず、多くのDNSプロキシーにおいて、 応答が正しいクライアントに経路付けられることを保証するために、外に向かう リクエストに対して新しい問い合わせIDを選択することが観測されている。 注: 問い合わせIDの変更は許容範囲であり、TSIG署名されたパケットのプロキシー 処理にも適合する。TSIG署名の計算はオリジナルのメッセージIDに基づくが、 メッセージIDはTSIG RRの中で配送されるからである。 各DNS問い合わせはランダムに生成された問い合わせIDを使用すべきだ、ということが 長年にわたり標準的なガイダンスとなっている。しかし、多くのプロキシーに おいて、連続するリクエストに対して連番の問い合わせIDを選択することが観測 されている。 DNSプロキシーは、[RFC5452]記載の関連する推奨、特にセクション9.2の 問い合わせIDと発信元ポートのランダム化に関する推奨に従うことが強く推奨 される(RECOMMENDED)。これはあらゆるNAT機能に含まれる発信元ポートの 選択にも適用される。 DNSプロキシーがNAT機能を持つブロードバンドゲートウェイ上で稼働している 場合、[RFC5452]のセクション10記載の、DNSの状態をどれくらいの期間維持 するかに関する推奨に従うべき(SHOULD)である。 Bellis Best Current Practice [Page 9] RFC 5625 DNS Proxy Implementation Guidelines August 2009 6.2. インターフェースとの対応付け 幾つかのゲートウェイは、内側(LAN側)と外側(WAN側)の両方のインター フェースをリスンするDNSプロキシーを保持することが観測されている。 この構成では、[RFC5358]記載のリフレクター攻撃を仕掛けるために プロキシーが使用されてしまう可能性がある。 ゲートウェイのDNSプロキシーは、デフォルトで装置のWAN側インターフェース からアクセスできるようにすべきではない(SHOULD NOT)。 6.3. パケットのフィルタリング 透過性の原則とロバストネス原則は、ファイアウォールのような、つまり 悪意あるトラフィックから内部ネットワーク上のシステムを保護することを 目的としたセキュリティ装置のパケットの詳細な検査(deep inspection)機能と 完全に適合するわけではない。 しかし、本質的に不正な形式のトラフィックと単に予期しないデータを含む トラフィックは明確に区別されるだろう。 パケットを破棄してもよい(MAY)不正なパケット例は以下を含む。 ・ 無効な圧縮ポインター(現行パケットの外側か、構文解析時にループを 生じさせるような場所を指し示している)を含む。 ・ 問い合わせ部、回答部、権威部、付加情報部のエントリー数が誤っている。 (ただし、切り詰めが発生するかもしれない状況では注意を要する)。 パケット破棄は、クライアントにオリジナルリクエストの再転送をくり返し 生じさせるが、クライアントは複数回の再転送間隔を経た後でなければ エラーを検知しない。 このような状況の場合、プロキシーはパケットを完全に破棄する代わりに、 クライアント向けの適切なエラー応答(例えばSERVFAIL)を合成すべき(SHOULD) である。これにより、クライアントはエラーを直ちに検知できるようになる。 7. Acknowledgements 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. Bellis Best Current Practice [Page 10] RFC 5625 DNS Proxy Implementation Guidelines August 2009 8. References 8.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008. Bellis Best Current Practice [Page 11] RFC 5625 DNS Proxy Implementation Guidelines August 2009 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009. 8.2. Informative References [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband Routers", February 2008, . [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on Broadband Routers and Firewalls", September 2008, . 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: http://www.nominet.org.uk/ Bellis Best Current Practice [Page 12]