☰

リバースDNSルックアップ時間を確認するコマンド/スクリプト

tag-icon • tag-icon linux networking shell-script dns
リバースDNSルックアップ時間を確認するコマンド/スクリプト

私はマスターデバイスが複数のスレーブデバイスと通信するプロジェクトを進めています。これを行うには、ネットワーク上のホストとの接続を確立する必要があります。しかし、時には中断されます。

その理由は、余分な時間がかかるからです。リバースDNSルックアップ。リストを確認または生成できるコマンドまたはスクリプトを教えてください。リバースDNSルックアップ時間。

番号を編集してください。 1

また、他のホストへの接続中に各要求にかかる時間のリストを取得できるように、rshソースコードにこのコマンドを追加できる場所を教えてください。

これにより、サーバーが停止する理由を見つけることができます。

ベストアンサー1

これらのいくつかは、使用されるスタブパーサによって異なります。たとえば、IPv6 AAAAレコードが返されたがIPv6接続がない場合、IPv6の問題が発生する可能性があります。

ソフトウェア（え、rsh？本当ですか？この答えは具体的ではありません）が独自の実装（たとえば、または）ではなくrshシステムパーサー（たとえば）を使用していると仮定すると、それを使用して何が起こっているかを確認できます。pingdighostgetent

$ time getent ahostsv4 www.google.com
$ time getent ahostsv6 www.google.com

上記の方法は、順方向検索と逆方向検索の両方を実行します（逆方向PTRまたは他の種類の検索を強制することはできませんが、getentA / AAAレコードにのみ興味があります）。

いくつかの便利なスクリプトがありますこの回答到着https://serverfault.com/questions/7056/whats-the-reverse-dns-command-line-utilityこれにより、（IPv4のみ）などの順方向および逆方向の検索を実行できますが、getent hostsPerlではこれを変更できます。

上記の両方の可能性は、nsswitchに関連するすべてのスイングとロータリーを含むシステムパーサーを使用するため、しなければならない動作はほとんどのアプリケーションと同じです。

クライアント側でテストすることを忘れないでくださいそしてサーバーの一方または両方がリバースルックアップを実行します。

ローカルパーサーを1つずつ確認することもできます。

$ while read opt p1 ;  do 
    [ "$opt" = "nameserver" ] && dig @$p1 www.google.com +short +identify; 
done < /etc/resolv.conf

そしてリバースDNSをチェックしてください。

$ dig www.google.com +short | xargs -n1 -i dig -x {} PTR +short +identify

この問題をさらにデバッグするには、次の点を確認する必要があります。

  • /etc/host.conf （リバースDNSによるスプーフィングチェックなど、さまざまなオプション）
  • /etc/resolv.conf(あなたのパーサー)
  • /etc/nsswitch.conf（確認するデータベース（例：/etc/hostsDNS、LDAPなど））
  • 出力dnstraceそして/またはdig +trace
  • /etc/gai.conf、存在する場合。とりわけ、これは、IPV6 AAAA レコードが A レコードの前にソートされるかどうかを制御します。
  • /etc/nscd.confnscd使用する場合

Wiresharkとrootアクセス権を持っている場合は、オンラインでDNSリクエストを見ることができます。

# tshark -w dns.cap "port 53"
# tshark -V -ta -n -r dns.cap

（この-Vオプションは冗長ですが、開発者はプロトコル解析出力にタイムスタンプを入れるつもりはありませんでした。-O dns新しいバージョンではこの問題が解決された可能性があります。）

今すぐ使っていなくてもnscd見やすい一部オプションを使用するか、インタラクティブに実行すると-ddどうなりますか-ddd？ホスト（A / AAAA）レコードのみがキャッシュされるため、nscdPTRレコードは最終的に短い（デフォルトは20秒）寿命で否定的にキャッシュされます。

glibcパーサー（およびその他）は、 " options debug"/etc/resolv.confだけでなく、RES_OPTIONSデバッグを有効にするために使用できる環境変数もサポートしています。残念ながら、この便利な機能を使用するには、glibcをビルドするときにDEBUGを有効にする必要があるため、これは利用できません。

重い仕事のための最良の選択肢は次のとおりです。ltracestrace、システムコールを追跡する方法gethostbyname()と同様に、ライブラリ呼び出しを追跡してタイムスタンプを指定できますgethostbyaddr()。欠点：複数レベルの間接参照を提供するNSスイッチ、膨大な量の出力で迷子になることがあります。 Telnetで簡単に実行すると、3000行を超える出力が生成され、2つのペアは非表示になりましたgethostbyname()。

$ ltrace -ttT -e "getaddr*+gethost*+getname*" getent ahosts www.google.com

13:42:06.118718 getent->getaddrinfo("www.google.com", nil, { 0x2a, 0, 0, 0, 0, nil, 
nil, nil }, { 0x2a, 0x2, 0x3, 0, 16, { 2, 0, { 0x69187d4a } }, "www.google.com", { 
0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x93187d4a } }, nil, { 0x2a, 0x2, 0x3, 0, 16, {
2, 0, { 0x67187d4a } }, nil, { 0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x68187d4a } }, 
nil, ... } } } }) = 0 <0.042561>

0x69187d4a人が読めるIPアドレス（= 105、24、125、74 - > 74.125.24.105）を出力しないため、何が起こっているのかを理解するのは少し難しいです。ただし、NSSを介してすべての通話を表示できるため、これはおそらくローカルの問題を追跡するための最良の方法です。

上記の修正を使用しており、追加の修正~/.ltrace.confが必要な場合があります。

typedef size_t = int;
typedef sockaddr = struct(short, short, in_addr);
typedef addrinfo = struct;
typedef addrinfo = struct(hex(int), hex(int), hex(int), hex(int), size_t, sockaddr*, string, addrinfo *);

int getaddrinfo(string, string, addrinfo *, +addrinfo**);
int getnameinfo(sockaddr*, uint, +string, +uint, +string, +uint, uint);

おすすめ記事