digコマンドとレコード
08.10.10 / DNSって何? / Author: aico
とうとう戻ってきましたDNS…わー!がんばりましょう!
今日はdigコマンドについて勉強しました。
…の前に!忘れちゃったあなたへ!DNSおさらいはこちら*
人間にわかりやすいドメイン名(FQDN)とコンピュータにわかりやすいIPアドレスを対応付けしてくれるのがDNSで、この仕事を名前解決と呼ぶんでしたよね。
この名前解決を具体的にしてくれるDNSクライアントがdigコマンドです!
digとは、domarn information groperの略です。
ターミナルで、
$ dig [ドメイン名(FQDN)][レコードタイプ]と入れるとそのドメインに関するデータが調べられます。
そのデータの形がレコードです。
DNSレコードにはIPを指定するAレコードやメールサーバを指定するMXレコード…などなどたくさん種類のレコードタイプがあります。
試しに$ dig co-akuma.directorz.jp [レコードタイプ]と小悪魔ブログのドメイン名を入れてみると、
;; ANSWER SECTION:
co-akuma.directorz.jp. 3600 IN A 125.6.176.32
と出ます!
Aレコードは、ドメイン名(FQDN)からIPアドレスを調べる(正引き)レコードです。
ここでは、「coakuma.directorz.jpというドメイン名(FQDN)に対応するIPアドレスは125.6.176.32です。」と書いてあります。
レコードとして得られた情報はしばらくの間保存=キャッシュされます。
キャッシュによって情報が保存されることで同じページを見るのに何度も問い合わせする必要がなくなります。
このレコードのキャッシュの有効期限を秒数で書いているのがTTLです。ここでは3600(秒)となっているので1時間キャッシュされます。
$ dig co-akuma.directorz.jpというようにレコードタイプを省略するとAレコードが検索されます。
$ dig
のようにターミナルでdigとだけ打つと
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518400 IN NS c.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
のように言われます。
NSレコードが登場しましたね。これは、ゾーン権限を持つDNSサーバを指定するレコードです。
ここでは、「ルートのゾーンを管理しているDNSサーバはこの13個です。」と書いてあります。
NSレコードはフルサービスリゾルバによる反復問い合わせの時に下位のゾーンの権限を持つDNSサーバを指定する時使われます。
DNSサーバは自分の直下と自分しか知らないので、名前解決は1つずつ下に下に反復して情報を聞いていきます。
うさこちゃんのひいおじいちゃんはうさこちゃんのじいちゃんにうさぱぱ(とその下)のことを権限委譲しているため、うさこちゃんのことを知りません。
そのため、「うさこちゃんは知らないけどうさじい(のゾーンのDNSサーバ)が知ってるかも」と言ってうさじいの情報をくれます。このとき渡される情報がうさじいのNSレコードです。
digコマンドでこの動作と同じことをすると
$ dig @m.root-servers.net co-akuma.directorz.jp
こんな感じです。
同じようにうさじいも権限委譲しているのでうさこちゃんのことを知りません。そのためうさぱぱのNSレコードをくれます。
コマンドでいうと
$ dig @a.dns.jp co-akuma.directorz.jp
うさぱぱはうさこちゃんのことを知っているのでIP(Aレコード)を渡します。
コマンドでいうと
$ dig @dns1.directorz.jp co-akuma.directorz.jp
このようにフルサービスリゾルバはどんな風に動いてるのかな?ってことをdigによって見てみたわけですが
$ dig co-akuma.directorz.jp としてもco-akuma.directorz.jpのIPは手に入れられましたよね?
なぜかというと問い合わせ先サーバが空欄になっていると/etc/resolv.confに書いてあるDNSサーバが反復問い合わせをしてくれるからです。これは自分のコンピュータが利用するDNSサーバの情報のファイルです。
つぎはMXレコードです。
$ dig directorz.jp mxと入力するとこのようにでます。
;; ANSWER SECTION:
directorz.jp. 1736 IN MX 3 mail.directorz.jp.
MXレコードはメールアドレスに利用するドメイン名(FQDN)を指定するレコードです。
ここでは「@の後ろがdirectorz.jp となっているメールアドレスに送られたメールはmail.directorz.jpのメールサーバが受け取ります。」と書いてあります。
メールアドレスはユーザ名+ドメイン名(FQDN)で出来ています。
MXレコードはドメイン名とメールサーバのFQDNとを結びつけます。
そのため、もしうさおくんがうさこちゃんにお手紙を出すと、
MXレコードでうさこちゃんのドメイン名と結びつけられたFQDNのメールサーバに送られるのです。
MXレコードにはメールサーバの優先順位をつけるプリファレンス値というものがあります。
プレファレンス値はドメイン名に結びつけられたメールサーバが2つ以上の時どちらを優先的に使うかを表しています。
プレファレンス値がより低い方から順番に優先して使われます。
4つ目はSOAレコードです!
SOAレコードはゾーン権限を持っているDNSサーバとその詳細が書かれているレコードです。
$ dig directorz.jp soaと入力すると…
;; ANSWER SECTION:
directorz.jp. 2560 IN SOA dns1.directorz.jp. hostmaster.directorz.jp.
1286337318 16384 2048 1048576 2560
数字がたくさん並んでますが、これはゾーン管理のための情報です。
DNSでは、複数のサーバでゾーン管理することによってDNSサーバの負担を軽減したり、障害が発生してもすぐ対策できるようになっています。
ネームサーバには管理者が設定するマスターサーバと、そのデータをコピーをもつスレーブサーバが存在します。
この、スレーブサーバによるマスターサーバのゾーン情報をコピーする作業をゾーン転送といいます。
スレーブサーバはrefreshの時間に沿ってマスターサーバのserialを確認して、自分の持っているものより大きいシリアルナンバーになっていたら、ゾーン転送を行います。
retryはゾーンファイル更新の確認が上手く出来なかった時、再確認を行うまでの時間を指定しています。
再確認が失敗し、expiryに指定された時間が経過してしまった時、スレーブサーバはそのゾーンのサーバとして動くことをやめます。
これは、トラブルが起きた時、誤った情報を流し続けないようにするため指定されています。
minimumはネガティブキャッシュのTTLです。
例えば、存在しないoo-akuma.directorz.jpというFQDNのレコードを尋ねても、ありませんってことがかえってくるだけです。
その、ありませんという返事をキャッシュするのがネガティブキャッシュです。
最後はTXTレコードです。
文章(テキスト)をドメイン名に関連づけられるのがTXTレコードです。
$ dig directorz.jp txtと入力すると…
;; ANSWER SECTION:
directorz.jp. 3600 IN TXT “v=spf1 ip4:125.6.176.0/24 ip4:211.125.109.73 ip4:219.94.152.26 ~all”
ここでは、「directorz.jpのテキストレコードはIPアドレスはIPv4で記述されていて、125.6.176.0/24(他2つ)以外のIPアドレスからdirectorz.jpとして送られてきたメールはなりすましの可能性があるためできるだけ受信しないでください。」と書いてあります。
TXTレコードはDNSの拡張用に用意されたレコードで、最近では主に、メールサーバのIPアドレスを確認して送信メールのなりすましを防ぐために使われます。
Comments: 5
はじめまして。いつも楽しく読ませて頂いています。
内容とあんまり関係ないんですが、キャッシュの綴りはcasheでなくてcacheだと思いますよ。
文中じゃなくて絵の中なので直すの大変そうですが…。
tmurataさん
はじめまして!コメントありがとうございます。
cache直しました〜><
指摘ありがとうございました。
10/13から10/14にかけてyahooでDNS障害があったみたいなので、いい勉強のネタになりそうですね~w
もにょもにょさん
コメントありがとうございます。
DNSは脆弱だからね〜と社長が言ってました!yahoo大変ですね><
とてもお勉強になります。大学2年生の工学部です^^
それにかわいいので最後まで読んじゃいますw