DNS勉強会@ゼロスタに行ってきた

恒例の行ってきたエントリです。そういえばqpstudy書き忘れてたけど、あれは勉強会じゃないからいいよね(;・∀・)

というわけで、今日は万難を排してゼロスタートコミュニケーションズで開催された「DNS勉強会」に行ってきました。つぶやきまとめはこちらをご覧ください。途中の@sugyanさんがよくわかりません。

DNSってなんじゃい!

BINDがあまりにもよく使われるせいで、「DNS=BIND」的な感じでBINDの設定のはなしとかばっかりが世の中にはびこってるけど、そもそもDNSってどういう仕組みでどういう登場人物がいるのかという話を、@zaki社長自ら解説するという豪華な勉強会。最初かなりグダグダな感じ(始まってから「ハッシュタグ今決めました」とか)で大丈夫かなと思ったけど、参加者の方から「〇〇ってなんですか?」的な質問も出てきていい感じに進んでました。実況担当だったりすこさんがまさかの投稿数制限により途中でつぶやけなくなるという大失態を除けば大成功( ゚д゚)?

人見知りの僕的には、人数の少ない勉強会だったので参加者全員の簡単な自己紹介が最初にあってもよかったかなーと思いました。

あとは自分向けのメモー

“再帰”リゾルバについて

「再帰リゾルバ」って言葉、ずっとピンとこなかったんですが、すっきりしました。要は「反復リゾルバ」を持ったキャッシュサーバに対してのみ問い合わせるのが「再帰リゾルバ」で、DNSの名物であるツリーをたどって多重問い合わせをするのは「反復リゾルバ」の方という話。なんか、「再帰」って名前から連想するのはどうしても反復リゾルバ相当の仕事なので、意味分からんわーと思ってたけど、まぁ名前の問題なのね。

CIDR PTR

あまり逆引きについて詳しくなかったんですが、CIDR PTRの話はなるほどという感じでしたので以下紹介。習ったことが大体組み合わされてて、いい感じっすね。

DNSの逆引き(IPアドレス→ドメインの解決)を行う仕組みとしては、in-addr.arpaという特殊なドメインを使います。例えば、zakiさんが例に出していたlang-8.comのIPを調べてそれを逆引きしてみましょう。まずは正引き。

$ dig lang-8.com
;; ANSWER SECTION:
lang-8.com.             159     IN      A       202.212.240.75

Aレコードですね。1つの名前にIPアドレスを結びつける最も基本的なRRになりますね。ただ、Aレコードで返すIPは別に自分の管理してるIPでなくても返せてしまうわけで、帰ってきたIPが本当にlang-8.comのものなのか確認したくなります。そこで逆引きをしてみます。

IPアドレスは左側の上位のセグメントから右にいくに従ってだんだん細かく管理が別れていきます。一方DNSの名前は左にいくほど細かく別れていきます。なので、逆引き用の名前はIPアドレスを「.」区切りで逆順にした形の名前を引くことになります。その際の上位のドメインとしてin-addr.arpaを使います。逆引きのレコードの種類はPTRになります。

$ dig 75.240.212.202.in-addr.arpa ptr
;; ANSWER SECTION:
75.240.212.202.in-addr.arpa. 3600 IN    CNAME   75.SUB72.240.212.202.in-addr.arpa.
75.SUB72.240.212.202.in-addr.arpa. 592 IN PTR   lang-8.com.

おや、なんか変な感じですね。期待としては、75.240.212.202.in-addr.arpaのPTRレコードがlang-8.comになっていて欲しかったのですが、それは何故かCNAMEになっています。CNAMEというのは別名を付けるレコードで、シンボリックリンクの様な存在です。

では、75.SUB72.240.212.202.in-addr.arpaとは何者でしょうか?

$ dig 75.SUB72.240.212.202.in-addr.arpa. soa
;; AUTHORITY SECTION:
SUB72.240.212.202.in-addr.arpa. 234 IN  SOA     ns.a.lang-8.com. hostmaster.SUB72.240.212.202.in-addr.arpa. 1302765149 16384 2048 1048576 2560

SOAレコードというゾーンを管理するレコードを聞いてみると、SUB72.240.212.202.in-addr.arpaになるようですね。この人のNSレコードを聞いてみましょう。NSレコードとは、そのドメイン自体を管理しているDNSサーバのことです。

$ dig ns SUB72.240.212.202.in-addr.arpa.
;; ANSWER SECTION:
SUB72.240.212.202.in-addr.arpa. 2461 IN NS      ns.b.lang-8.com.
SUB72.240.212.202.in-addr.arpa. 2461 IN NS      ns.a.lang-8.com.

ほぉほぉ。この謎のドメインは結局lang-8.comのドメインで管理されているようです。そのため、先程のPTRを問い合わせた際のCNAME先では正しくlang-8.comが返ってきていたということになります。

なんでこんなことに?

本来逆引きは、「75.240.212.202.in-addr.arpa」のPTRとして直接指定されているのがいいんですが、それを設定できるのは「75.」の上位のドメインに当たる「240.212.202.in-addr.arpa」を管理している人になります。lang-8.comがそこを管理しているのなら何の問題もなくPTRを設定できます。

IPアドレスがまだまだたくさんあった頃は、IPアドレスの割り当ては「.」区切りで256個とかでどーんと渡されていました。その場合、IPアドレスの「.」の区切りと管理者の範囲が一致しています。そのため、上記の様に240.212.202.in-addr.arpaのRRにPTRを書けます。

しかし、IPアドレスは少なくなり、今ではCIDR(Classless Inter-Domain Routing)という形で「.」区切りの中のさらに一部だけを渡すということが行われています。(そしてつい先日それは枯渇しました。。。)

CIDRの場合、「202.212.240.0/24」の256個のアドレスが例えば32個ずつに分けて8つの会社に割り当てられるということが起こります。すると、先ほどの逆引き用のPTRレコードを設定しようにも、いちいち240.212.202.in-addr.arpaを管理している人にそれぞれの会社が設定を依頼する必要が出てきてしまいます。これはどちらにとっても相当に面倒ですね。

そこで、lang-8.comの例で見たようなCNAMEを使ったテクニックが出てきました。8つに分けて管理しているのであれば、それぞれの逆引き用PTRレコードに対して以下の様なCNAMEを設定してしまいます。

0.240.212.202.in-addr.arpa   IN  CNAME  0.SUB01.240.212.202.in-addr.arpa.
1.240.212.202.in-addr.arpa   IN  CNAME  1.SUB01.240.212.202.in-addr.arpa.
...
31.240.212.202.in-addr.arpa  IN  CNAME  31.SUB01.240.212.202.in-addr.arpa.

32.240.212.202.in-addr.arpa  IN  CNAME  32.SUB02.240.212.202.in-addr.arpa.
...
63.240.212.202.in-addr.arpa  IN  CNAME  63.SUB02.240.212.202.in-addr.arpa.

...

つまり、202.212.240.0〜202.212.240.31の32個はSUB01.240.212.202.in-addr.arpaに、次の32個はSUB02.240.212.202.in-addr.arpaに、という感じ。そうしておいて、SUB0X.240.212.202.in-addr.arpa自体のNSレコードをそれぞれの会社のDNSサーバに向けてあげれば、あとはそれぞれのDNSサーバにおいて、「75.SUB72.240.212.202.in-addr.arpa」などについてPTRレコードを自由に設定することができます。

いやー興味深い。

グルーレコード

NSレコードはDNSサーバを指定するんですが、もしそれがこれから解決しようとしているドメイン配下だと、どう頑張っても名前が解決できなくなります。具体的にみてみましょう。

$ dig ns google.com
;; ANSWER SECTION:
google.com.             152713  IN      NS      ns2.google.com.
google.com.             152713  IN      NS      ns3.google.com.
google.com.             152713  IN      NS      ns4.google.com.
google.com.             152713  IN      NS      ns1.google.com.

google.comのNSはこのようにgoogle.comのサブドメインになってしまっています。これについてcomのNSサーバに問い合せてみましょう。f.gtld-servers.netというのはcomのNSのひとつです。

$ dig a google.com @f.gtld-servers.net.
;; AUTHORITY SECTION:
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.         172800  IN      A       216.239.34.10
ns1.google.com.         172800  IN      A       216.239.32.10
ns3.google.com.         172800  IN      A       216.239.36.10
ns4.google.com.         172800  IN      A       216.239.38.10

ほぅほぅ。comを管理している(google.comはnsX.google.comに委任している)はずのf.gtld-servers.netに聞いたのに、なぜか、nsX.google.comのAレコードが追加で返ってきています。これがグルーレコードというものです。

NS自体が解決したい先の管理下にあると、必ずループになってしまい名前解決ができなくなるのを防ぐため、あえて1つ上の管理ドメインからAレコードを返す形にしてあげています。こうして返ってきたIPアドレスに対して名前を聞いてみると正しく取れることが分かります。

$ dig a google.com @216.239.34.10
;; ANSWER SECTION:
google.com.             300     IN      A       72.14.203.104
google.com.             300     IN      A       72.14.203.103
google.com.             300     IN      A       72.14.203.105
google.com.             300     IN      A       72.14.203.106
google.com.             300     IN      A       72.14.203.147
google.com.             300     IN      A       72.14.203.99

無事取得できていますね!

おわりに

というわけで、復習も兼ねてdigを色々叩きながら書きました(←dig初心者)。初心者なんで間違ってたら指摘してくだしあ>< こういう話題はどうやってゲットしたらいいのか悩んでいた所だったので、非常に楽しかったです。

DNSは仕組みはとてもシンプルなのですが、インターネットの根幹を支える仕組みですし、今後も必要な知識となってくると思いますので引き続き勉強していきたいですね。IPv6対応については否が応でも必須となってきますので勉強する量が増えそう。。。

最後に、、、、

懇親会あった方がいいんじゃないかなぁ
|д゚)チラッ

講師の@zakiさん、つぶやき担当の@RiscoMorinoさんはじめ、ゼロスタの方々++!! 次回zsstudyにも期待ですね!

りすこ 11-04-22 (金) 1:52

|д゚)チラッ < ブログありがとう!!つぎ懇親会しよっかな!

riywo 11-04-22 (金) 23:05

>りすこさん

期待!!せっかく集まるのに勉強だけじゃもったいない!