HOME情報セキュリティ情報セキュリティ対策脆弱性対策ドメイン名の登録とDNS サーバの設定に関する注意喚起

本文を印刷する

情報セキュリティ

ドメイン名の登録とDNS サーバの設定に関する注意喚起

最終更新日 2005年 6月27日

独立行政法人 情報処理推進機構
セキュリティセンター

インターネット上で運用されているDNSサーバの中には、管理されていない状態のものがあります。ドメイン情報に偽の情報を記述させることで、第三者がそのドメイン名の持ち主であるかのようにふるまえてしまう(ドメインの乗っ取り)というものです。

ドメイン名のDNSサーバとして外部のドメイン名を持つホストを登録している場合、状況によってはドメインが乗っ取られてしまいます。このような状態は、セカンダリDNS サーバの廃止や委託業者の変更などの理由によるドメイン情報の管理不手際により、発生します。

ドメインの乗っ取りが行われた場合、以下の危険性があります。

  • フィッシング詐欺への利用
  • メールの盗み見

以下の情報を参考に、DNSサーバの設定を見直してください。

ドメイン名の登録と、DNSサーバの設定に関する注意喚起

外部に向けて運用されているDNSサーバの中には、セカンダリDNSサーバの廃止や委託業者の変更などの理由により、ドメインの乗っ取りが(*1)可能な、危険な状態で放置されているものがあります。

DNS サーバに登録し公開している情報において、外部のドメイン名を持つホストをドメイン名の DNS サーバとして指定している場合、ドメインの乗っ取りが行えてしまう可能性があります。

ドメインの乗っ取りが行われた場合、企業のウェブサイトを同じURLで全く別のサイトに誘導することでフィッシング詐欺に利用されたり、電子メールを第三者のサーバに誘導されて盗まれてしまう危険性があります。

(*1)ドメイン情報に偽の情報を混入させることにより、あたかも第三者がドメイン名の持ち主であるかのようにふるまえてしまう状態

問題と脅威の可能性

名前解決を行う DNS はインターネットにおける基本的かつ重要なサービスです。メールの宛先も、ウェブサイトの URL も、ドメインを管理する DNSサーバへの問いあわせができなければ外部からアクセスできなくなります。そのため、企業などでは冗長性を確保するために、セカンダリサーバを外部の業者等に委託することがあります。

しかし、セカンダリーサーバを廃止したり、委託先業者との契約が切れた等の理由やタイプミスなどによる設定間違いにより実状とサーバの設定が乖離してしまいドメイン名の設定が変更されないままである場合、セキュリティ上の問題が発生する可能性があります。

特に、委託先業者等の利用していたドメイン名が、有効期限切れで消失もしくは消失真近の場合は注意する必要があります。

DNS の問い合わせは、上位の DNS サーバに登録されたホストに均等に分散して送信されます。そのため、悪意ある第三者に委託先業者の利用していたドメイン名を取得され、上位のDNSサーバに登録されたDNSサーバ名を騙られた場合、一部の問い合わせが悪意ある第三者のDNSサーバに送信されることになります。

結果として、ドメインを乗っ取られ、偽の DNS 情報を流されてしまう危険性があります。

偽のDNS情報を流された場合、一般のユーザが正規のウェブサイトにアクセスしているつもりで、全く別のウェブサイトに誘導されてしまう危険性があります。フィッシング詐欺などの認証情報収集の一手法として、このようなドメイン名の乗っ取りによるウェブサイトの偽造が行われる事が考えられます。

また、偽のDNS情報を流すことでそのドメイン名のアドレスを持つ電子メールの宛先を変えることが出来るため、送信した筈のメールが第三者に渡ってしまう危険性があります。

技術情報

 以下を参考に、ご利用中のドメイン名が正しく運用されているかをご確認ください。

◎ドメイン名が安全に運用されているかの確認方法

ご利用中のドメイン名(以下、該当ドメイン名)について、正式なDNSサーバのみがドメイン名のDNSサーバとして登録されているか、ご確認ください。

DNSサーバの管理者は、DNS情報を自由に変更することができます。信頼できない管理者に委託してしまった場合、DNS情報の異常による不具合や、情報漏洩の切っ掛けとなる危険性があります。

また、初期の段階で信頼できる委託先管理者であっても、諸処の事情で現在は無関係の第三者が所有しているDNSサーバをNSレコードに登録してしまっている場合、そのDNS サーバにより該当ドメインの乗っ取りが行えてしまいます。

特に、元委託先管理者のDNSサーバ名のドメイン名が誰でも取得できる状態にある場合、ドメイン名を取得することで誰でも該当ドメイン名の乗っ取りが行えてしまう危険性があります。

その場合は、直ちに NS レコードの登録を修正し、危険な DNS サーバに依存しないように修正してください。

まず、レジストリへの登録情報を修正する必要があります。レジストリの登録の変更には、該当ドメイン名を登録した際の業者を経由する方法が一般的です。変更依頼を出して、レジストリの登録情報から危険なDNS サーバを削除してください。

そして、該当ドメイン名の正式な DNS サーバからも、同様に危険な DNS サーバを削除してください。

 以下を参考に、ドメインが安全に運用されているかをご確認ください。

該当ドメイン名の正式な DNS サーバの一覧を把握していますか?
まず、どのサーバが正式に該当ドメイン名の DNS サーバとして運用されているのか確認してください。
レジストリへの登録情報は正式な DNS サーバの一覧と一致していますか?
Whoisで該当ドメイン名を検索した時の情報が正式なDNSサーバの一覧と一致していない場合、レジストリへの登録が間違っています。レジストリへの登録情報を修正してください。
上位の DNS サーバに登録されたNS レコードと、NSレコードに登録されたDNS サーバの NS レコードは同一ですか?
同一でない場合、上位の DNS サーバの登録情報か、DNS サーバの登録情報のいずれかが間違っています。該当ドメイン名に関するNS レコードを、上位の DNS サーバと関連する全ての DNS サーバ間で同一に保ってください。
NSレコードに登録された全てのホストが、該当ドメイン名の DNS サーバとして動作していますか?
NS レコードに登録された全てのホストは、該当ドメイン名の DNSサーバとして動作し、同じDNS情報を返す必要があります。サーバの停止や、DNSサーバとして動作していない、あるいは該当ドメイン名の DNS 情報を持っていない,という状態は極力避けてください。
NS レコードに登録された DNS サーバの間で、該当ドメイン名の DNS 情報は同一に保たれていますか?
登録された情報が同一でない場合、DNSサーバ間でDNS情報の更新がうまく行えていない可能性があります。DNS情報は同一に保つようにしてください。
NSレコードに該当ドメイン名以外のドメイン名を持つDNSサーバが登録されている場合、そのDNSサーバは、現在も関係のある業者等が管理している、信頼できるDNS サーバですか?
◎DNS サーバの登録情報の確認手法

Whoisを使うことで、どのホストが正式なDNSサーバとしてレジストリへ登録されているかを確認できます。Whoisサーバはレジストリ毎に違い、JPドメインでは whois.jprs.jp となっています。

UNIX 環境などで whois(1) が利用できる場合は、下記のようにすることで調査できます。whoisの実装によっては、サーバの指定が無くても動作する場合もあります。

$ whois -h [レジストリの Whois サーバ] [調査したいドメイン名]

Whoisによる調査は、コマンドを利用する方法だけではなく、ウェブサイトを利用する方法もあります。多くのレジストリはウェブサイトからの検索方法を提供しています。日本であればwhois.jprs.jp から検索できます。その他のgTLD, ccTLD については IANA の情報を参照してください。

また、DNSサーバにNSレコードの問い合わせを行うことで、どのホストがDNSサーバとして登録されているかを調査できます。

調査したいサーバは、可能ならばキャッシュの影響を避けるために、IP アドレスで指定してください。

UNIX 環境などで dig(1) が利用できる場合は、

$ dig @[調査したいサーバ] -t ns [調査したいドメイン名]

とする事で、調査したいドメイン名のNSレコードが調査できます。ANSWER SECTIONにあるのが、そのドメイン名のリソースレコードです。flags に aa が含まれていれば、調査したドメイン名に対して権威サーバとして動作しているサーバからの応答となります。

dig(1) のかわりに dnsq(1) を利用しても同様の調査ができます。dnsq の場合は、以下のようになります。返答の中にauthoritative があれば、aa が含まれる応答です。

$ dnsq ns [調査したいドメイン名] [調査したいサーバ]

Microsoft Windows では、コマンドプロンプトから nslookup を使うことで調査ができます。Non-authoritative answer: がでなければ、aa が含まれる応答です。

> nslookup -q=ns [調査したいドメイン名] [調査したいサーバ]

◎具体的な確認の例

では、dig を使って調査を行ってみましょう。ここでは、example.jp というドメイン名を調査するとします。
※example.jp は例示用に予約されたドメイン名です。下記の情報は実在の情報とは異なります。

まずは、whois を利用して、example.jp のレジストリ登録を確認します。

$ whois -h whois.jprs.jp example.jp
Domain Information: [ドメイン情報]
[Domain Name] EXAMPLE.JP

[登録者名] Jhon Smith
[Registrant] Jhon Smith

[Name Server] ns.example.jp
[Name Server] ns.foo.test

[登録年月日] 19XX/01/01
[有効期限] 2010/01/01
[状態] Connected (19XX/01/01)
[最終更新] 19XX/01/01 00:00:00 (JST)

ns.example.jp と ns.foo.test が NS として登録されていることがわかります。この ns.foo.testというホストは、昔セカンダリ DNS サーバを委託していた組織のものとわかりました。example.jp のレジストリ登録から外す必要があります。

念のため、それぞれの DNS サーバについての登録情報を調査します。

$ dig @ns.example.jp -t ns example.jp
; <<>> DiG 9.2.4 <<>> @ns.example.jp -t ns example.jp
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1458
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2 ADDITIONAL: 2

;; QUESTION SECTION:
;example.jp. IN A

;; AUTHORITY SECTION:
example.jp. 345600 IN NS ns.example.jp
example.jp. 345600 IN NS ns.foo.test

;; ADDITIONAL SECTION:
ns.example.jp 86400 IN A 172.16.0.1
ns.foo.test 86400 IN A 192.168.0.1

ns.example.jp の結果はレジストリ登録と同一でした。次は、ns.foo.testを調査します。

$ dig @192.168.0.1 -t ns example.jp
; <<>> DiG 9.2.4 <<>> @192.168.0.1 -t ns example.jp
;; global options: printcmd
;; connection timed out; no servers could be reached

IP アドレスではホストまでアクセスできないようです。念のためにホスト名でも試してみます。

$ dig @ns.foo.test -t ns example.jp
dig: Couldn't find server 'ns.foo.test': Name or service not known

DNS サーバが応答する以前に、ホストの名前解決ができません。whois でドメイン名を調べてみます。

$ whois foo.test
No match!!

foo.testのドメイン名自体が存在しません。この状態を放置すれば、foo.testというドメイン名を取得した第三者が、ns.foo.testというDNSサーバを作成すると、偽の DNS 情報が応答に含まれてしまうことになります。

直ちに、レジストリ登録と ns.example.jp の DNS 情報を修正して、example.jp の DNS サーバからns.foo.test をはずす必要があります。

謝辞

ドメイン名の登録と DNS サーバの設定に関する問題をご指摘いただいた次の方々に謝意を表します。

  • 東京工業大学 原子炉工学研究所 助教授 前野年紀氏
  • 中京大学情報科学部 助教授 / (株)リフレクション 取締役 鈴木常彦氏

更新履歴

2005年 6月27日 掲載
2005年 6月27日 謝辞を掲載
問題と脅威の可能性・DNSサーバの登録情報の確認手法・具体的な確認の例に追記