- - PR -
DNS逆引きの再帰問い合わせについて
1
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-01-05 22:52
いつもお世話になっています。
DNS逆引きの仕組みについて、ご質問させていただきます。 DNSに使用するアプリは一般的なbind-9です。 正引きの場合、再帰問い合わせを行うとルートサーバを経由してwhoisに登録されている DNSサーバに問い合わせが行われると思います。 逆引きの場合、再帰問い合わせを行うとルートサーバからどこのサーバが応答を返す、 という紐付けはどこで行っているのでしょうか？ Plalaと契約しているのですが、すべてプロバイダで管理されているのでしょうか？ というのも、現在DMZ上に外部DNSサーバがあり、外部から"202.233.xxx.xxx"の名前解決 を行うと外部DNSサーバに問い合わせが中継されず、名前解決できない状況となっております。 正引きは正常にできています。 また、外部からnslookupでこの外部DNSサーバを指定してあげると正常に名前解決できる のでbindの設定の問題ではないと思います。 プロバイダに確認すれば早いことなのですが、逆引きの再帰問い合わせの仕組みについ て理解しておきたいので、何卒ご教授の程、お願いします。 ■構成（外部DNSサーバ） RedHatEnterprise Linux ES5 bind-9.3.3-7.el5 [ メッセージ編集済み 編集者: ドラミ 編集日時 2008-01-05 22:56 ] | ||||||||
|
投稿日時: 2008-01-06 00:56
お世話になっております。
問題を整理させて下さい。 ＤＭＺ上に存在するＤＮＳサーバから、「202.233.xxx.xxx」というアドレスを逆引きした際に、結果が帰ってこない。 ただ、別の回線を通じて、そのプロバイダから提供されるＤＮＳサーバで「202.233.xxx.xxx」のアドレスを逆引きした場合は、正常に結果が帰ってくるということでよいでしょうか？ みそは、逆引きしようとしているアドレスとプロバイダの契約だと思います。 ここからは、自分の契約しているプロバイダのＩＰアドレスをＤＭＺ上あるＤＮＳサーバで解決したいという前提で書きます。 固定ＩＰ８などのサービスをプロバイダから受けており、かつ、ドメインと逆引きの契約を行っている場合、ＢＩＮＤ上に定義するＺＯＮＥの定義方法が独特である場合が非常に多いです。ＫＤＤＩの場合は、「128h.0.168.192.in-addr.arpa」のように、通常では定義し得ない形での設定をするように指定されていることがあります。これは、その回線のＩＰアドレスを保有するプロバイダが、外部から逆引きのアドレス要求を行われた際に、代理となり、そのＤＮＳサーバから本来の契約主のＤＮＳサーバにアクセスを行い、必要なＰＴＲレコードを取得し、要求元へ結果を返すという仕組みになっているパターンが多いです。 上位の回線事業者が代理アクセスするため、そのシステムによって、上記の通りＺＯＮＥの定義名称が違うことがあります。 プロバイダからの逆引きの指定ＺＯＮＥの確認と、逆引きアドレスの要求が、アクセス制限されていないかを確認してみてください。 結果的に、逆引きのアドレスもルートからだんだんと降りてくる形になります。 ただし、最終的に自分が所持しているアドレス範囲の逆引きの要求は、要求元からが直接自分が設定したＤＮＳサーバに来るのではなく、上位回線事業者側で止まり、上位回線事業者が用意したシステムから要求されるという点がポイントだと思います。 ただし、これは契約やプロバイダ等によって異なります。 一般的なフレッツ網を利用した固定ＩＰアドレス提供サービスでは上記のようパターンが多いですが、詳細はプロバイダへご確認ください。 | ||||||||
|
投稿日時: 2008-01-06 10:17
プロバイダによって異なっていて、おおむね以下のどちらかに分類できると思います。 ・RFC 2317 に従ってユーザのDNS サーバに委譲する ・逆引きの設定をプロバイダが行う ※いずれの場合も別途申請が必要な場合もあるかもしれません。
202.233.xxx.xxx であれば、xxxx.xxxx.233.202.in-arpa.arpa. (PTR) に対する要求を解決できる必要があります。 解決の方法は正引きの場合とほぼ同様で、以下のような流れになります。 1. 最初にルート・サーバに問い合わせて arpa の NS を調べる。 $ dig @a.root-servers.net. -c IN -t NS arpa. 2. arpaゾーンを管理するネーム・サーバに問い合わせて in-addr.arpa の NS を調べる。 $ dig @a.root-servers.net. -c IN -t NS in-addr.arpa. 3. in-addr.arpaゾーンを管理するネーム・サーバに問い合わせて 202.in-addr.arpa の NS を調べる。 $ dig @a.root-servers.net. -c IN -t NS 202.in-addr.arpa. ;; ANSWER SECTION: 202.in-addr.arpa. 86400 IN NS ns-sec.ripe.net. 202.in-addr.arpa. 86400 IN NS tinnie.arin.net. 202.in-addr.arpa. 86400 IN NS ns1.apnic.net. 202.in-addr.arpa. 86400 IN NS ns3.apnic.net. 202.in-addr.arpa. 86400 IN NS ns4.apnic.net. 202.in-addr.arpa. 86400 IN NS dns1.telstra.net. 4. 202.in-addr.arpaゾーンを管理するネーム・サーバに問い合わせて 233.202.in-addr.arpa の NS を調べる。 $ dig @ns1.apnic.net. -c IN -t NS 202.233.in-addr.arpa. ;; AUTHORITY SECTION: 233.202.in-addr.arpa. 86400 IN NS a.dns.jp. 233.202.in-addr.arpa. 86400 IN NS b.dns.jp. 233.202.in-addr.arpa. 86400 IN NS d.dns.jp. 233.202.in-addr.arpa. 86400 IN NS e.dns.jp. 233.202.in-addr.arpa. 86400 IN NS f.dns.jp. 5. ・・・ ※返された結果はあくまでサンプルであり予告なしに変更される場合があります。 プロバイダに問い合わせる前に、実際に自分の IP アドレスに対する逆引きがどこまで解決できているのか追ってみられるとよいしょう。 [ メッセージ編集済み 編集者: あんとれ 編集日時 2008-01-06 10:19 ] | ||||||||
|
投稿日時: 2008-01-07 10:20
Dr.Doraemonさん
ご回答ありがとうございます。 >>ＤＭＺ上に存在するＤＮＳサーバから、「202.233.xxx.xxx」というアドレスを逆引き >>した際に、結果が帰ってこない。 >>ただ、別の回線を通じて、そのプロバイダから提供されるＤＮＳサーバで「202.233.xxx.xxx」 >>のアドレスを逆引きした場合は、正常に結果が帰ってくるということでよいでしょうか？ ⇒逆になります。DMZ上のDNSサーバから、「202.233.xxx.xxx」というアドレスを逆引き すると正常に名前解決できます。 別の回線を通じて、DMZ上のDNSサーバが保持している「202.233.xxx.xxx」のアドレスを 逆引きできない、といった事象が発生しています。 >>ただし、最終的に自分が所持しているアドレス範囲の逆引きの要求は、要求元からが直接自分が設定したＤＮＳサーバに来るのではなく、上位回線事業者側で止まり、上位回線事業者が用意したシステムから要求されるという点がポイントだと思います。 ⇒これでした。 上位回線事業者へ逆引きの権限委譲の設定は行っていませんでした。 私は今まで上位回線事業者が「202.233.xxx.xxx」のアドレスをDMZ上にいるDNSサーバへ中継してくれるものと思っていました。 しかし、再帰問い合わせではDMZ上のDNSサーバまで問い合わせが来ることはないということで納得できました。 さきほどPlalaへ逆引き権限委譲の設定をお願いいたしました。 これで解決できそうです。ありがとうございました。 | ||||||||
|
投稿日時: 2008-01-08 01:16
こんばんは。
脱線ではありますが、一応ツッコミを入れておきます。 結果的には同じになるでしょうが、再帰問い合わせは次のようになります。 例として、atmarkit.co.jp の mx ml02.itmedia.co.jp に付随する aレコード、202.218.219.6 の逆引きで。 1. 既知のルートサーバの1つ ( 例えば 198.41.0.4 ( a.root-servers.net ) ) に、6.219.218.202.in-addr.arpa の ptrレコードを問い合わせる $ dig @198.41.0.4 6.219.218.202.in-addr.arpa ptr +norecursive ⇒ ルートサーバは、サブドメイン 202.in-addr.arpa を委譲しているため、authorityのみを返す。 例えば、202.in-addr.arpa. in ns ns1.apnic.net. 等 2. 委譲先DNSサーバのIPアドレスを調べる ( ルートサーバから調べる手順が煩わしいため、手抜き ) ns1.apnic.net の aレコードが 202.12.29.25 と分かる ※手で試すなら、dig ns1.apnic.net で十分 3. 202.in-addr.arpa委譲先に 6.219.218.202.in-addr.arpa の ptrレコードを問い合わせる $ dig @202.12.29.25 6.219.218.202.in-addr.arpa ptr +norecursive ⇒ サブドメイン 218.202.in-addr.arpa を委譲しているため、authorityのみを返す 例えば、218.202.in-addr.arpa. in ns a.dns.jp. 4. 委譲先DNSサーバのIPアドレスを調べる ( ルートサーバから調べる手順が煩わしいため、手抜き ) a.dns.jp の aレコードが 203.119.1.1 と分かる 5. 218.202.in-addr.arpa委譲先に 6.219.218.202.in-addr.arpa の ptrレコードを問い合わせる $ dig @203.119.1.1 6.219.218.202.in-addr.arpa ptr +norecursive ⇒ サブドメイン 219.218.202.in-addr.arpa を委譲しているため、authorityのみを返す 例えば、219.218.202.in-addr.arpa. in ns ns01.itmedia.co.jp. 6. 委譲先DNSサーバのIPアドレスを調べる ( ルートサーバから調べる手順が煩わしいため、手抜き ) ns01.itmedia.co.jp の aレコードが 219.127.150.1 と分かる 7. 219.218.202.in-addr.arpa委譲先に 6.219.218.202.in-addr.arpa の ptrレコードを問い合わせる $ dig @219.127.150.1 6.219.218.202.in-addr.arpa ptr +norecursive ⇒ 当該レコードの権限を持っているサーバのため、answerが返る 6.219.218.202.in-addr.arpa. in ptr ml02.itmedia.co.jp. 以上より、202.218.219.6 の逆引きは ml02.itmedia.co.jp と分かる、という具合です。 | ||||||||
|
投稿日時: 2008-01-10 09:47
あんとれ様、angel様
返信が遅くなりましたが、ご回答ありがとうございます。 逆引きの再帰問い合わせは、こういう調べ方をするのですね。 大変参考になりました。 こちらの状況としては上位回線業者へ逆引きのセカンダリを登録して解決いたしました。 ありがとうございました。 | ||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。