- PR -

特定のドメインのみが名前解決出来ない

投稿者投稿内容
SHR
ベテラン
会議室デビュー日: 2006/06/15
投稿数: 99
投稿日時: 2007-05-21 18:21
なるほど、どうやら私の考えは見当違いであった模様。

>正しく登録されていなければ、他のNAMEサーバでも動かないはずですから。
ns.example.jpは引けて、ns.example2.jpが引けないかな?とか予想しました。
他のDNSではns.example2.jpでコケますがns.example.jpで解決して、
かなものさんの環境ではns.example2.jpでコケるとこで終ったりしてないかな?と。

しかし、そうなると謎なのがtraceした時の
> ;; Received 99 bytes from 202.12.30.131#53(B.DNS.jp) in 10028 ms
> dig: Couldn't find server 'ns.example2.jp': Name or service not known
JP DNS(b.dns.jp)に問い合わせて「知らん」と言われたのに、JPRSのwhoisでちゃんと返る…。

うーん、、、お手上げ…orz

※誤字修正5/21 18:24

[ メッセージ編集済み 編集者: SHR 編集日時 2007-05-21 18:22 ]
koji
常連さん
会議室デビュー日: 2004/11/04
投稿数: 36
お住まい・勤務地: 北海道
投稿日時: 2007-05-21 19:23
> # dig example.jp.
> ; <<>> DiG 9.2.1 <<>> example.jp.
> ;; global options: printcmd
> ;; connection timed out; no servers could be reached

> example.jp. 86400 IN NS ns.example2.jp.
> example.jp. 86400 IN NS ns.example.jp.
> ;; Received 99 bytes from 202.12.30.131#53(B.DNS.jp) in 10028 ms

expample.jpのNSを引くのに10sも掛かっているので結果として
connection timed outエラーになってしまうと思われます。

# /usr/sbin/named -c /path/to/named.conf -u bind
このように起動していたとしたら

# /usr/sbin/named -4 -c /path/to/named.conf -u bind
このように-4のオプションを付けてみるとうまくいくかもしれません。
未記入
会議室デビュー日: 2007/05/21
投稿数: 2
投稿日時: 2007-05-21 21:12
named.conf の内容ですが、

query-source address * port 53;
           ↓
//query-source address * port 53;

このようにすると変化はありますか?
かなもの
ベテラン
会議室デビュー日: 2006/08/07
投稿数: 62
投稿日時: 2007-05-22 18:01
レス有難う御座います。
進展がありました!

# /usr/sbin/named -4 -c /path/to/named.conf -u bind
起動スクリプトを変更する事や、namedの再起動が出来ない状況の為、
こちらを試す事が出来ませんでした。




query-source address * port 53;
           ↓
//query-source address * port 53;

forwardersを削ってキャッシュクリアした後にこちらを試した所、
名前解決する事が出来ました!

しかし、テストサーバも同様の設定をしてあり、そちらは名前解決が出来ます。
テストで一瞬だけ試しただけで、今はテストサーバを使う方に戻してあります。

query-source address の設定の意味を知る必要がありそうですね・・・。
かなもの
ベテラン
会議室デビュー日: 2006/08/07
投稿数: 62
投稿日時: 2007-05-22 19:41
追記です。

現在ここをにらめっこしています。
http://www.linux.or.jp/JM/html/bind/man5/named.conf.5.html

query-source address * port 53;
現在こういう設定になっていますが、これは手持ちのサーバが53番ポートしか使わないという意味になるんでしょうか?

又、この設定を消す事での考えられる影響範囲は、お解りますか?
未記入
会議室デビュー日: 2007/05/21
投稿数: 2
投稿日時: 2007-05-22 23:26
query-source address * port 53;

このように設定した場合、問合せ先(ns.example.jp)
に設置されているファイアウォールでブロックされて
しまっているという可能性は考えられないでしょうか?

※ファイアウォールの製品・設定にもよるかと思いますが・・・
かなもの
ベテラン
会議室デビュー日: 2006/08/07
投稿数: 62
投稿日時: 2007-05-26 07:17
レス有難うございます。

設定変更後の内容で今後運営していくのに、
確証が得られないと出来ないのが辛い所です。

同じバージョンのBINDで
query-source address * port 53;
この設定をしているのですが、本番環境では名前解決出来なくて、
テストサーバーだと出来るんですよね。

なので、「その設定が原因とは言えない」と言われてしまって・・・。
でも、実際設定を消すと出来るようになるんですよね・・・。

なんとか言いくるめて、設定変更するしか無いように感じてきました。

相手が、何かしらブロックしている可能性は、否定出来ないですね。
しかし、ns.example.jpの管理者から連絡が、一向に来る気配がないんですよね・・・。
a39
会議室デビュー日: 2005/01/26
投稿数: 5
投稿日時: 2007-05-28 14:22
引用:

# dig -d @ns.example2.jp. example.jp.
これが失敗しますが・・・

# dig -d @111.222.333.444 example.jp. ←(111.222.333.444はns.example2.jpのIP)
これは成功するのです。



プロトコルスタック問題ではないでしょうか.

example.jp と example2.jp とでは,NS RR の指す先の A RR 以外に AAAA RR があるかないかといった違いはありませんか?
kernel configuration で IPv6 が生かされていて,IPv6 の経路情報を与えていないのではないでしょうか?

ちょっと旧くて異なる応答の事例ですが,
BIND8 の dig では,IPv4 のみの kernel ですと AAAA RR も持つ所への query は,

;; res_nsend: Protocol not supported

となってしまったように思います.(BIND9 の dig では,kernel の IPv6 を殺してあれば,きちんと IPv4 にフォールバックします)
IPv4 アドレスを直接指定して到達できて,FQDN では到達できないということは,IPv6 アドレスを得て,IPv6 アドレスで query をかけたけれど応答がなかったということではないかと思いました.

テストサーバとの比較は,BIND の設定だけでなく,kernel オプションや,BIND のコンパイルオプションも比較した方が良いと思います.

スキルアップ/キャリアアップ(JOB@IT)