前々からDNSをちゃんと構築したいと思っていたし、DNSに何かを尋ねたときに教えてくれていることがなんなのか、ということをちゃんと理解すべきだと思っていた。思っていたけれどもふんわりした知識のままで、なんとなく進んできた。
今回、業務でDNSに関する知識が必要になったので、少し力を入れて学習することにした。
環境
うちの中で名前解決を担当するのはSmaba ad dcに内蔵のDNS。
このテストのために”dns”で名前解決できるようにした。
自ドメインは myhome としてマスク表記し、テスト用に hogeserver.hogeddns.jp を利用する。
どちらも架空。
アウトバウンドの53/udpはあいていて、問い合わせにはUbuntu 18.04と20.04を使用した。
digの応答についての学習
DNSのパケット
digはDNSパケットの中身を中心とした情報を表示してくれるので、中身を理解するためにはパケットの知識が必要。
パケットについてはこちらで教えてもらった。
@IT / DNSパケットフォーマットと、DNSパケットの作り方
概要を理解した上でRFC。1035あたりが基本のようだ。
JPRS / DNS関連RFCの日本語訳を公開(RFC 1034、RFC 1035、RFC 3901)
その上で、DNS関連のRFC。こんなにあるのかー。
Qiita / DNS関連RFC一覧
RFCを探すのにIETFのDocument Searchを使ったりする一方で、Google検索では「htmlized」というボタンで表示されるドキュメントが見つかったりする。
英語が不自由すぎるので、こちらで翻訳結果と原文を並べてみるとなんとなく分かったりするので大助かりだった。
RFC文書を自動翻訳したページ一覧
※RFCが新しくなっているときには、Obsoleted by: nnnnという表記がされている。
digの応答
うちの中に立てているDNSに、うちの1つのホストについて尋ねてみた。
$ dig @dns temp.hogeserver.hogeddns.jp any +norec ; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> @dns temp.hogeserver.hogeddns.jp any +norec ; (4 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35073 ;; flags: qr aa ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;temp.hogeserver.hogeddns.jp. IN ANY ;; ANSWER SECTION: temp.hogeserver.hogeddns.jp. 900 IN A 192.168.11.2 ;; AUTHORITY SECTION: hogeserver.hogeddns.jp. 3600 IN SOA dns.myhome. hostmaster.myhome. 3 900 600 86400 3600 ;; Query time: 0 msec ;; SERVER: 24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn#53(24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn) ;; WHEN: Sat Jul 17 17:30:58 JST 2021 ;; MSG SIZE rcvd: 128
いままでANSWERセクションしか気にしていなかったが、よくよく見直してみると 4 servers found ってなんだろ?から始まって、flags? SERVERをよく見てみると、DNSにIPv6でアクセスしてるなこれ、しかもGUA?不思議なことばっかり。
digが答えてくれていることがなんなのか、改めて整理してみる。
n servers found
なぜ4つなんだろう?
; (4 servers found)
ざっくりservers foundを表示するあたりのソースを眺め、そこから呼び出される関数のリファレンスを見たところ、今回のように @dns とした場合、dnsの名前解決が行われ、見つかったIPアドレスの数が報告されるようだった。
実際、うちのdnsは正式なホスト名のCNAMEで、その正式なホスト名に4つのIPアドレスを定義しているので、納得。
global options
digは1ラインで複数の問い合わせができるようになっている。
dig <グローバルオプション> <問い合わせ><オプション> <問い合わせ><オプション> … 多分こう。
なので、グローバルオプションという考え方があるようだ。
;; global options: +cmd
デフォルトで+cmdがグローバルオプションとして付与されている。
Got answer
これ以降、応答パケットの内容がHEADER、QUESTION、ANSWER、AUTHORITY、ADDITIONALの順で表示される。
;; Got answer:
フォーマット上、ANSWERセクション以降は全てRR(リソースレコード)の形式になっている。
以下の表は、今回の問い合わせをベースとして関係しそうな値をまとめたものなので、書きっぷりは中途半端。
レコードのタイプ別の値を詳しく知るにはRFC 1035の 3.3. 標準的なRR を見て、必要に応じて関係するRFCも見るのがよさそう。
セクション | digの応答の情報 | 内容 |
---|---|---|
Header | opcode | RFC5935, RFC6195 0: Query [RFC1035] 1: IQuery [RFC3245] 2: Status [RFC1035] 3: available for assignment 4: Notify [RFC1996] 5: Update [RFC2136] 6-15: available for assignment |
status | RFC6195 0: NoError: No Error 1: FormErr: Format Error 2: ServFail: Server Failure 3: NXDomain: Non-Existent Domain 4: NotImp: Not Implemented 5: Refused: Query Refused 6: YXDomain: Name Exists when it should not 7: YXRRSet: RR Set Exists when it should not 8: NXPRSet: RR Set that should exist does not 9: NotAuth: Server Not Autheritative for zone 10: NotZone: Name not contained in zone 11-15: Available for assignment ※RCODEはOPT RR, TSIG RR, TKEY RRも使って表現されるらしい。 ※RFCで16以降も定義されている。 | |
ID | 問い合わせのID、応答にこのIDがコピーされる。 | |
flags | RFC1035, RFC2535 qr: Query=0, Response=1 aa: 権威サーバーからの応答 tc: メッセージが長すぎるので切り捨てた rd: 再帰検索の要求(Queryで設定) ra: 再帰的クエリのサポートあり z: Reserved for future use ad: サーバー側で応答内容を検証した cd: サーバーは未検証のデータを受け入れ可能 | |
QUERY | QDCOUNTか。Questionセクションの数。 | |
ANSWER | ANCOUNTか。Answerの数。 | |
AUTHORITY | NSCOUNTか。Authorityの数。 | |
ADDITIONAL | ARCOUNTか。Additionalの数。 | |
Question | QNAME | 問い合わせたドメイン名。 |
QCLASS | RFC1035 全てのCLASSを含む値のセット。 <CLASS> IN: 1 the Internet CH: 3 the CHAOS class HS: 4 Hesiod [Dyer 87] <QCLASS> *: 255 any class | |
QTYPE | RFC1035 全てのTYPEを含む値のセット。 <TYPE> A: 1 a host address NS: 2 an authoritative name server CNAME: 5 the canonical name for an alias SOA: 6 marks the start of a zone of authority WKS: 11 a well known service description PTR: 12 a domain name pointer HINFO: 13 host infomation MINFO: 14 mailbox or mail list information MX: 15 mail exchange TXT: 16 text strings <QTYPE> AXFR: 252 A request for a transfer of an entire zone *: 255 A request for all records | |
Answer | – | 問い合わせに対する回答で、今回だとAレコードの情報が戻ってきていた。 何を問い合わせたのかによってリソースの種類は変わる。 |
NAME | このリソースが関係するドメイン名。 | |
TTL | このリソースレコードをキャッシュできる時間(秒単位)。 | |
CLASS | RDATAのCLASSを表す。上のQuestion – QCLASS参照。 | |
TYPE | RDATAのTYPEを表す。上のQuestion – QTYPE参照。 | |
RDATA | リソースを説明する可変長の文字列。 | |
Authority | NAME TTL CLASS TYPE | AuthorityのSOAレコードの情報が戻ってきていた。 以降、SOAリソースレコードで返される値。 |
MNAME | このゾーンのオリジナル、または、プライマリソース。 | |
RNAME | このゾーンの責任者のメールボックス(“@”が”.”になっているので注意)。 | |
SERIAL | ゾーンデーターのバージョン番号。 | |
REFRESH | ゾーンが更新されるまでの時間。 | |
RETRY | ゾーンの更新が失敗したとき、再試行までの待ち時間。 | |
EXPIRE | ゾーンが権威を失うまでの時間の上限。 | |
MINIMUM | このゾーンからエクスポートされるリソースレコードの最小TTL。 | |
Additional | – | 今回の問い合わせでは、回答がなかった。 EDNS0の仕組みでは、このセクションを使って値を戻してくる。 ここではメモとしてEDNSの回答を取り上げてみる。RFC 6891 |
NAME | 必ず0(ルートドメイン) | |
TTL | 拡張RCODE、バージョン(必ず0)、DNSSEC OKビットとして使う。 フラグの残り15ビットはRFC 6891の時点では未定義で0を要求。 | |
CLASS | リクエスト者がUDPで受信できるデータ部分のサイズ(payload size)。 | |
TYPE | OPT: 41 option | |
RDATA | {属性,値}のペア。RDLENでそのサイズが示される。 |
もう少し調べてみると、Additionalはこんなケースで値が戻されることが分かった。
- ゾーン定義にNSとMXのRRを登録。
- NSとMXのAレコードを登録。
- digで -t any 指定をして、そのゾーンについて尋ねる。
この情報を聞いてきたということは、どうせNSやMXのIPアドレスを聞きたくなるのでしょ?として回答している模様。
Result
最後に問い合わせに関する情報を表示してくれる。
;; Query time: 0 msec
問い合わせに掛かった時間は0msecとされている。
ローカル環境とは言え0msなんて変だなーと思ったけれども、ソースを見ると送信直前と受信直後に時間を取り出している風の名前が付いていて、差分はマイクロ秒で取りだして、1000で割って表示している。ISCが意識しているのはマイクロ秒のレベルなのか…と思うと0msも不思議ではないのかもしれない。
よそのサーバーに問い合わせればさすがに0msにはならず、掛かった時間が表示される。
;; SERVER: 24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn#53(24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn)
これもざっくりとソースを見てみたが、前半と後半の2部構成になっている。
前半は、問い合わせに使用したソケットの情報を人が読める形式に変換し、結果として IPアドレス#ポート が表示されている。
後半は、クエリを管理する構造体のservnameで、結果として IPアドレス が表示されている。
ここまで見たところで事例を探してみたが、前半と後半のIPアドレスが違うケースが見つからない…
今まで調べたパケットの構造と、プログラムの流れを考えると、これが違うケースはないのでは?が現時点の結論だけど、違っていたらごめんなさい。
;; WHEN: Sat Jul 17 17:30:58 JST 2021
これは、結果表示のタイミングでホストの時間を取得して表示している。
;; MSG SIZE rcvd: 128
メッセージサイズとされている。
パケットサイズの境界と戦ったりする場合には重要な数字になりそうなんだけれど、ちょっと調査に力尽きた感。
こちらを読ませていただいてMSG SIZEという表記を考えると、DNSが返したメッセージの「中身のサイズ」と考えるのが妥当か。
JPRS / DNSメッセージサイズについて考える
リソースレコードの種類
digのmanpageに出てくるRR(Resourse Record)がなんなのかをボンヤリ理解する程度のメモ。
種別 | 名称 | 内容 | 参考情報 |
---|---|---|---|
SOA | Start Of Authority | ゾーンの権威情報。 | @IT / SOAレコードには何が記述されている? |
NS | Name Server | ゾーンの権威サーバー。 ゾーンを委任する際に使われる。 | JPRS / NSリソースレコード |
MX | Mail eXchange | メールサーバー。 優先度を付けて複数指定できる。 | JPRS / MXリソースレコード |
A | Address(? ※1) | ドメイン名のIPv4アドレス。 | JPRS / Aリソースレコード |
AAAA | Quad A | ドメイン名のIPv6アドレス。 | JPRS / AAAAリソースレコード |
CNAME | Canonical Name | エイリアスに対する正式名。 | JPRS / CNAMEリソースレコード |
PTR | PoinTeR | ドメイン名へのポインタ。 IN-ADDR.ARPAの中で他のドメインを指し示す。 | JPRS / PTRリソースレコード |
TXT | TeXT | テキスト文字列。 テキストの意味は使われ方に依存する。 | JPRS / TXTリソースレコード |
OPT | OPTion(? ※1) | OPT疑似リソースレコード。 EDNS0※2 で定義されている。 | JPRS / OPT疑似リソースレコード |
番外 SPF | Sender Policy Framework | メール送信のなりすましを防ぐ仕組みで使われる。 かつてはSPFというレコードがあった。 現在はTXTレコードに設定値を記載。 | JPRS / SPF |
※1 AレコードとOPTレコードについて、何の略なのかを確定する文を見つけられなかった。
※2 EDNS0(Extension Mechanisms for DN)は、従来のDNSの仕組みに影響を与えないようにしながらフォーマットを拡張。OPT疑似リソースレコードが使われる。
問い合わせ色々
digによる問い合わせについて調べてみた。
DNSが管理しているゾーンの一覧
方法なし。今まで調べたパケットの構造では、尋ねることも、答えることもできないように見える。
それに、このことはゾーンを管理している人(達)だけが知っていれば良く、そんな情報なにに使うの?という話。
ゾーン全体の情報
ゾーン転送の要求ができることはできる。
でも普通は帰ってこないと思うし、なにをやっているの?と聞かれたら困る話なので、よそが管理するDNSに向かって尋ねるのは止めておいた方が無難。
JPRS / 権威DNSサーバにおけるゾーン転送の設定に関する注意喚起
$ dig @dns myhome -t axfr +norec ; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> @dns .myhome axfr +norec ; (4 servers found) ;; global options: +cmd myhome. 3600 IN SOA hoge.myhome. hostmaster.myhome. 5843 900 600 86400 3600 ; Transfer failed.
DNS管理者は、セカンダリサーバーから -t axfr をつけてプライマリサーバーに尋ねることはできるだろうと思われる。
ゾーン転送される中身を知ることに使えそう。
ドメインの権威サーバー
まず、+nssearchで尋ねてみた。
$ dig example.com +nssearch SOA ns.icann.org. noc.dns.icann.org. 2021072001 7200 3600 1209600 3600 from server nnn.nnn.nnn.nnn in 114 ms. SOA ns.icann.org. noc.dns.icann.org. 2021072001 7200 3600 1209600 3600 from server nnn.nnn.nnn.nn2 in 123 ms. SOA ns.icann.org. noc.dns.icann.org. 2021072001 7200 3600 1209600 3600 from server 2001:nnnn:nnnn::53 in 124 ms.
※IPアドレスはnでマスクした。
ここで、答えてくれたサーバーにexample.comについて尋ねる。
$ dig @nnn.nnn.nnn.nnn example.com -t any +norec … ;; ANSWER SECTION: example.com. 86400 IN MX 0 . …
example.comについては、サンプル等で使うために用意されているものであって、あくまでもサンプル。
この方法で大体の場合は検索ができるのではないかと思われる。
試しに、うちのサーバーについて尋ねた(hogeでマスクしている)。
$ dig @nsa.hogeddns.jp hogeserver.hogeddns.jp -t any +norec … ;; ANSWER SECTION: hogeserver.hogeddns.jp. 300 IN MX 10 mx.hogeserver.hogeddns.jp. hogeserver.hogeddns.jp. 300 IN A nnn.nnn.nnn.nnn hogeserver.hogeddns.jp. 300 IN NS nsa.hogeddns.jp. hogeserver.hogeddns.jp. 300 IN NS nsb.hogeddns.jp. hogeserver.hogeddns.jp. 300 IN SOA hogeserver.hogeddns.jp. root.hogeddns.jp. 1626903593 600 180 600 300 hogeserver.hogeddns.jp. 300 IN TXT "hogehoge hogehoge" …
これでいくと…
このDDNSサービスでは、hogeserver.hogeddns.jpをSOAとして、NSを2つ貸してくれていて、ここでゾーン管理されている模様。また、このゾーンに関する連絡先にもなってくれている。
ドメインのメールサーバー
権威サーバーを探すときに、MXレコードが出てきている。
この他、以下のように尋ねることもできる。
$ dig @nsa.hogeddns.jp hogeserver.hogeddns.jp -t mx +norec … ;; ANSWER SECTION: hogeserver.hogeddns.jp. 300 IN MX 10 mx.hogeserver.hogeddns.jp. …
これは権威サーバーに直接尋ねたが、日頃使っているDNSサーバーに +norec せずに尋ねてみても答えは得られる。
ただ、これが正しいのかどうかは、経路上のDNSによるのだろう。
ドメインのテキストレコード
これも、権威サーバーを探すときに、TXTレコードが出てくる。
この他、以下のように尋ねることもできる。
$ dig @nsa.hogeddns.jp hogeserver.hogeddns.jp -t txt +norec … ;; ANSWER SECTION: hogeserver.hogeddns.jp. 300 IN TXT "hogehoge hogehoge" …
これも、権威サーバーに直接問い合わせているが、日頃使っているDNSサーバーに尋ねることもできる。
IPアドレスからホスト名が知りたい
いわゆる逆引き。
$ dig -x nnn.nnn.nnn.nnn
※IPアドレスはnでマスクした。
ただし、これで尋ねたとしても、逆引きゾーンがない場合には答えが返ってこない。
また、帰ってきたとしても、それが世の中的に使われるホスト名ではない場合がある。
awsに付けられている長いゾーンの名前が返ってきたり、プロバイダーのアクセスポイントに番号を振ったような名前が返ってきたりする。
逆引きできないこと自体は悪ではないので、逆引きできたらラッキーくらいの気持ちで試してみる程度。
名前をIPアドレスに変換する仕組み
これもきちんと理解しておかないと、どこに何を尋ねるべきなのかを判断できない。
JPRS / DNSのしくみと動作原理~インターネットを支え続けるDNS~
図7で説明されている問い合わせを試してみる。
まず、ルートサーバーに www.example.jp について尋ねたところ、ANSWER 0、AUTHORITY 8、ADDITIONAL 16が返ってきた。
$ dig @a.root-servers.net www.example.jp -t any … ;; AUTHORITY SECTION: jp. 172800 IN NS a.dns.jp. jp. 172800 IN NS d.dns.jp. jp. 172800 IN NS e.dns.jp. jp. 172800 IN NS f.dns.jp. jp. 172800 IN NS h.dns.jp. jp. 172800 IN NS g.dns.jp. jp. 172800 IN NS c.dns.jp. jp. 172800 IN NS b.dns.jp. ;; ADDITIONAL SECTION: a.dns.jp. 172800 IN A 203.119.1.1 <省略> …
そこで、jpサーバーに www.example.jp について尋ねた。
この後さらにzサーバーに www.example.jp について尋ねたが、存在しないゾーンらしく答えはなかった。
$ dig @a.dns.jp www.example.jp -t any … ;; AUTHORITY SECTION: jp. 900 IN SOA z.dns.jp. root.dns.jp. 1627010106 3600 900 1814400 900 …
そこで、メモとしてとあるドメインについて同じ手順で尋ねた結果を example.jp でマスクして記す。
$ dig @a.dns.jp www.example.jp -t any … ;; AUTHORITY SECTION: example.jp. 300 IN NS nsa.example.jp. example.jp. 300 IN NS nsb.example.jp. ;; ADDITIONAL SECTION: nsa.example.jp. 86400 IN A nnn.nnn.nnn.nnn nsb.example.jp. 86400 IN A nnn.nnn.nnn.nn2 … $ dig @nsa.example.jp www.example.jp -t any … ;; ANSWER SECTION: www.example.jp. 300 IN A nnn.nnn.nnn.nn3 www.example.jp. 300 IN A nnn.nnn.nnn.nn4 …
※繰り返しで恐縮だが、あくまでも、とあるドメインを example.jp でマスクしたもの。
名前解決がこの手順で行われるなら、浸透とか伝播とかいう世界は存在しない。
www.example.jpのTTLは5分に設定されており、普通の人が使うプロバイダーのDNSや企業のDNSにあるキャッシュDNSサーバー(フルリゾルバ)がキャッシュすることがあっても、キャッシュが破棄される5分を過ぎたら必ず新しい値で参照できることになる。
Ubuntuの名前解決
スタブリゾルバ
Ubuntuはsystemd-resolvedを使って名前解決が行われる。
/etc/resolv.confは/run/systemd/resolve/stub-resolv.confのシンボリックになっていて、動的に生成されている。これには、
- このファイルは編集しないでね。
- systemd-resolve –status で利用中のDNSがわかるよ。
- man:systemd-resolved.service(8)をみてね。
と書かれている。実際にステータスを見てみたところ、こんな応答だった。
$ systemd-resolve --status Global DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa … corp d.f.ip6.arpa home internal intranet lan local private test … Link 2 (ens33) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.nnn.nnn ← (1) 独自に立てたDNS 24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn ← (2) プロバイダー貸与のルーターが広告するDNSサーバー fdnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn ← (3) 独自に立てたIPv6用の広告、物理的には(1)のDNSサーバー DNS Domain: myhome
※IPアドレスはマスクしている。
ens33にはDNSが3つ用意されていることが分かった(まぁ、設定したとおりではあるのだけれど)。
スタブリゾルバによる名前解決
v6プラス契約なので、うちの中はIPv4とIPv6が混在している。
$ dig @dns hoge.example.net +norec
みたいな問い合わせをすると、digは”dns”の名前解決をした後で、hoge.example.netを”dns”に尋ねる。
“dns”の解決結果はというと、こんな結果だった。
$ ping dns PING dns(24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:0dns (24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:0dns)) 56 data bytes 64 bytes from 24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:0dns (24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:0dns): icmp_seq=1 ttl=64 time=0.090 ms …
/etc/gai.confは何も変えていなかったので、24nn:~が優先されており、プロバイダー貸与のルーターになっていた。
プロバイダー貸与のルーターは、「ローカルドメイン問合せテーブル」なる機能を有している。
そこに、うちの中で使用するドメインと、「プライマリDNSアドレス」としてそれぞれにSamba ad dcのDNSを設定してある。
では、dns.myhomeはどう定義されているのか、プロバイダー貸与のルーターに尋ねる。
$ dig @24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn -t any dns.myhome +norec ; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> @24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn -t any dns.myhome +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41478 ;; flags: qr aa ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;dns.myhome. IN ANY ;; ANSWER SECTION: dns.myhome. 900 IN CNAME hoge.myhome. ;; AUTHORITY SECTION: myhome. 3600 IN SOA hoge.myhome. hostmaster.myhome. 5843 900 600 86400 3600 ;; Query time: 4 msec ;; SERVER: 24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn#53(24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn) ;; WHEN: Tue Jul 20 07:23:04 JST 2021 ;; MSG SIZE rcvd: 105
確かに、hoge.myhomeの別名としてdns.myhomeを定義した、その通り。
では、hoge.myhomeはどのように定義されているのか尋ねる。
$ dig @24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn -t any hoge.myhome +norec
; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> @24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn -t any hoge.myhome +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18551
;; flags: qr aa ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;hoge.myhome. IN ANY
;; ANSWER SECTION:
hoge.myhome. 900 IN AAAA 24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:0dns
hoge.myhome. 900 IN A 192.168.nnn.nnn
;; AUTHORITY SECTION:
myhome. 3600 IN SOA hoge.myhome. hostmaster.myhome. 5843 900 600 86400 3600
;; Query time: 4 msec
;; SERVER: 24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn#53(24nn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn)
;; WHEN: Tue Jul 20 07:26:23 JST 2021
;; MSG SIZE rcvd: 187
こうして名前が解決が行われていた。
ちょっと不思議だったのは、プロバイダー貸与のルーターは、+norecを付けているのにhoge.myhomeに答えを聞きに行っていること。
このルーターは何も答えを持っていないのだから、通常の使い方であればよそに聞きに行っても何の問題もない。
でも、本当は知らないのに知っていると答えるこの動作、何かを本気で調べなきゃならないときには気をつけないと。
dig なんちゃって翻訳
Ubuntuのdigマニュアルは日本語化されていたが、ちょっと(だいぶ?)古いようだった。
ubuntu manuals / dig (18.04) 英語版
ubuntu manuals / dig (20.04) 英語版
そこで、20.04の英語版をなんちゃって翻訳。
途中までGoogle先生、途中からDeepL先生が教えてくれたものを、ほぼそのまま記載。
名前
dig – DNS調査ユーティリティ
書式
dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m] [-p port#][-q name] [-t type] [-v] [-x addr] [-y [hmac:]name:key] [[-4] | [-6]] [name] [type][class] [queryopt…]
dig [-h]
dig [global-queryopt…] [query…]
説明
digは、DNSネームサーバーに問い合わせるための柔軟なツールです。DNSルックアップを実行し、照会されたネームサーバーから返された回答を表示します。ほとんどのDNS管理者は、その柔軟性、使いやすさ、出力の明確さのために、digを使用してDNSの問題をトラブルシューティングします。他のルックアップツールは、digよりも機能が少ない傾向があります。
digは通常コマンドライン引数で使用されますが、ファイルからルックアップ要求を読み取るためのバッチ操作モードもあります。-hオプションを指定すると、コマンドライン引数とオプションの簡単な要約が出力されます。以前のバージョンとは異なり、digのBIND 9実装では、コマンドラインから複数のルックアップを発行できます。
特定のネームサーバーにクエリを実行するように指示されない限り、digは/etc/resolv.confにリストされている各サーバーを試行します。使用可能なサーバーアドレスが見つからない場合、digはクエリをローカルホストに送信します。
コマンドライン引数またはオプションが指定されていない場合、digは”.”のNSクエリを実行します(the root)。
${HOME}/.digrcを介してdigのユーザーごとのデフォルトを設定することができます。このファイルが読み取られ、その中のオプションがコマンドライン引数の前に適用されます。-rオプションは、予測可能な動作を必要とするスクリプトに対して、この機能を無効にします。
INおよびCHクラス名は、INおよびCHトップレベルドメイン名と重複しています。これらのトップレベルドメインを検索する場合は、-tおよび-cオプションを使用してタイプとクラスを指定する、-qを使用してドメイン名を指定する、あるいは”IN”と”CH”を使用します。
簡単な使い方
digの一般的な呼び出しは以下のようになります:
dig @server name type
この場合:
server
クエリするネームサーバーの名前またはIPアドレスです。これは、ドット付き10進表記のIPv4アドレス、またはコロン区切り表記のIPv6アドレスにすることができます。指定されたサーバー引数がホスト名の場合、digはそのネームサーバーにクエリを実行する前にその名前を解決します。
サーバー引数が指定されていない場合、digは/etc/resolv.confを参照し、そこにアドレスが見つかると、そのアドレスのネームサーバーにクエリを実行します。-4または-6オプションのいずれかが使用されている場合、対応するトランスポートのアドレスのみが試行されます。使用可能なアドレスが見つからない場合、digはクエリをローカルホストに送信します。応答するネームサーバーからの応答が表示されます。
name
検索するリソースレコードの名前です。
type
必要なクエリのタイプを示します – ANY, A, MX, SIGなど。typeは任意の有効なクエリタイプにすることができます。type引数が指定されていない場合、digはAレコードのルックアップを実行します。
オプション
-4
IPv4のみを使います。
-6
IPv6のみを使います。
-b address[#port]
クエリの送信元IPアドレスを設定します。アドレスは、ホストのネットワークインターフェイスのいずれか、または”0.0.0.0″または”::”の有効なアドレスである必要があります。オプションのポートは、”#<port>”を追加することで指定できます。
-c class
クエリクラスを設定します。デフォルトのクラスはINで、他のクラスは、Hesiodレコードの場合はHS、Chaosnetレコードの場合はCHです。
-f file
バッチモード: digは、指定されたファイルから処理するルックアップ要求のリストを読み取ります。ファイルの各行は、コマンドラインインターフェイスを使用してdigへのクエリとして与えられるのと同じ方法で編成する必要があります。
-k keyfile
指定されたファイルから読み取られたキーを使用して、TSIGを使用してクエリに署名します。キーファイルは、tsig-keygen(8)を使用して生成できます。digでTSIG認証を使用する場合、照会されるネームサーバーは、使用されているキーとアルゴリズムを知っている必要があります。BINDでは、これは、named.confで適切なキーとサーバーステートメントを提供することによって行われます。
-m
メモリ使用量のデバッグを有効にします。
-p port
デフォルトのポート53ではなく、サーバー上の非標準ポートにクエリを送信します。このオプションは、非標準ポート番号でクエリをリッスンするように構成されているネームサーバーをテストするために使用されます。
-q name
照会するドメイン名。これは、名前を他の引数と区別するのに役立ちます。
-r
${HOME}/.digrcからオプションを読み取りません。これは、予測可能な動作を必要とするスクリプトに役立ちます。
-t type
問い合わせるリソースレコードタイプです。有効なクエリタイプであればどれでもかまいません。BIND 9でサポートされているリソースレコードタイプの場合は、タイプニーモニック(”NS”や”AAAA”など)で指定できます。逆引き参照を示すために-xオプションが指定されていない限り、デフォルトのクエリタイプは”A”です。AXFRのタイプを指定することにより、ゾーン転送を要求できます。インクリメンタルゾーン転送(IXFR)が必要な場合は、タイプをixfr=Nに設定します。増分ゾーン転送には、ゾーンのSOAレコードのシリアル番号がNであったためにゾーンに加えられた変更が含まれます。
すべてのリソースレコードタイプは、”TYPEnn”として表すことができます。ここで、”nn”はタイプの番号です。リソースレコードタイプがBIND 9でサポートされていない場合、RFC3597で説明されているように結果が表示されます。
-u
クエリ時間をミリ秒ではなくマイクロ秒で出力します。
-v
バージョン番号を出力して終了します。
-x addr
アドレスを名前にマッピングするための簡略化された逆引き参照です。addrは、ドット付き10進表記のIPv4アドレス、またはコロンで区切られたIPv6アドレスです。-xを使用する場合、名前、クラス、および型の引数を指定する必要はありません。digは、94.2.0.192.in-addr.arpaのような名前のルックアップを自動的に実行し、クエリのタイプとクラスをそれぞれPTRとINに設定します。IPv6アドレスは、IP6.ARPAドメインでニブル形式を使用して検索されます。
-y [hmac:]keyname:secret
指定された認証キーでTSIGを使用してクエリに署名します。keynameはキーの名前であり、secretはbase64でエンコードされた共有シークレットです。hmacはキーアルゴリズムの名前です。有効な選択肢は、hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, またはhmac-sha512です。hmacが指定されていない場合、デフォルトはhmac-md5であるか、MD5が無効になっている場合はhmac-sha256です。
注: -yを使用すると、共有シークレットがコマンドライン引数としてクリアテキストで提供されるため、-kオプションを使用し、-yオプションは使用しないでください。これは、ps(1)からの出力、またはユーザーのシェルによって維持されている履歴ファイルに表示される場合があります。
問い合わせオプション
digは、ルックアップの実行方法と表示される結果に影響を与えるいくつかのクエリオプションを提供します。クエリヘッダーのこれらのセットまたはリセットフラグビットの一部、回答のどのセクションが出力されるかを決定するもの、およびタイムアウトと再試行の戦略を決定するものがあります。
各クエリオプションは、プラス記号(+)が前に付いたキーワードで識別されます。一部のキーワードは、オプションを設定またはリセットします。これらの前に文字列noを付けて、そのキーワードの意味を否定することができます。他のキーワードは、タイムアウト間隔などのオプションに値を割り当てます。それらの形式は+keyword=valueです。略語が明確であれば、キーワードは省略できます。たとえば、+cdは+cdflagと同等です。クエリオプションは次のとおりです:
+[no]aaflag
+[no]aaonlyと同義。
+[no]aaonly
クエリに”aa”フラグを設定します。
+[no]additional
応答のADDITIONAL SECTIONを表示します[表示しません]。デフォルトでは表示されます。
+[no]adflag
クエリのAD(authentic data)ビットを設定します[設定しません]。これは、サーバーのセキュリティポリシーに従って、すべての回答セクションと権限セクションがすべて安全であると検証されているかどうかを返すようにサーバーに要求します。AD=1は、すべてのレコードが安全であると検証されており、回答がOPT-OUT範囲からのものではないことを示します。 AD=0は、回答の一部が安全でないか、検証されていないことを示します。このビットはデフォルトで設定されています。
+[no]all
すべての表示フラグを設定またはクリアします。
+[no]answer
応答のANSWER SECTIONを表示します[表示しません]。デフォルトでは表示されます。
+[no]authority
応答のAUTHORITY SECTIONを表示します[表示しません]。デフォルトでは表示されます。
+[no]badcookie
BADCOOKIE応答を受信した場合は、新しいサーバーCookieを使用してルックアップを再試行します。
+[no]besteffort
おかしなメッセージの内容でも表示を試みます。デフォルトでは、おかしな回答は表示されません。
+bufsize=B
EDNS0を使用して広告されるUDPメッセージバッファサイズをBバイトに設定します。このバッファの最大サイズと最小サイズは、それぞれ65535と0です。この範囲外の値は、適切に切り上げまたは切り捨てられます。ゼロ以外の値を指定すると、EDNSクエリが送信されます。
+[no]cdflag
クエリのCD(checking disabled)ビットを設定します[設定しません]。これは、応答のDNSSEC検証を実行しないようにサーバーに要求します。
+[no]class
レコードを出力するときにCLASSを表示します[表示しません]。
+[no]cmd
出力の最初のコメントの出力を切り替えて、digのバージョンと適用されたクエリオプションを識別します。このオプションは常にグローバルな効果があり、グローバルに設定してから、ルックアップごとにオーバーライドすることはできません。デフォルトでは、このコメントが出力されます。
+[no]comments
パケットヘッダーとOPT疑似セクションに関する情報、および応答セクションの名前を含む、出力内のいくつかのコメント行の表示を切り替えます。デフォルトでは、これらのコメントを出力します。
出力内の他のタイプのコメントはこのオプションの影響を受けませんが、他のコマンドラインスイッチを使用して制御できます。これらには、+[no]cmd, +[no]question, +[no]stats, および+[no]rrcommentsが含まれます。
+[no]cookie[=####]
オプションの値を使用して、COOKIE EDNSオプションを送信します。以前の応答からCOOKIEを再生すると、サーバーは以前のクライアントを識別できます。デフォルトは+cookieです。
+cookieは、ネームサーバーからのデフォルトクエリをより適切にエミュレートするように+traceが設定されている場合にも設定されます。
+[no]crypto
DNSSECレコードの暗号化フィールドの表示を切り替えます。これらのフィールドの内容は、ほとんどのDNSSEC検証の失敗をデバッグするために不要であり、それらを削除すると、一般的な失敗を簡単に確認できます。デフォルトでは、フィールドが表示されます。省略した場合、文字列”[omitted]”に置き換えられます。DNSKEYの場合、キーIDが置き換えとして表示されます。e.g. “[ key id = value ]”
+[no]defname
非推奨、+[no]searchの同義語として扱われます。
+[no]dnssec
クエリの追加セクションのOPTレコードにDNSSEC OKビット(DO)を設定することにより、DNSSECレコードの送信を要求します。
+domain=somename
/etc/resolv.confのdomainディレクティブで指定されているように、somenameドメインを含むように検索リストを設定し、+searchオプションが指定されているかのように検索リスト処理を有効にします。
+dscp=value
クエリの送信時に使用するDSCPコードポイントを設定します。有効なDSCPコードポイントは[0..63]の範囲にあります。デフォルトでは、コードポイントは明示的に設定されていません。
+[no]edns[=#]
クエリの対象となるEDNSバージョンを指定します。有効な値は0〜255です。EDNSバージョンを設定すると、EDNSクエリが送信されます。+noednsは、記憶されているEDNSバージョンをクリアします。EDNSはデフォルトで0に設定されています。
+[no]ednsflags[=#]
ゼロでなければならないEDNSフラグビット(Zビット)を指定された値に設定します。10進数、16進数、8進数のエンコードが受け入れられます。名前付きフラグ(e.g. DO)の設定は、黙って無視されます。デフォルトでは、Zビットは設定されていません。
+[no]ednsnegotiation
EDNSバージョンネゴシエーションを有効/無効にします。デフォルトでは、EDNSバージョンネゴシエーションが有効です。
+[no]ednsopt[=code[:value]]
EDNSオプションをcode pointコードで指定し、オプションで値のペイロードを16進文字列として指定します。コードは、EDNSオプション名(NSIDやECSなど)または任意の数値のいずれかです。+noednsoptは、送信するEDNSオプションをクリアします。
+[no]expire
EDNS有効期限オプションを送信します。
+[no]expandaaaa
AAAAレコードを出力するときは、デフォルトのRFC 5952推奨の表示形式ではなく、すべてのゼロを出力します。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]fail
SERVFAILを受け取った場合は、次のサーバーを試しません。デフォルトでは、通常のスタブリゾルバーの動作とは逆で、次のサーバーを試行しません。
+[no]header-only
QUESTION SECTIONなしでDNSヘッダーを使用してクエリを送信します。デフォルトでは、質問セクションが追加されます。これが設定されている場合、クエリタイプとクエリ名は無視されます。
+[no]identify
+shortオプションが有効になっていても、回答を提供したIPアドレスとポート番号を表示します[または表示しません]。短い形式の回答が要求された場合、デフォルトでは、回答を提供したサーバーの送信元アドレスとポート番号は表示されません。
+[no]idnin
入力時にIDNドメイン名を処理します[処理しません]。これには、コンパイル時にIDNSUPPORTが有効になっている必要があります。
デフォルトでは、標準出力がttyの場合、IDN入力を処理します。digの出力がファイル、パイプ、およびその他のtty以外のファイル記述子にリダイレクトされると、入力のIDN処理は無効になります。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]idnout
出力のpunyコードを変換します[変換しません]。これには、コンパイル時にIDNSUPPORTが有効になっている必要があります。
デフォルトでは、標準出力がttyの場合、出力でpunyコードを処理します。digの出力がファイル、パイプ、およびその他のtty以外のファイル記述子にリダイレクトされると、出力でのpunyコード処理は無効になります。
+[no]ignore
TCPで再試行する代わりに、UDP応答の切り捨てを無視します。デフォルトでは、TCP再試行が実行されます。
+[no]keepalive
EDNSキープアライブオプションを送信します[または送信しません]。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]keepopen
ルックアップごとに新しいTCPソケットを作成するのではなく、クエリ間でTCPソケットを開いたままにして再利用します。デフォルトは+nokeepopenです。
+[no]mapped
マップされたIPv4 over IPv6アドレスの使用を許可します。デフォルトは+mappedです。
+[no]multiline
SOAレコードのようなレコードを、人間が読めるコメント付きの詳細な複数行形式で出力します。デフォルトでは、各レコードを1行に出力して、dig出力のマシン解析を容易にします。
+ndots=D
名前の中に現れるドットの必要数をDに設定し、絶対指定とみなします。デフォルト値は、/etc/resolv.confのndotsステートメントで定義されたもので、ndotsステートメントがない場合は1です。ドット数が少ない名前は相対指定と解釈され、もし+searchが設定されていれば、/etc/resolv.confのsearchまたはdomainディレクティブに記載されているドメインから検索されます。
+[no]nsid
クエリを送信するときに、EDNSネームサーバーID要求を含めます。
+[no]nssearch
このオプションが設定されている場合、digは検索対象の名前を含むゾーンの権限のあるネームサーバーを見つけて、各ネームサーバーがそのゾーンに対して持っているSOAレコードを表示しようとします。応答しなかったサーバーのアドレスも出力されます。
+[no]onesoa
AXFRを実行するときに、SOAレコードを1つだけ(はじめの)出力します。デフォルトでは、SOAレコードの開始と終了の両方が出力されます。
+[no]opcode=value
指定された値をDNSメッセージのオペコードに設定します[復元します]。デフォルト値はQUERY(0)です。
+padding=value
EDNSパディングオプションを使用してクエリパケットのサイズを値バイトのブロックにパディングします。たとえば、+padding=32を指定すると、48バイトのクエリが64バイトにパディングされます。デフォルトのブロックサイズは0で、パディングを無効にします。最大値は512です。通常、値は128などの2の累乗であると予想されます。ただし、これは必須ではありません。パディングされたクエリへの応答もパディングされる場合がありますが、クエリがTCPまたはDNS COOKIEを使用している場合に限ります。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]qr
送信時のクエリメッセージの表示を切り替えます。デフォルトでは、クエリは出力されません。
+[no]question
回答が返されたときに、クエリの質問セクションの表示を切り替えます。デフォルトでは、質問セクションをコメントとして出力します。
+[no]raflag
クエリのRA(Recursion Available)ビットを設定します[設定しません]。デフォルトは+noraflagです。このビットは、サーバーがQUERYに対して無視すべきものです。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]rdflag
+[no]recurseの同義語。
+[no]recurse
クエリのRD(再帰が必要)ビットの設定を切り替えます。このビットはデフォルトで設定されています。つまり、digは通常再帰的なクエリを送信します。+nssearchオプションを使用する場合、および+traceを使用する場合は、ルートサーバーのリストを取得するための最初の再帰的なクエリを除き、再帰が自動的に無効になります。
+retry=T
サーバーへのUDPクエリを再試行する回数をデフォルトの2ではなくTに設定します。+triesとは異なり、これには最初のクエリは含まれません。
+[no]rrcomments
出力でのレコードごとのコメントの表示を切り替えます(たとえば、DNSKEYレコードに関する人間が読める形式のキー情報)。デフォルトでは、複数行モードがアクティブでない限り、レコードコメントは出力されません。
+[no]search
resolv.conf(存在する場合)のsearchlistまたはdomainディレクティブで定義された検索リストを使用します[使用しません]。デフォルトでは、検索リストは使用しません。
+ndotsによってオーバーライドされる可能性のあるresolv.conf(デフォルト 1)の’ndots’は、名前が相対として扱われるかどうか、したがって検索が最終的に実行されるかどうかを決定します。
+[no]short
簡潔な答えを提供します。デフォルトでは、回答を詳細な形式で出力します。このオプションは常にグローバルな効果があります。グローバルに設定してから、ルックアップごとにオーバーライドすることはできません。
+[no]showsearch
中間結果を表示する検索を実行します[実行しません]。
+[no]sigchase
この機能は廃止され、削除されました。代わりにdelvを使用してください。
※訳注 Ubuntu 18.04では以下のように説明されている。
DNSSEC署名チェーンを追跡します。-DDIG_SIGCHASEを使用してdigをコンパイルする必要があります。この機能は非推奨です。代わりにdelvを使用してください。
+split=W
リソースレコードの長い16進数、またはBase64形式のフィールドを、W文字の塊に分割します(Wは4の倍数に切り上げられます)。+nosplitまたは+split=0を指定すると、フィールドはまったく分割されません。デフォルトは56文字で、マルチライン・モードがアクティブな場合は44文字です。
+[no]stats
統計の出力を切り替えます: クエリが行われたとき、応答のサイズなど。デフォルトの動作では、各ルックアップ後にクエリ統計をコメントとして出力します。
+[no]subnet=addr[/prefix-length]
指定されたIPアドレスまたはネットワークプレフィックスを使用してEDNSクライアントサブネットオプションを送信します[送信しません]。
dig +subnet=0.0.0.0/0, または単に dig +subnet=0 は、空のアドレスとソースプレフィックス長が0のEDNS CLIENT-SUBNETオプションを送信し、このクエリを解決するときにクライアントのアドレス情報が使用してはならないことをリゾルバに通知します。
+[no]tcflag
クエリのTC(TrunCation)ビットを設定します[設定しません]。デフォルトは+notcflagです。このビットは、サーバーがQUERYに対して無視すべきものです。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]tcp
ネームサーバーへの問い合わせにTCPを使用します[使用しません]。デフォルトではUDPを使用します。ただし、type anyまたはixfr=Nのクエリが要求された場合のデフォルトはTCPです。AXFRのクエリは常にTCPを使用します。
+timeout=T
クエリのタイムアウトをT秒に設定します。デフォルトのタイムアウトは5秒です。Tを1未満に設定しようとすると、問い合わせタイムアウトには1秒が適用されます。
+[no]topdown
この機能はdig +sigchaseに関連していますが、これは廃止され、削除されました。代わりにdelvを使用してください。
※訳注 Ubuntu 18.04では以下のように説明されている。
DNSSECの署名チェーンを追いかける際に、トップダウンで検証を行います。digを-DDIG_SIGCHASEでコンパイルする必要があります。この機能は非推奨です。代わりにdelvを使用してください。
+[no]trace
調べている名前のルートネームサーバーからのデリゲーションパスのトレースを切り替えます。トレースはデフォルトでは無効になっています。トレースが有効な場合、digは検索されている名前を解決するために繰り返しクエリを実行します。ルートサーバからの参照をたどり、検索結果の解決に使用された各サーバからの回答を表示します。
@serverも指定されている場合は、ルート・ゾーン・ネーム・サーバに対する最初の問い合わせにのみ影響します。
また、+dnssecは+traceが設定されているときにも設定され、ネームサーバからのデフォルトのクエリをより適切にエミュレートします。
+tries=T
サーバへのUDPクエリの試行回数を、デフォルトの3ではなくTに設定します。Tがゼロ以下の場合、試行回数は自動的に1に切り上げられます。
+trusted-key=####
以前は、dig +sigchaseで使用する信頼できる鍵を指定していました。この機能は廃止され、削除されました。
代わりにdelvを使用してください。
※訳注 Ubuntu 18.04では以下のように説明されている。
+sigchaseで使用する信頼できるキーを含むファイルを指定します。各DNSKEYレコードは、それぞれの行になければなりません。指定されていない場合、digは/etc/trusted-key.keyを探し、次にカレントディレクトリのtrusted-key.keyを探します。digを-DDIG_SIGCHASEでコンパイルする必要があります。この機能は非推奨です。代わりにdelvを使用してください。
+[no]ttlid
記録の出力時にTTLを表示します[表示しません]。
+[no]ttlunits
秒、分、時間、日、週を表す”s”, “m”, “h”, “d”, “w”という人間が読みやすい時間単位でTTLを表示します[表示しない]。+ttlidを暗示します。
+[no]unexpected
予想外のソースからの回答を受け入れます[受け入れません]。デフォルトでは、digはクエリを送信したソース以外のソースからの回答を受け入れません。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]unknownformat
すべてのRDATAを未知のRRタイプ提示形式(RFC 3597)で表示する。デフォルトでは既知のタイプのRDATAをそのタイプの表示形式で出力します。
+[no]vc
ネームサーバーへの問い合わせにTCPを使用します[使用しません]。この+[no]tcpの代替構文は、後方互換性のために提供されています。後方互換性のために用意されています。”vc”は”virtual circuit”の略です。
+[no]yaml
応答(+qrを使用している場合は、送信されるクエリも)を詳細なYAML形式で表示します。
※訳注 Ubuntu 18.04のdigには実装されていない。
+[no]zflag
DNSクエリの最後の未割り当てDNSヘッダーフラグを設定します[設定しません]。このフラグはオフがデフォルトです。
複数問い合わせ
BIND 9のdigの実装では、コマンドラインでの複数のクエリの指定をサポートしています(-f バッチファイルオプションもサポートしています)。これらのクエリのそれぞれには、独自のフラグ、オプション、およびクエリ・オプションのセットを与えることができます。
この場合、各クエリ引数は、上述のコマンドライン構文で個々のクエリを表します。各クエリには、標準オプションとフラグ、検索対象の名前、オプションのクエリタイプとクラス、そのクエリに適用されるクエリオプションが含まれます。
すべてのクエリに適用される、グローバルなクエリオプションを指定することもできます。これらのグローバルクエリオプションは、コマンドラインで指定したname、class、type、options、flags、クエリオプションの最初のタプルの前になければなりません。グローバルクエリオプション(+[no]cmdオプションを除く)は、クエリ固有のクエリオプションセットで上書きすることができます。
例えば:
dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
は、コマンドラインを使用してdigに3つの検索を行う方法を示しています。www.isc.orgのANYクエリ、127.0.0.1の逆引き、そしてisc.orgのNSレコードのクエリです。グローバルクエリオプションとして+qrが適用されているので、digは各ルックアップで作成した最初のクエリを表示します。最後のクエリには、ローカルクエリオプションとして+noqrが適用されています。これは、digがisc.orgのNSレコードを検索する際に、最初のクエリを表示しないことを意味しています。
IDNサポート
digがIDN(internationalized domain name/国際化ドメイン名)をサポートしてビルドされていれば、非ASCIIドメイン名を受け入れて表示することができます。digはDNSサーバーにリクエストを送信したり、サーバーからの応答を表示する前に、ドメイン名の文字エンコーディングを適切に変換します。何らかの理由でIDNサポートをオフにしたい場合は、環境変数IDN_DISABLEを定義します。digの実行時にこの変数が設定されていると、IDNサポートは無効になります。
ファイル
/etc/resolv.conf
${HOME}/.digrc
関連項目
delv(1), host(1), named(8), dnssec-keygen(8), RFC1035.
バグ
クエリの選択肢が多すぎるのではないでしょうか。
著者
Internet Systems Consortium, Inc.
著作権
Copyright © 2000-2011, 2013-2018 Internet Systems Consortium, Inc. (“ISC”)
番外
こちらは、T.Suzuki先生に教えてもらったときに「DNSは曖昧で、だから成り立っているところもあるんだけれども、こんなこともあるんだよね」と教えていただいた事例。
$ dig txt cf1111.tcpreplay.net @8.8.8.8 $ dig txt cf1111.tcpreplay.net @1.1.1.1
8.8.8.8はGoogleが運営するパブリックDNSリゾルバで、独自開発されている。
1.1.1.1はCloudflareが運営するパブリックDNSリゾルバで、最速を謳っている。
これはきっと教材で、丹念に調べてみると勉強になる。
さいごに
いままで「知りたい」と思っていたのに行動していなかった事柄。いつもトライしてはマニュアルとかRFCとかの壁にぶつかり、面倒になって止めていた。
今回、業務で必要になったことをきっかけとして情報を探すようになり、T.Suzuki先生から直接VITOCHAを教えていただける機会を得た。参加してみたところとてもハイレベルだった…のに、私の質問でレベルを下げちゃったかなぁ。しかしながら、私にとっては至極勉強になった大切な時間になった。
T.Suzuki先生、ありがとうございました。
このことをきっかけとして、まずは正しく聞くことができる知識が必要と考えるようになり、学習に取り組んだ。どこで切り上げるか…というところの判断レベルを上げて調べた一方で、DNSSECとEDNS0を割り切っている。
どうにか抱えている業務に対する準備になったと判断して、メモとしてリリース。
とはいえ、DNSへの質問の仕方、何を答えてくれているのかをきちんと理解する為の最初の一歩でしかない。問題を調べる為には、聞き方ももっと知る必要があるだろうし、どのような設定がなされているのかを想像できる知識や経験が必要になるんだろうなー。
コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他