15年1月30日金曜日

詳解TCP/IP
~DNS編~
15年1月30日金曜日
DNSとは
ドメインネームシステム(DNS:Domain Name System)は
TCP/IPアプリケーションがホスト名とIPアドレス間で
マッピングするときや、電子メールのルーティング情報を提供する時に
用いられる分散データベースである
なぜ分散という言葉が使われているか:
単一のサイトでインターネット全体の情報を知っている所は無いため
IPアドレス→ホストの変換(逆引き)
ホスト→IPアドレスの変換(正引き)
15年1月30日金曜日
DNSとは
15年1月30日金曜日
DNSとは
Application
Resolver
gethostbyname(3) : Host!IP
gethostbyaddr(3) : IP!Host
DNS1
......
DNSn
- リゾルバーはTCP/IPプロトコルスタックのようなカーネルの一部ではない
- アプリケーションがコネクションを確立するには名前解決が事前に必要
- カーネルはDNSについては何も関知しない
15年1月30日金曜日
DNSの基本
大文字でもOK
15年1月30日金曜日
DNSの基本
- DNSの名前空間は階層構造、ドメイン名はラベルのリストで構成される
- すべてのノードは最大63キャラクタのラベルを持っている (ルートは特殊)
- ツリーの異なる場所で同じラベルが使われても問題ない
- 最後がピリオドで終わるものはFQDNと呼ばれている (ex. sfc.keio.ac.jp.)
15年1月30日金曜日
DNSの基本
net
us
jp
cn
org
- 権限委譲はDNSの重要な要素
- 最上位ドメインの一部を一つのNICが管理してそれ以外はゾーンで権限を委任
- 大規模なシステムでは権限を委任する事によって負荷を分散させている
15年1月30日金曜日
DNSの基本
Primary
Server
ゾーン転送
Secondary
Server
ディスクからゾーン情報をロード
- 1台のネームサーバは複数のゾーンを管理できる
- ゾーン責任者はそのゾーンに1次,2次ネームサーバを提供する必要がある
(それぞれは独立していて冗長性を確保したサーバでなくてはならない)
- 1次ネームサーバはディスクからゾーン情報を読み取るのに対して2次ネームサーバは1次ネームサーバから情報を受け取る、これをゾーン転送と言う
- ゾーン転送は定期的に実行される
15年1月30日金曜日
DNSの基本
- 要求された情報を持っていない場合はルートサーバに問い合わせる
- 各サーバはルートサーバのIPアドレスを知っている
- ルートサーバはA~Mまでの13台が存在 (最近ほとんどがエニーキャスト化された)
15年1月30日金曜日
DNSの基本
実際にwww.sfc.keio.ac.jpがどのように名前解決されるのかを見てみる
15年1月30日金曜日
DNSの基本
実際にwww.sfc.keio.ac.jpがどのように名前解決されるのかを見てみる
a.root-servers.net
d.dns.jp
ns0.sfc.keio.ac.jp.
Resolver
j.root-servers.net
e.dns.jp
svp00.sfc.keio.ac.jp.
b.root-servers.net
f.dns.jp
ns.mita.keio.ac.jp.
g.root-servers.net
a.dns.jp
kogwy.cc.keio.ac.jp.
15年1月30日金曜日
DNSの基本
実際にwww.sfc.keio.ac.jpがどのように名前解決されるのかを見てみる
a.root-servers.net
d.dns.jp
ns0.sfc.keio.ac.jp.
Resolver
j.root-servers.net
e.dns.jp
svp00.sfc.keio.ac.jp.
jpはdns.jpに聞いて
b.root-servers.net
IN A 133.27.4.220
f.dns.jp
ns.mita.keio.ac.jp.
keioはkeio.ac.jpに聞いて
g.root-servers.net
15年1月30日金曜日
a.dns.jp
kogwy.cc.keio.ac.jp.
DNSクエリ
15年1月30日金曜日
DNSクエリ
tcpdumpでDNS要求をキャプチャした例 (www.sfc.keio.ac.jp → 133.27.4.220)
DNS照会要求
DNS照会応答
15年1月30日金曜日
DNSクエリ
tcpdumpでDNS要求をキャプチャした例 (www.sfc.keio.ac.jp → 133.27.4.220)
ヘッダ
“w
w w”
“s
bbff 0100 0001 0000 0000 0000 0377 7777 0373 6663 046b 6569 6f02 6163 026a 7000 0001 0001 f c”
IP
IP
UDP
DNS
“k
e i
o
DNS
a c
j
p”
タイプクラス
DNS照会要求
DNS照会応答
15年1月30日金曜日
DNS照会要求
(0xbbff)
(0x0001)
(0x0000)
(0x0100)
(0x0000)
(0x0000)
(0 0000 0 0 1 0 000 0000)
QR: 照会(0)/応答(1)のどちらか
オペコード: 0=通常照会, 1=逆照会, 2=サーバステータス要求
AA: 権威ある回答かどうか
TC: UDPでは512byteを超えた場合に断片化して送信された事を示す
RD: 再帰要求
recode: 0=異常なし, 3=ネームエラー
15年1月30日金曜日
DNS照会要求
(0xbbff)
(0x0001)
(0x0000)
(0x0100)
(0x0000)
(0x0000)
照会タイプ:
A=1, NS=1, CNAME=2, PTR=12, HINFO=13, MX=15
AXFR=252, *(ANY)=255
照会クラス: 1=Internet
15年1月30日金曜日
DNS照会応答
(0xbbff)
(0x0001)
(0x0000)
(0x8160)
(0x0001)
(0x0000)
(1 0000 0 0 1 1 000 0000)
QR: 照会(0)/応答(1)のどちらか
オペコード: 0=通常照会, 1=逆照会, 2=サーバステータス要求
AA: 権威ある回答かどうか
TC: UDPでは512byteを超えた場合に断片化して送信された事を示す
RD: 再帰要求
recode: 0=異常なし, 3=ネームエラー
15年1月30日金曜日
DNS照会応答
3つはすべて同じリソースレコード形式
15年1月30日金曜日
DNS照会応答
(0xbbff)
(0x0001)
(0x0000)
(0x8160)
(0x0001)
(0x0000)
(3www3sfc4keio2ac2jp0)
(0x0001)
(0x0001)
(0xc00c0001)
(0x0004)
(0x851b04dc = 133.27.4.220)
15年1月30日金曜日
リソースレコード
- Aレコード: IPアドレス(IPv4)を定義。32bitバイナリ値として格納
- PTRレコード: ポインタ照会に用いられる。in-addr.arpa.のドメイン名として記述
- CNAMEレコード: エイリアスを定義する時に利用
- HINFOレコード: サーバの情報を記述。必須ではないためセキュリティ上の理由
から書かない場合が多い
- NSレコード: そのドメインの権威あるネームサーバを記述
15年1月30日金曜日
リソースレコード
- MXレコード: メールの送信時に利用される
(例だと[email protected].宛はmail-gw1/2.sfc.keio.ac.jp.に送信され、優先度
(10,20)の高いものからそちらに配信されるので、mail-gw1.sfc.keio.ac.jp.が優先
度が高いサーバである事が分かる
15年1月30日金曜日
逆引き
- 正引き(ホスト→IP)と逆引き(IP→ホスト)は同じ仕組み(正引き)で実現されている
- in-addr.arpaという存在
1. www.sfc.keio.ac.jp.のIPほしい
Application
DNS Resolver
3. 133.27.4.220だよ
2. www.sfc.keio.ac.jp.の名前解決をして
ほしいという内容のDNSパケットを作成
1. 133.27.4.220のIPほしい
Application
3.www.sfc.keio.ac.jp.だよ
DNS Resolver
2. 220.4.27.133.in-addr.arpa.の名前解決をし
ほしいという内容のDNSパケットを作成
15年1月30日金曜日
逆引き
15年1月30日金曜日
逆引き
- 正引きと同じように逆引きを利用できるが、中は正引きのAレコードの要求では
なく、PTRレコードを要求している
(つまり、ホスト→IPという正引きのデータを利用して変換している訳ではない)
→逆引きできないIPアドレスも存在する
→逆引きしたホストは自称なのでそのホストを正引きして検証する必要がある
- IPアドレスを逆順に記述しているのは
ドメインツリーの構造が正引きに最適になっているのでそれにあわせるため
15年1月30日金曜日
逆引き
15年1月30日金曜日
キャッシング
- DNSトラフィック軽減のためにサーバはキャッシュを行う
- DNSサーバは往復時間(RTT)の評価が決まるまでゾーンの様々なサーバを利用
し、一番往復時間の短いサーバを利用する
- CNAMEとAレコードが1つの応答で双方とも返されるのも実装による最適化
- リゾルバはキャッシュをレコードのTTL値の範囲の間だけ保持する
15年1月30日金曜日
UDPとTCP
- DNSのwell-knownポートは53/tcp, 53/udp (TCP/UDPの両方をサポート)
- なぜ多くの場合UDPだけしかDNSには利用されないのか？
- 照会を行って応答パケットが512byteを超えるとTCビットがセットされ、そのパ
ケットの最初の512byteが送信されてくる
→TCビットがセットされたパケットを受け取るとリゾルバはTCPで再要求する
- ゾーン転送を行う上で2次サーバに転送されるデータは512byteを超える事が多い
→単一の照会/応答では不可能なためTCPが用いられる
15年1月30日金曜日
まとめ
- DNSの存在はインターネットにおいて極めて重要なもの
- アプリケーションはホストをIPに、逆変換するためにリゾルバにコンタクトする
- DNS要求/応答はすべて同じメッセージ形式を持つ
15年1月30日金曜日

Download Report