mochikoAsTechのdig日記

当方好きなコマンドはdigです!お友達から!!よろしくお願いします!!!

nslookupよりdig!DNS初心者向けのdig解説

このサイト(例えばhttps://infra.xyz/)って、どこのウェブサーバ使ってるんだっけ?というときは、

host infra.xyz

とか

nslookup
> set type=a
> infra.xyz

でもいけますが、nslookupは既に開発も止まっていて、ゆくゆくは無くなると言われているので、nslookupよりはdigを使おう!と思っています。

でもdig、叩くとこんな感じでべろべろっと色々出るので最初驚くんだよね。

$ dig infra.xyz

; <<>> DiG 9.10.0-P1 <<>> infra.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33266
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; ANSWER SECTION:
infra.xyz.              600     IN      A       153.121.58.159

;; AUTHORITY SECTION:
infra.xyz.              600     IN      NS      ns1.infra.xyz.
infra.xyz.              600     IN      NS      ns2.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          600     IN      A       153.121.58.159
ns2.infra.xyz.          600     IN      A       54.64.115.59

;; Query time: 272 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 28 22:24:44 JST 2015
;; MSG SIZE  rcvd: 122

どこ見たらいいの・・・という訳で一つずつ解説。

先ず、いちばん上にあるのがHEADER。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33266
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

今回は「status: NOERROR」となってるけど、これは普通に聞いて、普通に返ってきたのでNOERROR(正常)。 他には、NXDOMAIN(リクエストされた名前が存在しない)、REFUSED(リクエストが拒否された)、FORMERR(DNSメッセージのフォーマットが不正)、SERVFAIL(DNSサーバ側の状態が異常)などがある。

「flags: qr rd ra;」は、qr(問い合わせたクエリに対する回答であること)、rd(再帰的問い合わせに対する回答であること)、ra(キャッシュサーバが再帰問い合わせを許可していること)を表している。

なので、どこかのサーバから

dig infra.xyz @ns1.infra.xyz

DNSコンテンツサーバを指定して叩くと、「flags: qr aa rd;」とrdの代わりにaa(権威を持つ応答であること)になる。

あとは、ns1.infra.xyzは外からの再帰問い合わせは許可していない(=オープンリゾルバではない)ので、

dig yahoo.com @ns1.infra.xyz

のように叩くと、「status: REFUSED」で「flags: qr rd;」になる。

HEADERの下が、QUESTION SECTIONとANSWER SECTION。

;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; ANSWER SECTION:
infra.xyz.              600     IN      A       153.121.58.159

名前の通り、問い合わせとそれに対する回答。(慣れないとQUESTION SECTIONだけ見ちゃって、あれ値が返ってこない!ってなる)

ちなみに「infnya.xyz」みたいに存在しないドメインを問い合わせて「status: NXDOMAIN」になったときは、ANSWERセクションそのものがなくて、リクエストしたドメイン(infnya.xyz)の親ドメイン(xyz)のSOAレコードが、その下のAUTHORITYセクションで返ってくる。

$ dig infnya.xyz

; <<>> DiG 9.10.0-P1 <<>> infnya.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8329
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infnya.xyz.                    IN      A

;; AUTHORITY SECTION:
xyz.                    3600    IN      SOA     ns0.centralnic.net. hostmaster.centralnic.net. 3000169304 900 1800 6048000 3600

;; Query time: 590 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 28 22:33:48 JST 2015
;; MSG SIZE  rcvd: 104

AUTHORITY SECTIONとADDITIONAL SECTION。

;; AUTHORITY SECTION:
infra.xyz.              600     IN      NS      ns1.infra.xyz.
infra.xyz.              600     IN      NS      ns2.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          600     IN      A       153.121.58.159
ns2.infra.xyz.          600     IN      A       54.64.115.59

リクエストしたドメイン(infra.xyz)のネームサーバ(ns1.infra.xyz, ns2.infra.xyz)と、そのIPアドレス(153.121.58.159, 54.64.115.59)が表示される。(間違えやすいけど、ここで表示されるのは親のDNSコンテンツサーバに登録されているグルーレコードではなく、実際のns1.infra.xyzにあるinfra.xyz.zoneに書いてあるNSレコードとAレコード)

ちなみにDNSキャッシュサーバのnamed.confのoptionsセクションで、

minimal-responses yes;

にすると、AUTORITY SECTIONとADDITIONAL SECTIONセクションは省略される。(DNSコンテンツサーバとして返す情報に変化はない)

最後に一番下にある色々。

Query time(クエリの応答時間)と、SERVER(応答したDNSサーバのIPアドレスとポート番号)、MSG SIZE(メッセージサイズ)。

;; Query time: 590 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 28 22:33:48 JST 2015
;; MSG SIZE  rcvd: 104

今回はns1.infra.xyzの中でdigを叩いたので、SERVERは自分自身(127.0.0.1)になってます。

という感じなので、何かDNSがうまく引けない・・・というときは、

  • STATUSはNXDOMAINか?REFUSEDか?
  • flagsにrdがあるか?ないか?
  • SERVERのIPはGIPか?LIPか?

辺りを確認して、DNSキャッシュサーバ側の問題なのか、DNSコンテンツサーバ側の問題なのか、を切り分けるようにしています。 +traceオプションつけると、Rootから引いてくれてわーい、とかもありますが、その辺の便利オプションは言い出すときりがないのでまた別途。

最後になりましたが、digはdomain information groperの略です。

WS000450

参考資料:

AWSのEC2で、CentOS7のホスト名を変更する方法

ホスト名の恒久的な変更ね、/etc/hostsでしょー!と思ったらCentOS7からファイルが/etc/hostnameに変わっていた。(名前まんまだ) しかも直接書き換えるのは推奨されない様子で、専用のコマンドが用意されてた。

hostnamectl set-hostname 変更後のホスト名

を叩くと、/etc/hostnameが変更される。hostnamectlで結果も確認できる。でもrebootすると元に戻る。

なんだこれ・・・と思ったらAWS(EC2)の独自設定があった。

vi /etc/cloud/cloud.cfg

で# - update_hostnameしとけばOK。

グルーレコードの確認方法

いったん、+traceで親のDNSコンテンツサーバを調べて、

$ dig infra.xyz +trace

; <<>> DiG 9.10.0-P1 <<>> infra.xyz +trace
;; global options: +cmd
.                       346259  IN      NS      h.root-servers.net.
.                       346259  IN      NS      j.root-servers.net.
.                       346259  IN      NS      k.root-servers.net.
.                       346259  IN      NS      g.root-servers.net.
.                       346259  IN      NS      l.root-servers.net.
.                       346259  IN      NS      i.root-servers.net.
.                       346259  IN      NS      f.root-servers.net.
.                       346259  IN      NS      c.root-servers.net.
.                       346259  IN      NS      b.root-servers.net.
.                       346259  IN      NS      m.root-servers.net.
.                       346259  IN      NS      d.root-servers.net.
.                       346259  IN      NS      a.root-servers.net.
.                       346259  IN      NS      e.root-servers.net.
.                       347445  IN      RRSIG   NS 8 0 518400 20150224050000 20150214040000 16665 . 49XDs9Icoki4ReHy1mUexld6E7w8xCb7NTXMlie4bckAQ2p61KjzkhbJ 89DT98Xpc2IcfJy1TWgee2CTthYXXbLuuhEJdZEUrlJW2ku2IjSaEH3L JlriAwtHgrziIKgWseXAxUVJc7/w+QoYd9XV7oIOHwL3Q8MH65ako+z2 nm8=
;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 14 ms

xyz.                    172800  IN      NS      z.nic.xyz.
xyz.                    172800  IN      NS      y.nic.xyz.
xyz.                    172800  IN      NS      x.nic.xyz.
xyz.                    172800  IN      NS      generationxyz.nic.xyz.
xyz.                    86400   IN      DS      3599 8 1 3FA3B264F45DB5F38BEDEAF1A88B76AA318C2C7F
xyz.                    86400   IN      DS      3599 8 2 B9733869BC84C86BB59D102BA5DA6B27B2088552332A39DCD54BC4E8 D66B0499
xyz.                    86400   IN      RRSIG   DS 8 1 86400 20150226050000 20150216040000 16665 . 2wVBaGY2zO+b1jX12HPs7Ly0za90q+AtGM5tm3fRyOrDpCQt1XD0iJnc ij2jWuXWWXL8005Qqvi5C/gRiGJswfChKuX4J4/OKGGPzSVjxGynuEQu m3hTUtFWNESuGRAqS1zlsypFRP9O8mpaTamHRxamcQuvDSrbZBLpTbb3 sOU=
;; Received 537 bytes from 192.33.4.12#53(c.root-servers.net) in 122 ms

infra.xyz.              3600    IN      NS      ns1.infra.xyz.
infra.xyz.              3600    IN      NS      ns2.infra.xyz.
1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN NSEC3 1 1 1 - 1KKABMBG1LO63FOI21UHUBCQJDM5D2RM NS SOA RRSIG DNSKEY NSEC3PARAM
1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20150311130404 20150209214037 38328 xyz. teRlK0XJ4/Z4SmzTdI3idnwN4Zf4rLHYBap/w0KV34CB6ICtkWsBM1bk hWS4jSQ6XrjFO/OrOEKvgl/DcoyYiEsijJkcqo364JYAVUCzK1cdHlJQ efbZjruxLPEoe+34jb6gZvuY15huradsTnEnyDKQraMuOnLCUpqqiKun L9E=
jap3nebfhkg51v8uie6lh8n8fm536euf.xyz. 3600 IN NSEC3 1 1 1 - JTBA28MNE9VHFM3561JQOEB66MS83DLK NS DS RRSIG
jap3nebfhkg51v8uie6lh8n8fm536euf.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20150315190829 20150213161936 38328 xyz. ctm4qzSZRJt9gww/VHZ7PhDS8bEkpaRdkSi2FqyIf+hBA83Z7nWvQGUN Ubxd/kgR37gd3NDXoFXiJ3jhYBqJn6Ejfv9kPCv08kjEJ2lQ9W6wfSnA z8Fw67+SvQlwOIntcuDGvW7eL7He5B0C2VmQXVhLhI8dBzpbYR8tMove VCc=
;; Received 591 bytes from 185.24.64.42#53(y.nic.xyz) in 137 ms

infra.xyz.              600     IN      A       153.121.58.159
infra.xyz.              600     IN      NS      ns2.infra.xyz.
infra.xyz.              600     IN      NS      ns1.infra.xyz.
;; Received 122 bytes from 153.121.58.159#53(ns1.infra.xyz) in 0 ms

親(z.nic.xyz)に向かって問い合わせると、AUTHORITY SECTIONとADDITIONAL SECTIONにグルーレコードの情報が表示される。

$  dig infra.xyz @z.nic.xyz

; <<>> DiG 9.10.0-P1 <<>> infra.xyz @z.nic.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37776
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; AUTHORITY SECTION:
infra.xyz.              3600    IN      NS      ns1.infra.xyz.
infra.xyz.              3600    IN      NS      ns2.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          3600    IN      A       153.121.58.159
ns2.infra.xyz.          3600    IN      A       153.121.58.159

;; Query time: 55 msec
;; SERVER: 2a04:2b00:13ee::42#53(2a04:2b00:13ee::42)
;; WHEN: Mon Feb 16 23:22:27 JST 2015
;; MSG SIZE  rcvd: 106

ちなみに、何も指定せずに普通に問い合わせた時に出るAUTHORITY SECTIONとADDITIONAL SECTIONは、グルーレコードの値ではなく、実際のDNSコンテンツサーバ(今回の例で言えばns1.infra.xyzとns2.infra.xyz)で設定されているNSレコードとAレコードの値なので注意。

グルーレコードのNSと、DNSコンテンツサーバのNSレコードはどっちが優先されるか?

グルーレコードに

infra.xyz. 3600 IN NS ns1.infra.xyz.
infra.xyz. 3600 IN NS ns2.infra.xyz.

ns1.infra.xyz. 3600 IN A 153.121.58.159
ns2.infra.xyz. 3600 IN A 153.121.58.159

と登録して、でも実際のDNSコンテンツサーバ(153.121.58.159と54.64.115.59)に置いてあるゾーンファイルには、

infra.xyz. 600 IN NS ns2.infra.xyz.
infra.xyz. 600 IN NS ns1.infra.xyz.

ns1.infra.xyz. 600 IN A 54.64.115.59
ns2.infra.xyz. 600 IN A 54.64.115.59

と書いてある状態で、

dig infra.xyz @ns1.infra.xyz

したら、153.121.58.159と54.64.115.59のどっちに聞きにいくでしょう?

私、153.121.58.159だと思ってたんだけど、54.64.115.59だった。

$ dig infra.xyz @ns2.infra.xyz

; <<>> DiG 9.10.0-P1 <<>> infra.xyz @ns2.infra.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16672
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; ANSWER SECTION:
infra.xyz.              600     IN      A       153.121.58.159

;; AUTHORITY SECTION:
infra.xyz.              600     IN      NS      ns2.infra.xyz.
infra.xyz.              600     IN      NS      ns1.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          600     IN      A       54.64.115.59
ns2.infra.xyz.          600     IN      A       54.64.115.59

;; Query time: 5 msec
;; SERVER: 54.64.115.59#53(54.64.115.59)
;; WHEN: Mon Feb 16 23:10:30 JST 2015
;; MSG SIZE  rcvd: 122

グルーレコードに書いてあるDNSコンテンツサーバに行って、そこでもう1回NS引いてからA引くんだね。勉強になった。

digの+shortとか+norecursionとかは、後半何文字か省略しても通る

digの+shortは+shorでも通る(さすがに+shoはダメだった)し、+norecurseは+norでも通る。 なんか「あ、いまtypoした?」って時に普通に応答返ってきて、ん?と思ってたんだけど、まさか後半何文字か省略しても通る仕様だったとは。

ドメインの期限がモノによって1年後の「月末まで」だったり、しっかり365日後だったりするのは何故?

ドメインを買った時、たとえば2月3日に買っても翌年の2月28日までになってるドメインと、きっちり365日後の2月2日までになってるドメインがあって、これなんなんだろー?と思ってたんだけど、最近謎が解けた。(推察だけど多分あってる)

jpドメインはいつ買っても、有効期限は翌年の同月月末になる模様。さすがJPRS、お値段高いだけあるー。親切設計ー。

でもその他のTLD(comとかnetとか)は、普通に1年後。

分かるけど、分かるけども、レジストリごとに仕様違うの面倒臭い・・・そういう世界なのは分かるんだけど、もうちょっと足並みを揃えてくれ・・・・Whoisの項目とかもバラバラじゃないか・・・。

お名前.comのWhois情報公開代行を使ったまま、RapidSSLのSSL証明書を発行する方法

個人で購入したドメインで、HTTPSのサイトを開きたい! 自己署名のオレオレ証明書じゃなくて、RapidSSLみたいなDVの証明書買いたい! でもWhoisを公開するのは嫌!一時的に公開して、また代行に戻すと(たぶん)お金かかるから嫌! そのドメインでメールも受信してない!という状況で色々悩んだのでメモ。

先ずCSRのDN(ディスティングイッシュネーム)って何にしたらいいの?

DNって主要なのは 国名 (C)、都道府県名 (S/ST) 、市町村名 (L)、組織名 (O)、組織単位名(OU)、コモンネーム (CN)なんだけど、RapidSSLCSRでここを真面目に入力しても、証明書になって返ってくるときは全部 「GeoTrust Inc.」とかに塗りつぶされてて、結局コモンネーム (CN)しか残らない。(だってDV証明書だから身元証明しないもん)

じゃあ全部適当でいいかと言うとそうでもなくて、組織名 (O)は、そのドメインWhoisで組織名(Organization)に登録されているものと同一じゃないとダメ。(即発行されなくて面倒、と聞いたことがある)

という訳で、お名前.comのWhois情報公開代行を使っているときのCSRは、こんな感じで。

国名 (C):JP 都道府県名 (S/ST):Tokyo 市町村名 (L):Shibuya-ku 組織名 (O):Whois Privacy Protection Service by onamae.com 組織単位名(OU):なし(何も入力しないでEnter) コモンネーム (CN):証明書が必要なFQDN

そして申し込むときに「指定ファイルアップロードによる承認」を選ぶ。

申し込み完了すると、「こういうファイル名で、中にこう書いてあるファイルをアップして」というメールが来るので、アップすれば、1分に1回のペースでアクセスが来てて、ファイルを確認できたらすぐに証明書が発行される。

よかったー、Whois情報公開代行使ってて、かつメールの受信が出来なくても、この方法なら発行できたよー。