サブネットに分割したらnslookup命令で逆引きできなくなった

質問

よろしくお願いします。
NTTから借りているルータ内蔵型モデムのDMZホスト機能とやらを使ってみようと思い自宅ウェブサーバをDMZ領域に設置することにしました。
そのため今まで使っていたクラスCのプライベートアドレスを2つのサブネットに分割してネットワーク192.168.1.128をDMZ領域にしました。
それで、やっとこさウェブサーバのIPアドレスの変更やネームサーバの設定などを終えて通信できるようになったのですが
どうもリナックスのnslookup命令で逆引きしようとすると
** server can't find 130.1.168.192.in-addr.arpa: NXDOMAIN
と表示されるだけで名前解決が出来ません。
またnamed.confファイルと逆引き用のゾーンファイルを元の192.168.1.10に戻すと逆引きできるようになるという何とも不思議な現象なのです。
別に逆引きが出来なくても普通に通信が出来ているのだから問題ないのですが、やっぱりちょっと気持ちが悪いですよね。
ネットワークをサブネットに分割したのが関係しているのか、とかいろいろ考えてみたのですけど、いっこうに出来ないので、ここに聞きに来ちゃいました。
逆引きが出来ない原因に心当たりのある方はいらっしゃいますか。
どなたか教えてください。

回答No.8

noname#41381 · ベストアンサー

#6お礼より
>すると、なんてことでしょう!!依然として反応は遅いままです。
>これでは、ますます原因が分からなくなってしまいましたね。
>
いえいえ、かなり前進です。
少なくともルータは関係なかったので絞り込めます。

まず、現在サーバとクライアントが別セグメントになってしまっているので、
同一セグメントにしてみてください。
例えば
　サーバ：192.168.1.130/255.255.255.128
　クライアント：192.168.1.131/255.255.255.128

あと、SSH接続ということで、これも切り分けの為に、
SSHを使わずtelnetやftp接続を行ってみていただけますでしょうか。
（これは別セグメントの場合と同一セグメントの場合それぞれチェックしてみてください）

お礼

kanop_98さん、ご返信ありがとうございます。
なんとトラブルが解決いたしました。
SSHサーバに一瞬で接続出来るようになりました。
さて、いったい原因は何だったのかといいますと
スミマセン実は分からないのです。
あの後、何を行ったかといいますと
クライアントパソコンをサーバと同じDMZ領域に配置したのです。
つまりサーバのアドレスが192.168.1.130/25ですから
クライアントパソコンを192.168.1.131/25にしてみました。
すると今までが嘘のように一瞬で接続できるようになりました。
この後サーバとクライアントをクロス線で直接接続して確認してみると、これも一瞬で接続できました。
そして、さらに、その後もとの環境に戻しました。
すなわちクライアントパソコンのアドレスを192.168.1.3/25にしてルータを通してサーバと通信します。
そうしたら、なんと、これも一瞬で接続できてしまったというわけです。
そう言うわけで原因は全く不明なままですが解決できてしまいました。
どうも、お手数をおかけしました。

回答No.10

noname#41381

#9です。
おぉ解決ですか！おめでとうございます。

自分的には原因を判明させたかったとこですが...(しつこい性格なもんですみません^ ^;)
tcpdumpは障害発生中でないと意味がないので、またの機会でということで。

なにはともあれ、お疲れさまでした！

お礼

kanop_98さん、どうもお手数をおかけしました。
自分としても原因が分からないままですので
再度このような状況に陥ったときに困りそうです。
しかし、ひとまず問題は解決し
また現時点で待ちは全く発生していませんので
しばらく様子を見ることにします。
どうもありがとうございました。

回答No.9

noname#41381

#8自己レス２回目です。
>同一セグメントにしてみてください。
>
すみません、試されていたんですね。
意図する方向で補足されているのに、きちんと読まなくてはだめですね。反省です。

ちなみに、接続応答が早かった時期はあるのでしょうか？
DNS設定をする前とかでしょうか？

あと、キャプチャの件ですが...
Linuxとしかかかれていないので微妙ですが、
　tcpdump
だけ実行してみて、だらだら～と何かが出てきたら使用できます。（ctrl+cで終了）
ちょっと試してみてください。

お礼

ご返信ありがとうございます。
トラブル解決の要因はなんと「同一セグメントにしてみてください」という書き込みが2度にわたり、あったためです。
1度目、同一セグメントに配置しましたが遅いままで、このあとレスがなければ2度とこの方法は試さなかったでしょう。
2度目のレスで改めて同一セグメントにしたら、いきなりトラブル解決です!!

ちなみに申し遅れましたがサーバはレッドハットリナックス8.0で構築しました。
tcpdump命令を試してみたら出来ました。
すごいいっぱい文字が出てきました。

回答No.7

noname#41381

#6です。自己レスです。
>試しに同一セグメント(ルータなし)で接続してみてはいかがですか？
>
すみません。
サーバを仮想DMZホスト機能で外部に見せたら遅くなったということでしたね。
サブネットに分割という話も元々あったので、詳しく教えて頂けますでしょうか？
・ルータの機種名
・サーバのIPアドレス、サブネットマスク、デフォルトゲートウェイ
・クライアントのIPアドレス、サブネットマスク、デフォルトゲートウェイ
・クライアントからサーバへの接続はローカルIP or 仮想DMZでのグローバルIP？

お礼

補足要求の件につきまして次のとおり補足いたします。
引き続き、ご回答よろしくお願いします。

ルータの機種名:ルータはADSLモデムに内蔵されています。ADSLモデムは「ADSLモデム-NV」というものです。
サーバのIPアドレス:192.168.1.130
サブネットマスク:255.255.255.128
デフォルトゲートウェイ:192.168.1.129
クライアントのIPアドレス:192.168.1.3
サブネットマスク:255.255.255.128
デフォルトゲートウェイ:192.168.1.1
クライアントからサーバへの接続はローカルIP:192.168.1.130へ行っています。

以上より何か思い当たる点がありましたら、お知らせください。

回答No.6

noname#41381

毎度#5です。
しつこくてすみません。(なんとか解決して、安眠したいので...^ ^;)
応答が遅いというのは、telnet接続ということでいいでしょうか？

#5お礼より
>恐らくサーバにログインする際ルータの中で複雑な処理が行われているために遅くなっているのかも知れません。
>
ルータはそんな複雑な処理はしないです。
試しに同一セグメント(ルータなし)で接続してみてはいかがですか？

あと、sendmailでidentの応答待ちになる等、ある種の応答がフィルタされていて
接続待ちになっている可能性もありますね。
ネットワーク上でパケットをキャプチャするとか、サーバ側でtcpdumpを動かして
そこら辺の動きを見るといいかもしれません。

お礼

kanop_98さん、ご返信ありがとうございます。
しつこいだなんてとんでもない!
レスされるのが嫌なら、とっくに質問を締切ってますって。
僕等にとっては再レスをしてくださる回答者の方々こそが真の神ですよ。
ところで、なんと私のトラブルがkanop_98さんの安眠を妨げていたとは!!
それでは一刻も早く解決しなければいけませんね!!

まずサーバですがSSHサーバを利用しています。
そして、ご指摘のとおりルータなしで接続してみました。
メインパソコンとサーバ機をクロス線で直接接続して確認してみることにしました。
サーバ機のアドレスは192.168.1.130/25ですのでメインパソコンのアドレスを一時的に192.168.1.131にしてログイン操作を行ってみました。
すると、なんてことでしょう!!依然として反応は遅いままです。
これでは、ますます原因が分からなくなってしまいましたね。

あと、パケットをキャプチャする方法やtcpdumpにつきましては残念ながら良く分かりません。
ですので、もしよろしければ、やり方を教えていただけませんか。

回答No.5

noname#41381

#4お礼より
>しかし学校の環境では、どのパソコンからでも一瞬でテルネットサーバに接続できるので
>他にも解決法があるのではと考えたのですが、どうでしょうか。
>
DNSをきちんと設定していれば、レコードが存在しないという応答が返るので
逆引き待ちになることはないと思います。

どこからどこに対して、どういった接続方法が遅いかがわからなかったので、
とりあえず今回のような逆引き問題もあり、それが原因では？と思った次第です。
クライアントのIPに対してサーバからnslookup等で逆引きした場合はどうですか？
これで待ちをくらうようならDNSの問題でしょう。

お礼

kanop_98さん毎度お返事ありがとうございます。
ご指摘の「クライアントのIPに対してサーバからnslookupで逆引」を確認してみたところ
** server can't find 3.1.168.192.in-addr.arpa: NXDOMAIN
というメッセージが瞬時に返ってきました。
この結果、待ちは発生していないと思われます。

この現象はルータ内蔵型モデムの仮想DMZホスト機能を有効にしてから見られるようになりましたので
恐らくサーバにログインする際ルータの中で複雑な処理が行われているために遅くなっているのかも知れません。
しかし、はっきりした原因は分かりませんし現段階では、それほど頻繁にサーバにログインしませんので多少待たされますが我慢することにします。
この問題につきましては今後もっと頻繁にサーバを管理するようになって不便と感じたときに
改めて質問に参りたいと思います。

回答No.4

noname#41381

#3お礼より
>最近サーバにシェル接続するときのログイン動作が、とてつもなく遅くなったような(汗)。
>
サーバ側で接続元の逆引きが出来ていない為その待ちが発生していると考えられますね。
そのクライアントのIPアドレスを逆引きレコードを登録して様子をみてはいかがですか？
hostsに記載してしまってもいいと思います。

お礼

kanop_98さん、ご返信ありがとうございます。
これはクライアント機に名前を付けるということでしょうか。
しかし、これは、とても骨の折れる作業なのではないでしょうか。
いえ僕のメインパソコンは1台ですから簡単ですけど
例えば学校のクライアント機全てに名前を付けて、全てネームサーバに登録する事を考えると気が遠くなりそうです。
しかし学校の環境では、どのパソコンからでも一瞬でテルネットサーバに接続できるので
他にも解決法があるのではと考えたのですが、どうでしょうか。

回答No.3

noname#41381

サブネット化した逆引きはちょっとコツがいります。
in-addr.arpa.では各オクテット単位でしかゾーンが作れないからです。
ようは、
　192.168.1.0/25
　192.168.1.128/25
ともに、
　1.168.192.in-addr.arpa.
に含まれるのです。

今回は幸いなことに、192.168.x.xとローカルIPに対する逆引きゾーンなので、
たとえ、192.168.1.128/25であっても192.168.1.0/24を管理してしまっても問題ないですね。
＃192.168.1.0/25を別のDNSサーバとして立てていたり
＃Cクラス未満のグローバルIPの場合は上位への委任の依頼等が発生します

設定は、
<named.conf>
　　:
　zone "1.168.192.in-addr.arpa"IN {
　type master;
　file "1.168.192.in-addr.arpa.db";
　allow-update { none;};
};

<1.168.192.in-addr.arpa.db>
(128.1.168.192.in-addr.arpa.dbと同じ)

これでいけるのではないでしょうか？

あと、#2お礼より
>このモデムには静的ルーティング設定という機能がありますが、
>
これはルーティングの設定ですね。
"DNSルーティング"は問い合わせする内容によって、DNSサーバを振り分ける機能なので、
これとは別物です。
この機能は無さそうなので、気にする必要はありません。

お礼

kanop_98さん、ご返信ありがとうございます。
なんとオクテット単位で設定しなければいけなかったのですね。
ひょっとして、これって恥ずかしい質問しちゃいました??
お教えいただいたとおりnamed.confとゾーン名を変更しましたら逆引き出来るようになりました。
逆引きなんて使うことはありませんが気になっていたことが解決できて、すっきりしました。
どうもありがとうございました。
ところでサブネットに分割したのが関係しているのかどうかは分からないのですが
最近サーバにシェル接続するときのログイン動作が、とてつもなく遅くなったような(汗)。

回答No.2

noname#41381

ホスト側から逆引きが出来ないのか、全てからそのホスト情報の逆引きが出来ないのかがちょっと読み取れません。
bindのnamed.conf、ゾーンファイルの設定内容、namedのエラーログなどを補足していただけますか？

>NTTから借りているルータ内蔵型モデム
>
BA8000Proでしょうか？
これにはDNSルーティング機能がついているので、この設定も怪しいですね。
192.168.1.128/25を外部のNSに問い合わせしてしまっているとか。

お礼

Oct 27 17:56:08 linux named[7463]: shutting down: flushing changes
Oct 27 17:56:08 linux named[7463]: stopping command channel on 127.0.0.1#953
Oct 27 17:56:08 linux named[7463]: no longer listening on 127.0.0.1#53
Oct 27 17:56:08 linux named[7463]: no longer listening on 192.168.1.130#53
Oct 27 17:56:08 linux named[7460]: exiting
Oct 27 17:56:08 linux named[7484]: starting BIND 9.2.1 -u named
Oct 27 17:56:08 linux named[7484]: using 1 CPU
Oct 27 17:56:08 linux named[7487]: loading configuration from '/etc/named.conf'
Oct 27 17:56:08 linux named[7487]: no IPv6 interfaces found
Oct 27 17:56:08 linux named[7487]: listening on IPv4 interface lo, 127.0.0.1#53
Oct 27 17:56:08 linux named[7487]: listening on IPv4 interface eth0, 192.168.1.130#53
Oct 27 17:56:08 linux named[7487]: command channel listening on 127.0.0.1#953
Oct 27 17:56:08 linux named[7487]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Oct 27 17:56:08 linux named[7487]: dns_master_load: 128.1.168.192.in-addr.arpa.db:2: ignoring out-of-zone data (1.168.192.in-addr.arpa)
Oct 27 17:56:08 linux named[7487]: zone 128.1.168.192.in-addr.arpa/IN: could not find NS and/or SOA records
Oct 27 17:56:08 linux named[7487]: zone 128.1.168.192.in-addr.arpa/IN: has 0 SOA records
Oct 27 17:56:08 linux named[7487]: zone 128.1.168.192.in-addr.arpa/IN: has no NS records
Oct 27 17:56:08 linux named[7487]: zone bh.jp/IN: loaded serial 200310231
Oct 27 17:56:08 linux named[7487]: zone localhost/IN: loaded serial 42
Oct 27 17:56:08 linux named[7487]: running
Oct 27 17:56:08 linux 10月 27 17:56:08 named: named起動 succeeded

NTTから借りているルータ内蔵型モデムはADSLモデム-NVというものです。
このモデムには静的ルーティング設定という機能がありますが、これはご指摘のDNSルーティング機能とは別物でしょうか。
しかし正引きは正常にできて逆引きだけができないので私的にはルータの設定は問題無いと思うのですがどうでしょうか。

以上の補足より、何か思い当たることがございましたら、是非とも教えてください。

補足

kanop_98さん、ご返信ありがとうございます。
補足要求に対しましては次のとおり補足しますので引き続き、ご回答よろしくお願いします。
nslookup命令はサーバ機にシェル接続して直接行いますので全てのホストから逆引きできないと思われます。
設定内容は次のとおりです。

<named.conf>
// generated by named-bootconf.pl

options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};

//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." IN {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

include "/etc/rndc.key";

zone "bh.jp"IN {
type master;
file "bh.jp.db";
allow-update { none;};
};

zone "128.1.168.192.in-addr.arpa"IN {
type master;
file "128.1.168.192.in-addr.arpa.db";
allow-update { none;};
};
</named.conf>

<128.1.168.192.in-addr.arpa.db>
$TTL 86400
1.168.192.in-addr.arpa. IN SOA linux.bh.jp. burn.bh.jp. (
200310271 ;Serial
3600 ;Refresh
3600 ;Retry
604800 ;Expire
86400 ; Minimum TTL
)
IN NS linux.bh.jp.

130 IN PTR linux.bh.jp.
</128.1.168.192.in-addr.arpa.db>

BINDの起動ログ(一部省略)は次のとおりです。
Oct 27 17:37:26 linux sshd(pam_unix)[7330]: session opened for user burn by (uid=500)
Oct 27 17:37:34 linux 10月 27 17:37:34 su(pam_unix)[7359]: session opened for user root by burn(uid=500)
Oct 27 17:55:10 linux named[1956]: shutting down: flushing changes
Oct 27 17:55:10 linux named[1956]: stopping command channel on 127.0.0.1#953
Oct 27 17:55:10 linux named[1956]: no longer listening on 127.0.0.1#53
Oct 27 17:55:10 linux named[1956]: no longer listening on 192.168.1.130#53
Oct 27 17:55:11 linux named[1953]: exiting
Oct 27 17:56:04 linux 10月 27 17:56:04 named: named停止 failed
Oct 27 17:56:04 linux named[7460]: starting BIND 9.2.1 -u named
Oct 27 17:56:04 linux named[7460]: using 1 CPU
Oct 27 17:56:04 linux named[7463]: loading configuration from '/etc/named.conf'
Oct 27 17:56:05 linux named[7463]: no IPv6 interfaces found
Oct 27 17:56:05 linux named[7463]: listening on IPv4 interface lo, 127.0.0.1#53
Oct 27 17:56:05 linux named[7463]: listening on IPv4 interface eth0, 192.168.1.130#53
Oct 27 17:56:05 linux 10月 27 17:56:05 named: named起動 succeeded
Oct 27 17:56:05 linux named[7463]: command channel listening on 127.0.0.1#953
Oct 27 17:56:05 linux named[7463]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Oct 27 17:56:05 linux named[7463]: dns_master_load: 128.1.168.192.in-addr.arpa.db:2: ignoring out-of-zone data (1.168.192.in-addr.arpa)
Oct 27 17:56:05 linux named[7463]: zone 128.1.168.192.in-addr.arpa/IN: could not find NS and/or SOA records
Oct 27 17:56:05 linux named[7463]: zone 128.1.168.192.in-addr.arpa/IN: has 0 SOA records
Oct 27 17:56:05 linux named[7463]: zone 128.1.168.192.in-addr.arpa/IN: has no NS records
Oct 27 17:56:05 linux named[7463]: zone bh.jp/IN: loaded serial 200310231
Oct 27 17:56:05 linux named[7463]: zone localhost/IN: loaded serial 42
Oct 27 17:56:05 linux named[7463]: running

回答No.1

mld_sakura

「ネットワークをサブネットに分割した」のではなく、セグメント分割したのではないのですか？？

お礼

ご返信ありがとうございます。
たぶんセグメント分割ではないと思います。
NTTからレンタルしているルータ内蔵型モデムの仮想DMZホスト機能を使ってDMZ領域を作成しました。
現在の状態は
192.168.1.0/255.255.255.128
のローカルエリア領域と
192.168.1.128/255.255.255.128
の仮想DMZ領域の2つのサブネットに分割している状態で、この2つのサブネットはルータ内蔵型モデムのインターフェース192.168.1.1および192.168.1.129と、それぞれ接続されている状態です。
各ワークステーション機はローカルエリア領域192.168.1.0
に接続されており
サーバ機だけが仮想DMZ領域192.168.1.128に接続されている状態です。
以上より、心当たりがありましたら教えてください。