1

2012-‐‑‒08-‐‑‒31      DNS  Summer  Days  2012

DNSのRFCの歩き⽅方
株式会社ハートビーツ 　滝澤隆史
⽇日本Unboundユーザー会

2

私は誰• ⽒氏名:  滝澤  隆史  @ttkzw• 所属:  株式会社ハートビーツ▫ サーバの構築・運⽤用や24時間365⽇日の有⼈人監視をやっている会社▫ いわゆるMSP（マネージド  サービス  プロバイダ）• DNSとの関わり▫ システム管理理者として1997年年から2006年年までネームサー
バの運⽤用
 BIND4,  BIND8,  djbdns,  BIND9▫ 現在は個⼈人サーバでネームサーバを運⽤用
 NSD,  Unbound▫ ⽇日本Unboundユーザー会

 Unbound/NSDの⽂文書の翻訳▫ DNSは趣味です(ｷﾘｯ3

このセッションの⽬目的• DNSの仕様を調べるための取っかかりになるよ
うな情報を提供すること。

4

このセッションの概要• DNSの概念念や仕様を定めている▫ RFC  1034  DOMAIN  NAMES  –  CONCEPTS  AND  FACILITIES（ドメイン名  –  概念念と機能）と▫ RFC  1035  DOMAIN  NAMES  –  IMPLEMENTATION  AND  SPECIFICATION（ドメイン名  –  実装と仕様）• と、後に発⾏行行されたRFCで変更更・修正された内容および拡張された仕様の⼀一部について説明す
る。

5

注意点
• この資料料ではRFCの⽂文書を⼀一部翻訳しています
が、おおざっぱな訳なので、後で⾃自⾝身で原⽂文を当たってください。
• 話者は英語が得意ではありません。発⾳音は酷いのでご容赦ください。
• 今回は拡張された機能についてはほとんど説明しません。特にDNSSECについては全く説明しません。DNSSECについてのRFCについては
DNSSECジャパンのサイトを訪問してください。

6

7

RFCとは
• IETF（Internet  Engineering  Task  Force）により発⾏行行されている技術⽂文書▫ インターネット標準や情報提供の⽂文書などがある• RFCは"Request  for  Comments"の略略• RFCとは何かを理理解するためにはRFCを読むの
がよい。

8

RFCの形式

著者

この番号のRFCを廃⽌止Network	
 Working	
 Group	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 R.	
 Arends	 RFCの番号

Request	 for	
 Comments:	
 4033	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 Telematica	
 Instituut	 Obsoletes:	
 2535,	
 3008,	
 3090,	
 3445,	
 3655,	
 3658,	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 R.	
 Austein	
 
	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 3755,	
 3757,	
 3845	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 ISC	
 
Updates:	
 1034,	
 1035,	
 2136,	
 2181,	
 2308,	
 3225,	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 M.	
 Larson	
 
	
 	
 	
 	
 	
 	
 	
 	
 	
 3007,	
 3597,	
 3226	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 VeriSign	 この番号のCategory:	
 Standards	
 Track	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 D.	
 Massey	 RFCを更更新
	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 Colorado	 State	 University	
 
分類
	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 S.	
 Rose	
 
	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 NIST	
 
	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 March	 2005	
 
タイトル
	
 
	
 
RFCの発⾏行行⽉月
本⽂文
	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 DNS	
 Security	
 Introduction	
 and	
 Requirements	 	 Status	 of	
 This	
 Memo	
 
	
 
	
 	
 	
 This	
 document	 specifies	
 an	
 Internet	
 standards	
 track	 protocol	
 for	
 the	
 

9

RFCの番号• 発⾏行行されたRFCの番号は変わらない。

▫ 代わりに、致命的な間違いや編集ミスについて
は"ERATTA"が別途出ることがあるので注意。
▫ 新しいRFCにより"obsoletes"されることがある。

• RFCに慣れてくるとRFCのタイトルではなくRFCの番号で会話をするようになってくる。
▫ 「RFC  1034ではこう書かれているけどRFC  2181ではこうだ」

10

RFCの分類• RFC  1796  "Not  All  RFCs  are  Standards"
すべてのRFCが標準であるわけではない▫ Infomational  （情報提供）▫ Experimental  （実験的）▫ Standard  Track  （標準化過程）

 Proposed  Standard  （標準への提唱）
 Draft  Standard  （標準への草稿）
 Internet  Standard  （インターネット標準）▫ Historic  （歴史的）11

分類:  標準化過程• Standard  Track  （標準化過程）▫ Proposed  Standard  （標準への提唱）▫ Draft  Standard  （標準への草稿） RFC  6410（2011年年10⽉月発⾏行行）により"Internet  Standard"に統合▫ Internet  Standard  （インターネット標準） 「STD  xxx」のように別途番号付けされる

12

分類:  ⾮非標準化過程、BCP• Non-‐‑‒Standards  Track  （⾮非標準化過程）▫ Experimental  （実験的） 研究や開発の成果▫ Infomational  （情報提供）

 インターネットコミュニティーのための情報▫ Historic  （歴史的） 新しい仕様に置き換えられ、役割が終わったもの• Best  Current  Practice  （現時点での最良良な⽅方法）▫ 運⽤用についての⽂文書▫ 「BCP  xxx」のように別途番号付けされる

13

要求レベルを⽰示すために⽤用いられるキーワード• RFCの⽂文書中に次のような説明がある

The  key  words  "MUST",  "MUST  NOT",  "REQUIRED",  "SHALL",  "SHALL  NOT",  "SHOULD",  "SHOULD  NOT",  "RECOMMENDED",    "MAY",  and  "OPTIONAL"  in  this  document  are  to  be  interpreted  as  described  in  RFC  2119.

• RFC  2119  /  BCP  14  "Key  words  for  use  in  RFCs  to  Indicate  Requirement  Levels"▫ RFCにおいて要求レベルを⽰示すために⽤用いられる
キーワード

14

要求レベルを⽰示すために⽤用いられるキーワード
⼤大⽂文字の時にキーワードとして意味を持つ
キーワード

邦訳

意味

MUST

しなければならない

要求事項

REQUIRED

要求される

SHALL

するもとのする

MUST  NOT

してはならない

SHALL  NOT

しないものとする

SHOULD

すべきである

RECOMMENDED

推奨される

SHOULD  NOT

すべきでないNOT  RECOMMEDED 推奨されない
MAY

してもよい

OPTIONAL

任意である

禁⽌止事項
推奨事項

（無視する場合は慎重な判断が必要）

⾮非推奨事項（容認する場合は慎重な判断が必要）

任意事項

15

RFCに関するサイト• RFC  Editor▫ http://www.rfc-‐‑‒editor.org/• IETF  TOOLS▫ http://tools.ietf.org/html/▫ RFCを追いかけるには⾮非常に便便利利• JPRS  DNS関連技術情報▫ http://jprs.jp/tech/▫ DNS関連のRFCの邦訳がある• DNSSECジャパン▫ http://dnssec.jp/▫ DNSSECに関連するRFCの邦訳や技術情報がある

16

17

DNSの基本仕様のこの2つのRFC• RFC  1034

▫ DOMAIN  NAMES  –  CONCEPTS  AND  FACILITIES▫ ドメイン名  –  概念念と機能• RFC  1035  ▫ DOMAIN  NAMES  –  IMPLEMENTATION  AND  SPECIFICATION▫ ドメイン名  –  実装と仕様

18

RFC  1034

DOMAIN  NAMES  -‐‑‒  CONCEPTS  AND  FACILITIES• タイトル▫ DOMAIN  NAMES  –  CONCEPTS  AND  FACILITIES▫ ドメイン名  –  概念念と機能• 概要▫ DNSの構成要素の役割や機能についての説明 ドメイン名空間とリソースレコード
 ネームサーバー
 リゾルバー

19

RFC  1035

DOMAIN  NAMES  -‐‑‒  IMPLEMENTATION  AND  SPECIFICATION• タイトル▫ DOMAIN  NAMES  –  IMPLEMENTATION  AND  SPECIFICATION▫ ドメイン名  –  実装と仕様• 概要▫ DNSのプロトコルの仕様
 ドメイン名空間
 リソースレコード
 メッセージ
 マスターファイル
 ネームサーバーの実装
 リゾルバーの実装
 メールエクスチェンジャ

20

DNSの構成要素
ネームサーバー

ゾーン転送（権威サーバー）

ネームサーバーロード（権威サーバー）

マスター
ファイル
ゾーン内のリソース
レコードを記述

メッセージ
ネームサーバー

ドメイン名空間（フルサービス
リゾルバー）

メッセージ

リソースレコードcomjp

example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

リゾルバー

ドメイン名
exampleexample

ns

www

co

ns.example.jp.
192.0.2.1

タイプ

21

RFC  1034とRFC  1035への道• DNSの仕組みをある程度度理理解していないとRFC  1034とRFC  1035の内容を理理解できない。
▫ いきなりRFCを読んでもたぶん理理解できない。

• 時代背景が異異なることを意識識すること。

▫ DNSが検討開始されたのはARPANETからThe  Internetへの過渡期▫ 現在は、IN以外のクラス（CS,  CH,  HS）は使わない。
 ただし、CHは本来の⽤用途とは異異なり、ネームサー
バーの情報の取得に使われている。
 $  dig  TXT  CH  version.bind.

22

RFC  1034とRFC  1035への道• 曖昧さや間違いがある。

▫ RFC  1034とRFC  1035が基本仕様であるが、▫ 後から公開されたRFCにより、▫ 曖昧な点や間違いが訂正されたり、仕様が変更更されたりしているため、▫ RFC  1034とRFC  1035の内容がすべて正しいとは思わないように。

• RFC  1034と1035をアップデートしているRFCも合
わせて読みたい。
▫ RFC  2181  "Clariﬁcations  to  the  DNS  Speciﬁcation"はDNSの仕様の明確化をしているRFCであるので、読むべき。

23

RFC  1034と1035のアップデート（拡張機能のRFCは除く）• RFC  1123

▫ Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Support• RFC  1982

▫ Serial  Number  Arithmetic• RFC  2181

▫ Clariﬁcations  to  the  DNS  Speciﬁcation• RFC  2308

▫ Negative  Caching  of  DNS  Queries  (DNS  NCACHE)• RFC  3425

▫ Obsoleting  IQUERY• RFC  4343

▫ Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation• RFC  5452

▫ Measures  for  Making  DNS  More  Resilient  against  Forged  Answers• RFC  5936

▫ DNS  Zone  Transfer  Protocol  (AXFR)• RFC  5966

▫ DNS  Transport  over  TCP  -‐‑‒  Implementation  Requirements

24

DNSの基本仕様およびアップデート
RFC  1982  /  PS
Serial  Number  Arithmetic
RFC  1034  /  STD  13
DOMAIN  NAMES  -‐‑‒  CONCEPTS  AND  FACILITIESRFC  1035  /  STD  13
DOMAIN  NAMES  -‐‑‒  IMPLEMENTATION  AND  SPECIFICATION
RFC  1123  /  STD  3
Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Supportアップデート参照

RFC  2181  /  PS
Clariﬁcations  to  the  DNS  Speciﬁcation

RFC  2308  /  PS
Negative  Caching  of  DNS  Queries  (DNS  NCACHE)

RFC  3425  /  PS
Obsoleting  IQUERYRFC  4343  /  PS
Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation

RFC  5452  /  PS
Measures  for  Making  DNS  More  Resilient  against  Forged  Answers

RFC  5936  /  PS
DNS  Zone  Transfer  Protocol  (AXFR)

RFC  5966  /  PS
DNS  Transport  over  TCP  -‐‑‒  Implementation  Requirements

25

26

RFC  1034の⽬目次• 1.  STATUS  OF  THIS  MEMO 　本⽂文書の位置づけ• 2.  INTRODUCTION 　はじめに• 3.  DOMAIN  NAME  SPACE  and  RESOURCE  RECORDS 　ドメイン名空間とリソースレコード• 4.  NAME  SERVERS 　ネームサーバー• 5.  RESOLVERS 　リゾルバー• 6.  A  SCENARIO 　シナリオ• 7.  REFERENCES  and  BIBLIOGRAPHY 　出典および参考⽂文献

27

RFC  1034の概要• DNSの構成要素の役割や機能についての説明▫ ドメイン名空間とリソースレコード▫ ネームサーバー▫ リゾルバー28

1.  STATUS  OF  THIS  MEMO
1.  本⽂文書の位置づけ• 概要▫ このRFCはDNSについての紹介を⾏行行う。

 タイトルの通り「概念念と機能」について説明▫ 詳細はRFC  1035にて⾏行行う。

29

2.  INTRODUCTION
2.  はじめに• 2.1.  The  history  of  domain  names            ドメイン名の歴史• 2.2.  DNS  design  goals            DNSの設計⽬目標• 2.3.  Assumptions  about  usage            利利⽤用についての想定• 2.4.  Elements  of  the  DNS            DNSの要素

30

2.  INTRODUCTION
2.  はじめに• 概要▫ DNSを導⼊入するに⾄至った経緯やDNSがどういうものかを紹介している。

31

3.  DOMAIN  NAME  SPACE  and  RESOURCE  RECORDS
3.  ドメイン名空間とリソースレコード• 3.1.  Name  space  speciﬁcations  and  terminology            名前空間の仕様と⽤用語• 3.2.  Administrative  guidelines  on  use            利利⽤用上の管理理ガイドライン• 3.3.  Technical  guidelines  on  use            利利⽤用上の技術ガイドライン• 3.4.  Example  name  space            名前空間の例例• 3.5.  Preferred  name  syntax            名前の構⽂文

32

3.  DOMAIN  NAME  SPACE  and  RESOURCE  RECORDS
3.  ドメイン名空間とリソースレコード• 3.6.  Resource  Records            リソースレコード• 3.7.  Queries            問い合わせ• 3.8.  Status  queries  (Experimental)            状態問い合わせ（実験機能）• 3.9.  Completion  queries  (Obsolete)            補完問い合わせ（廃⽌止機能）33

3章の位置づけ
ネームサーバー

ゾーン転送（権威サーバー）

ネームサーバーロード（権威サーバー）

マスター
ファイル
ゾーン内のリソース
レコードを記述

メッセージ
ネームサーバー

ドメイン名空間（フルサービス
リゾルバー）

メッセージ

リソースレコードcomjp

example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

リゾルバー

ドメイン名
exampleexample

ns

www

co

ns.example.jp.
192.0.2.1

タイプ

34

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• ツリー構造とノード▫ ドメイン名空間はツリー構造▫ 各ノードとリーフはリソースの集まりに対応している▫ 内部ノードとリーフノードを区別しない。両⽅方とも「ノード」と呼ぶ。

ルート
ノード

com

jp

ノード
exampleexample

ns

リーフ
ノード

www

co

35

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• ラベル▫ 各ノードは「ラベル」を持つ。
▫ ラベルの⻑⾧長さは0オクテットから
63オクテットまで▫ 兄弟ノードは同じラベルを持たない。
▫ 兄弟でないノードは同じラベルを持てる。
▫ ルートのためにnullラベル（⻑⾧長さ0）が予約されている。

ルート
ノード
””

ラベル
"com"

com

examplejp

example

ns

www

co

36

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• ドメイン名▫ ノードのドメイン名はそのノードか
らルートノードまでのパス上のラベ
ルのリスト
 例例)  "www",  "example",  "jp",  ""com

examplejp

example

ns

www

co

37

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• ドメイン名の内部表現▫ ドメイン名はラベルをつなげたもの▫ ラベルはオクテットの⻑⾧長さと⽂文字列列で表される。
 "www"の内部表現を16進数で表すと"3  77  77  77"となる。

▫ すべてのドメイン名はルートで終わり、
ルートのラベルはnull⽂文字であるため、内部表現はドメイン名の終わりに0バイ
トの⻑⾧長さを使う。
 www.example.jp.の内部表現
3  77  77  77  8  65  78  61  6d  70  6c  65  2  6a  70  0• ドメイン名の⻑⾧長さ▫ ドメイン名のオクテット数は255まで

com

examplejp

example

ns

www

co

38

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• ⼤大⽂文字⼩小⽂文字▫ ドメイン名の⽐比較の際には⼤大⽂文字⼩小⽂文字を区別しない。
▫ ドメイン名を受け取ったときには⼤大⽂文字⼩小⽂文字を維持すべき• RFC  4343  "Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation"

39

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• ドメイン名の⼊入⼒力力は表⽰示上の表現

ルート
ノード
””

▫ ラベルの⻑⾧長さを省省き、ラベルを"."で分ける。
 例例）www.example.jp.

▫ ドメイン名はルート（空の）ラベ
ルで終わるため、ドットで終わる形式になる。
 例例）www.example.jp."空のラベル（⾮非表⽰示）"com

examplejp

example

ns

www

co

40

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• 絶対ドメイン名と相対ドメイン名

www.example.jp.
絶対ドメイン名com

examplejp

examplens

www
相対ドメイン名

www

co

41

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• 相対ドメイン名とオリジンや検索索リスト▫ 相対ドメイン名はオリジン（注：マスターファイルのオリジン）や検索索リス
ト（注：リゾルバーの検索索リスト）に対して相対。
▫ オリジンや検索索リストのメンバーとしてルート"."が解釈される。⼊入⼒力力を省省略略するために最後の"."がよく省省かれる。
 例例）www.example.jp   →FQDN（Fully  Qualiﬁed  Domain  Name、完全修飾ドメイン名）？

com

examplejp

example

ns

www

co

42

3.1.  Name  space  speciﬁcations  and  terminology
3.1.  名前空間の仕様と⽤用語• FQDN（Fully  Qualiﬁed  Domain  Name、完全修飾ドメイン名）▫ トップレベルドメインまでを含んだドメイン名
 例例:  www.example.jp▫ この⽂文法を⽰示した明確な定義はない？
▫ RFC  1594  FYI  on  Questions  and  Answers  -‐‑‒  Answers  to  Commonly  asked  "New  Internet  User"  Questions 5.2    What  is  a  Fully  Qualiﬁed  Domain  Name?

▫ RFC  1983  Internet  Users'  Glossary Fully  Qualiﬁed  Domain  Name  (FQDN)

com

examplejp

example

ns

www

co

43

3.2.  Administrative  guidelines  on  use3.2.  利利⽤用上の管理理ガイドライン• 概要▫ DNSの技術仕様としては特定のツリー構造やラベルの選択規則を強要しないという⽅方針について記述されている。

44

3.3.  Technical  guidelines  on  use3.3.  利利⽤用上の技術ガイドライン• 概要▫ DNSで扱うオブジェクトの要件について述べている。
 オブジェクト名とドメイン名のマッピング
 RRタイプとオブジェクトを記述するデータ形式

45

3.4.  Example  name  space
3.4.  名前空間の例例• 当時の例例。現在とは異異なるので注意。
||+---------------------+------------------+
|
|
|
MIL
EDU
ARPA
|
|
|
|
|
|
+-----+-----+|+------+-----+-----+
|
|
|
|
|
|
|
BRL NOSC DARPA| IN-ADDR SRI-NIC
ACC|+--------+------------------+---------------+--------+
|
|
|
|
|
UCI
MIT
|
UDEL
YALE
|
ISI
|
|
+---+---+||||LCS ACHILLES +--+-----+-----+--------+
|
| |
|
|
|
XX
A C
VAXA VENERA Mockapetris

46

3.5.  Preferred  name  syntax
3.5.  好ましい名前の構⽂文• 概要▫ ラベルの構⽂文について• ラベルとホスト名▫ ラベルはARPANETホスト名の規則に従う。

 RFC  952  DOD  INTERNET  HOST  TABLE  SPECIFICATION
 RFC  1123  Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Support  によりホスト名の仕様が変更更された• ホスト名▫ 英⽂文字で始まる  →  英⽂文字あるいは数字で始まる（RFC  1123）▫ 英⽂文字あるいは数字で終わる▫ 間の⽂文字は英⽂文字、数字、ハイフンが使える• ラベル▫ ラベルは63⽂文字未満

47

3.6.  Resource  Records
3.6.  リソースレコード• 概要▫ リソースレコードについての説明を記述する。

48

3.6.  Resource  Records
3.6.  リソースレコード

ドメイン名空間• リソースレコード▫ ドメイン名はノードを識識別する。
▫ 各ノードはリソース情報の集まりを持つ。空でもよい。
▫ 特定の名前に関連づけられたリソース情報の集まりは別々のリソースレコード（RRs）から構成される。
▫ 集まりの中のRRsの順番は指定できないし、維持される必
要も無い。

com

examplejp

example

ns

co

www

リソースレコード
example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

ドメイン名

ns.example.jp.
192.0.2.1

タイプ

49

3.6.  Resource  Records
3.6.  リソースレコード• リソースレコードの⽤用語▫ owner（オーナー）

 そのRRがあるドメイン名▫ type（タイプ） このリソースレコードのリソースのタイプを識識別する符号化された16ビットの値。タイプは抽象的なリソースを参照する。
 A,  CNAME,  HINFO,  MX,  NS,  PTR,  SOA

▫ class プロトコルファミリーを識識別する符号化された16ビットの数
 IN(the  Internet  system),  CH(the  Chaos  system)

50

3.6.  Resource  Records
3.6.  リソースレコード• リソースレコードの⽤用語▫ TTL

 RRの⽣生存期間。このフィールドは秒単位の32ビット整数。リゾルバーがキャッシュするときに使う。TTLはRRが破棄されるまでにキャッシュしてよい期間を⽰示す。
 RFC  2181  Clariﬁcations  to  the  DNS  Speciﬁcation"8.  Time  to  Live  (TTL)" 符号無し整数
 最⼩小値:  0
 最⼤大値:  2147483647    (2^31  -‐‑‒  1)
 最上位ビットが1であるときにはTTLを0と扱うべき▫ RDATA タイプとクラスに依存するデータ。

51

3.6.1.  Textual  expression  of  RRs3.6.1.  RRsのテキスト表現• RRのテキスト表現の形式▫ RRは1⾏行行で⽰示される。複数⾏行行になる場合には括弧を使う。
example.com. 172800 IN NS a.iana-servers.net.
example.com.
3600 IN SOA dns1.icann.org. (hostmaster.icann.org.
2012080872 7200 3600 1209600 3600 )▫ ⾏行行の先頭はRRのオーナー。

example.com. 172800 IN NS a.iana-servers.net.

▫ 空⽩白で始まる⾏行行は、オーナーが前のRRと同じと想定される。
example.com. 172800 IN NS a.iana-servers.net.
172800 IN NS b.iana-servers.net.

52

3.6.1.  Textual  expression  of  RRs3.6.1.  RRsのテキスト表現• RRのテキスト表現の形式  –  TTL,タイプ,クラス• オーナーの次は、TTLとタイプとクラス。

▫ クラスとタイプはニーモニックを使う。
▫ TTLは整数を使う。
▫ タイプは必ず最後である。
▫ INクラスとTTLはわかりやすさのために例例からよく省省略略される。

• RRのテキスト表現の形式  –  RDATA▫ リソースデータあるいはRRのRDATAセクションは典型的表現の知識識を使って与えられる。

53

3.6.2.  Aliases  and  canonical  names
3.6.2.  別名と正式名• 概要▫ CNAMEについての説明• CNAME▫ CNAMEは別名に対するオーナー名を識識別する。
RRのRDATAセクションの対応する正式名を⽰示す。
▫ CNAME  RRがノードに存在したら、他のデータは存在すべきではない。これは、正式名とその別名に違いがでないを保証する。
▫ この規則はキャッシュされたCNAMEは権威サーバーに他のRRタイプを確認することなしに使われることも保証する。

54

3.6.2.  Aliases  and  canonical  names
3.6.2.  別名と正式名• RFC  2181  Clariﬁcations  to  the  DNS  Speciﬁcation  "10.1.  CNAME  resource  records"▫ CNAMEの意味を明確化

 CNAME  ("canonical  name")「正式名」は"alias  name"「別名」と関連づけるために使う
 CNAMEは「別名」を⽰示すのでなく、「別名」に対する「正式名」を⽰示す。
 別名  IN  CNAME  正式名

55

3.7.  Queries
3.7.  問い合わせ• 概要▫ 問い合わせについて• 問い合わせ▫ DNS問い合わせと応答は標準メッセージフォーマット
で運ばれる。
▫ メッセージフォーマットは常に存在するいくつかの固定フィールドと問い合わせパラメータとRRを運ぶ4つのセクション▫ ヘッダーにある最も重要なフィールドは異異なる問い合
わせを分けるopcodeと呼ばれる4ビットのフィールド
である。

56

3.7.  Queries
3.7.  問い合わせ• 4つのセクション▫ Question 問い合わせ名と他の問い合わせパラメータ▫ Answer 回答のRR▫ Authority

 他の権威サーバーを⽰示すRR。answerセクションの権威データのSOA  RRでもよい。

▫ Additional 他のセクションのRRを使う際に役に⽴立立つかもしれな
いRR

57

3.7.1.  Standard  queries
3.7.1.  標準の問い合わせ▫ 標準の問い合わせは ターゲットドメイン名（QNAME）、
 問い合わせタイプ（QTYPE）、
 問い合わせクラス（QCLASS）
 を⽰示し、⼀一致するRRを尋ねる。

58

3.7.2.  Inverse  queries  (Optional)
3.7.2.  逆問い合わせ  (付加機能)• RFC  3425  Obsoleting  IQUERYにより廃⽌止59

4.  NAME  SERVERS
4.  ネームサーバー• 4.1.  Introduction            はじめに• 4.2.  How  the  database  is  divided  into  zones            データベースのゾーンの分割⽅方法• 4.3.  Name  server  internals            ネームサーバーの内部

60

4章の位置づけ
ネームサーバー

ゾーン転送（権威サーバー）

ネームサーバーロード（権威サーバー）

マスター
ファイル
ゾーン内のリソース
レコードを記述

メッセージ
ネームサーバー

ドメイン名空間（フルサービス
リゾルバー）

メッセージ

リソースレコードcomjp

example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

リゾルバー

ドメイン名
exampleexample

ns

www

co

ns.example.jp.
192.0.2.1

タイプ

61

4.1.  Introduction
4.1.  はじめに
• 概要

▫ ネームサーバーとゾーンについて記述している。

• ネームサーバーとゾーン▫ ネームサーバーはドメインのデータベースのリポ
ジトリーである。
▫ データベースはゾーンと呼ばれる部分に分割され、ネームサーバー間に分散されている。
▫ ネームサーバーの基本的なタスクはゾーン内のデータへの問い合わせに回答することである。

62

4.2.  How  the  database  is  divided  into  zones
4.2.  データベースをゾーンに分割する⽅方法• 概要▫ データベースをゾーンに分割する⽅方法について説
明する。

63

4.2.  How  the  database  is  divided  into  zones
4.2.  データベースをゾーンに分割する⽅方法• 名前空間の分割は2つの隣隣接したノードの間で⾏行行われる。
▫ 左記の例例ではexampleとjpの間• 接続された名前空間の各グループ
は別々のゾーンとなる。
• ゾーンは領領域内のすべての名前の権威となる。
• RFC  2181  Clariﬁcations  to  the  DNS  Speciﬁcation  "6.  Zone  Cuts"に詳細に説明あり

comexamplejp

example

ns

www

co

64

4.2.1.  Technical  considerations
4.2.1.  技術的な考慮• ゾーンを記述するデータは4つの部分を持つ▫ ゾーン内のすべてのノードの権威デー
タ▫ ゾーンのトップノードを定義するデータ▫ 委任したサブゾーンを記述するデータ。
すなわち、ゾーンの最下部の切切断。
▫ サブゾーンのネームサーバーにアクセスをさせるデータ（グルー"glue"データと呼ばれる。）

com

examplensjpexample

sub

ns

www

co

www

65

4.2.2.  Administrative  considerations
4.2.2.  管理理上の考慮• 組織が⾃自⾝身のドメインを管理理したいときの最初の⼀一
歩は、正しい親ゾーンを識識別し、親ゾーンの所有者に管理理を委任してもらうように同意を得ることである。
• 新しいサブゾーンに適した名前が選ばれたら、新しい所有者は複数のネームサーバーを⽤用意することを⽰示すべきである。
• 最後の導⼊入の段階では、委任が効果を持つのに必要なNS  RRsとグルーRRsを親ゾーンに追加してもらう。両⽅方のゾーンの管理理者はゾーンカットの両側で同じNSとグルーRRsを持ち続けるようにする。

66

4.3.  Name  server  internals
4.3.  ネームサーバーの内部

67

4.3.1.  Queries  and  responses
4.3.1.  問い合わせと応答• ネームサーバの主要な活動は標準問い合わせに回答することである。
• 問い合わせと応答はRFC  1035のメッセージ
フォーマットで運ばれる。
• 問い合わせはQTYPE,  QCLASS,  QNAMEを含む。

68

4.3.1.  Queries  and  responses
4.3.1.  問い合わせと応答• ⾮非再帰検索索モード▫ サーバーとして最も単純なモードは⾮非再帰である。
▫ ローカル情報のみを使って回答する。
▫ 応答はエラー、回答、回答に最も近い他のサーバへの参照のいずれかを含む。
▫ すべてのネームサーバーは⾮非再帰問い合わせを実装しなければならない。

69

4.3.1.  Queries  and  responses
4.3.1.  問い合わせと応答• 再帰検索索モード▫ クライアントとして最も単純なモードは再帰検索索
モードである。
▫ このモードでは、ネームサーバーはリゾルバーの役割として動作し、エラーあるいは回答を返す。
しかし、参照は返さない。
▫ このサービスはネームサーバーでは付加機能である。ネームサーバーは再帰検索索モードを使うクライアントを制限してもよい。

70

4.3.2.  Algorithm
4.3.2.  アルゴリズム• 概要▫ ネームサーバーの問い合わせに対するアルゴリズ
ムを説明している。

71

4.3.3.  Wildcards
4.3.3.  ワイルドカード• 概要▫ ラベル"*"で始まる所有者名を持つRRsは特別な扱
いを⾏行行う。
▫ このようなRRをワイルドカードと呼ぶ。

72

4.3.4.  Negative  response  caching  (Optional)
4.3.4.  ⽐比例例応答のキャッシュ  (付加機能)• 否定応答をキャッシュすることについての説明• 誤りあり▫ The  method  is  that  a  name  server  may  add  an  SOA  RR  to  the  additional  section  of  a  response  when  that  response  is  authoritative.

• RFC  2181  Clariﬁcations  to  the  DNS  Speciﬁcation  "7.1.  Placement  of  SOA  RRs  in  authoritative  answers"により訂正▫ リソースが存在しないときにレスポンスに含めるSOA
レコードはadditionalセクションではなくauthorityセクションに置く。

73

4.3.4.  Negative  response  caching  (Optional)
4.3.4.  ⽐比例例応答のキャッシュ  (付加機能)• RFC  2308  Negative  Caching  of  DNS  Queries  (DNS  NCACHE)で詳細な説明と再定義▫ RFC  1034からの変更更点（8  -‐‑‒  Changes  from  RFC  1034）

 ネガティブキャッシュはoptionalであったが、RFC  2308ではキャッシュする場合は、ネガティブキャッシュもしなければならないよう（must）になった。
 AuthorityセクションのSOAレコードはキャッシュしなければならない（MUST）。
 キャッシュしたSOAレコードは応答に加えなければならない（MUST）。

74

4.3.5.  Zone  maintenance  and  transfers
4.3.5.  ゾーンの保守と転送• 概要▫ ゾーン転送についての説明• RFC  5936  DNS  Zone  Transfer  Protocol  (AXFR)でAXFRのすべてがアップデートされて
いる。

75

5.  RESOLVERS
5.  リゾルバー• 5.1.  Introduction            はじめに• 5.2.  Client-‐‑‒resolver  interface            クライアント-‐‑‒リゾルバー  インターフェイス• 5.3.  Resolver  internals            リゾルバーの内部

76

5章の位置づけ
ネームサーバー

ゾーン転送（権威サーバー）

ネームサーバーロード（権威サーバー）

マスター
ファイル
ゾーン内のリソース
レコードを記述

メッセージ
ネームサーバー

ドメイン名空間（フルサービス
リゾルバー）

メッセージ

リソースレコードcomjp

example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

リゾルバー

ドメイン名
exampleexample

ns

www

co

ns.example.jp.
192.0.2.1

タイプ

77

5.1.  Introduction
5.1.  はじめに
• 概要

▫ リゾルバーはユーザープログラムとドメインネー
ムサーバーへのインターフェイスのプログラムである。
▫ リゾルバーはユーザープログラムからサブルー
ティンコールあるいはシステムコールにより要求を受け付け、ローカルのホストのデータ形式と互換性のある形式で欲しい情報を返す。

78

5.2.  Client-‐‑‒resolver  interface
5.2.  クライアント-‐‑‒リゾルバーのインターフェイス• 概要▫ 典型的な機能

 ホスト名からホストアドレスへの変換
 ホストアドレスからホスト名への変換
 ⼀一般的な検索索機能

79

5.3.  Resolver  internals
5.3.  リゾルバーの内部• 概要▫ リゾルバーの実装についての説明▫ スタブリゾルバー▫ リソース▫ アルゴリズム80

6.  A  SCENARIO
6.  シナリオ• 省省略略81

7.  REFERENCES  and  BIBLIOGRAPHY
7.  出典と参考⽂文献• 省省略略82

83

RFC  1035の⽬目次• 1.  STATUS  OF  THIS  MEMO 　この⽂文書の位置づけ• 2.  INTRODUCTION 　はじめに• 3.  DOMAIN  NAME  SPACE  AND  RR  DEFINITIONS 　ドメイン名空間とリソースレコードの定義• 4.  MESSAGES 　メッセージ• 5.  MASTER  FILES 　マスターファイル• 6.  NAME  SERVER  IMPLEMENTATION 　ネームサーバーの実装• 7.  RESOLVER  IMPLEMENTATION 　リゾルバーの実装• 8.  MAIL  SUPPORT 　メールのサポート• 9.  REFERENCES  and  BIBLIOGRAPHY 　出典と参考⽂文献

84

RFC  1035の概要• DNSのプロトコルの定義▫ ドメイン名空間▫ リソースレコード▫ メッセージ▫ マスターファイル▫ ネームサーバーの実装▫ リゾルバーの実装▫ メールエクスチェンジャ

85

1.  STATUS  OF  THIS  MEMO
1.  本⽂文書の位置づけ• 概要▫ この⽂文書はドメイン名システムとそのプロトコルについての詳細を記述するものである。

86

2.  INTRODUCTION
2.  はじめに• 2.1.  Overview            概説• 2.2.  Common  conﬁguration            共通の構成• 2.3.  Conventions            取り決め

87

2.1.  Overview
2.1.  概説

882.2.  Common  conﬁgurations
2.2.  共通の構成• リゾルバーの最も単純で典型的な構成
Local Host

| Foreign|+---------++----------+| +--------+|| user queries ||queries | ||| User|-------------->||---------|->|Foreign || Program || Resolver || | Name |||<--------------||<--------|--| Server ||| user responses||responses| ||+---------++----------+| +--------+|
A|
cache additions || references |V||+----------+|| cache||+----------+|

89

2.2.  Common  conﬁgurations
2.2.  共通の構成• ネームサーバーの単純な構成
Local Host

| Foreign|+---------+|//||+---------+ |+----------+| +--------+|| |||responses| |
|
|
| |
|
Name
|---------|->|Foreign || Master |-------------->| Server || |Resolver|| files | |||<--------|--||||/|| queries | +--------++---------++----------+|

90

2.2.  Common  conﬁgurations
2.2.  共通の構成• フルサービスリゾルバーのある構成
Local Hosts| Foreign|+---------+||| responses|| Stub|<--------------------+|| Resolver|||||----------------+||+---------+ recursive|||
queries|||V||+---------+ recursive+----------+| +--------+|| queries||queries | ||| Stub|-------------->| Recursive|---------|->|Foreign || Resolver|| Server|| | Name |||<--------------||<--------|--| Server |+---------+ responses||responses| ||+----------+| +--------+| Central |||cache ||+----------+|

91

2.2.  Common  conﬁgurations
2.2.  共通の構成• ゾーン転送を使う構成
Local Host

| Foreign|+---------+|//||+---------+ |+----------+| +--------+|| |||responses| |
|
|
| |
|
Name
|---------|->|Foreign || Master |-------------->| Server || |Resolver|| files | |||<--------|--||||/|| queries | +--------++---------++----------+|A|maintenance | +--------+|+------------|->|||
queries| |Foreign ||| | Name |+------------------|--| Server |maintenance responses | +--------+

92

2.3.  Conventions
2.3.  取り決め

93

2.3.1.  Preferred  name  syntax
2.3.1.  名前の構⽂文• 概要▫ ドメイン名の構⽂文▫ ラベルの構⽂文• ドメイン名の構⽂文▫ <domain>  ::=  <subdomain>  |  "  "▫ <subdomain>  ::=  <label>  |  <subdomain>  "."  <label>▫ <label>  ::=  <letter>  [  [  <ldh-‐‑‒str>  ]  <let-‐‑‒dig>  ]▫ <ldh-‐‑‒str>  ::=  <let-‐‑‒dig-‐‑‒hyp>  |  <let-‐‑‒dig-‐‑‒hyp>  <ldh-‐‑‒str>▫ <let-‐‑‒dig-‐‑‒hyp>  ::=  <let-‐‑‒dig>  |  "-‐‑‒"▫ <let-‐‑‒dig>  ::=  <letter>  |  <digit>▫ <letter>  ::=  any  one  of  the  52  alphabetic  characters  A  through  Z  in▫ upper  case  and  a  through  z  in  lower  case▫ <digit>  ::=  any  one  of  the  ten  digits  0  through  9

942.3.1.  Preferred  name  syntax
2.3.1.  名前の構⽂文• ラベル▫ ラベルはホスト名の規則に従う。

 英⽂文字で始まる  →  英⽂文字あるいは数字で始まる（RFC  1123）
 英⽂文字あるいは数字で終わる
 間の⽂文字は英⽂文字、数字、ハイフンが使える▫ 当時のホスト名の仕様

 RFC  952  DOD  INTERNET  HOST  TABLE  SPECIFICATION▫ RFC  1123  Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Support  によりホスト名の仕様が変更更された▫ ラベルは63⽂文字未満

95

2.3.2.  Data  Transmission  Order
2.3.2.  データ転送の順番• 概要▫ データのオクテットレベルでの順番を説明している。

96

2.3.3.  Character  Case
2.3.3.  ⼤大⽂文字⼩小⽂文字• 概要▫ ⼤大⽂文字⼩小⽂文字の取り扱いについて• ⼤大⽂文字⼩小⽂文字の区別▫ ラベルやドメイン名などの⽐比較の際には⼤大⽂文字⼩小
⽂文字を区別しない。

• ⼤大⽂文字⼩小⽂文字の維持▫ 可能な限り⼤大⽂文字⼩小⽂文字を維持する。

• RFC  4343  "Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation"

97

2.3.4.  Size  limits
2.3.4.  サイズの制限• 概要▫ サイズの制限• サイズの制限▫ ラベル

 63オクテット以下▫ 名前

 255オクテット以下▫ TTL

 符号付き32ビット整数の正の数▫ UDPメッセージ 512オクテット以下

98

3.  DOMAIN  NAME  SPACE  AND  RR  DEFINITIONS
3.  ドメイン名空間とRRの定義• 3.1.  Name  space  deﬁnitions            名前空間の定義• 3.2.  RR  deﬁnitions            RRの定義• 3.3.  Standard  RRs            標準のRRs• 3.4.  ARPA  Internet  speciﬁc  RRs            Internet特有のRRs• 3.5.  IN-‐‑‒ADDR.ARPA  domain            IN-‐‑‒ADDR.ARPAドメイン• 3.6.  Deﬁning  new  types,  classes,  and  special  namespaces            新しいタイプ、クラス、特別な名前空間の定義⽅方法

99

3章の位置づけ
ネームサーバー

ゾーン転送（権威サーバー）

ネームサーバーロード（権威サーバー）

マスター
ファイル
ゾーン内のリソース
レコードを記述

メッセージ
ネームサーバー

ドメイン名空間（フルサービス
リゾルバー）

メッセージ

リソースレコードcomjp

example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

リゾルバー

ドメイン名
exampleexample

ns

www

co

ns.example.jp.
192.0.2.1

タイプ

100

3.1.  Name  space  deﬁnitions
3.1.  名前空間の定義• 概要▫ ドメイン名▫ ラベル• ドメイン名とラベルの定義▫ メッセージ内のドメイン名は⼀一続きのラベルで説明される。
▫ 各ラベルは⼀一つのオクテットの⻑⾧長さとオクテットの数で表現される。
▫ 各ドメイン名はルートのnullラベルで終わる。ドメイン名
は0の⻑⾧長さのバイトで終わる。
▫ 各⻑⾧長さの上位2ビットは0になり、⻑⾧長さのオクテットの残りの6ビットはラベルを63オクテット以下に制限する。
▫ ドメイン名の⻑⾧長さは255オクテット以下。

101

3.2.  RR  deﬁnitions
3.2.  RRの定義

102

3.2.1.  Format
3.2.1.  フォーマット
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|
/
/
/
NAME
/
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
TYPE|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
CLASS
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
TTL
|
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|RDLENGTH|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/
RDATA
/
/
/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

103

3.2.1.  Format
3.2.1.  フォーマット
• NAME▫ 所有者名。このリソースレコードに関するノードの名前• TYPE▫ RR  TYPEコードの⼀一つを含む2オクテット• CLASS▫ RR  CLASSコードの⼀一つを含む2オクテット

104

3.2.1.  Format
3.2.1.  フォーマット
• TTL▫ 符号付き32ビット整数。リソースレコードがキャッシュされてもよい時間間隔。

• RDLENGTH▫ RDATAフィールドのオクテット⻑⾧長を⽰示す符号無し
16ビット整数。

• RDATA▫ リソースを⽰示す可変⻑⾧長の⽂文字。

105

3.2.1.  Format
3.2.1.  フォーマット
• 間違い▫ "SOA  records  are  always  distributed  with  a  zero  TTL  to  prohibit  caching."• RFC  2181  Clariﬁcations  to  the  DNS  Speciﬁcation  "7.2.  TTLs  on  SOA  RRs"

▫ どこにも⾔言及されていないし、そのような実装は
⾏行行われていない。実装はTTLが0であることを想定すべきではないし、0のTTLを持つSOAレコー
ドを送信することを要求してもいけない。

106

3.2.2.  TYPE  values
3.2.2.  TYPEの値
TYPE

value

meaningA1

a  host  addressNS2a  host  address

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  pointerMX

15

mail  exchange

TXT

16

text  strings

107

3.2.3.  QTYPE  values
3.2.3.  QTYPEの値• QTYPEは問い合わせのquestionパートで出てくる。
• QTYPEはTYPEのスーパーセット。
• QTYPEの"MAILB"と"MAILA"は使われていない。

QTYPE

value

meaning

AXFR

252

A  request  for  a  transfer  of  an  entire  zone*

255

A  request  for  all  records

108

3.2.4.  CLASS  values
3.2.4.  CLASSの値
CLASS
mnemonics

value

meaningIN1the  InternetCS2the  CSNET  class  (Obsolete)CH3the  CHAOS  classHS

4

Hesiod109

3.2.5.  QCLASS  values
3.2.5.  QCLASSの値• QCLASSは問い合わせのquestionセクションで出てくる。
• QCLASSはCLASSのスーパーセット

QCLASS
mnemonics

value

meaning*255

any  class110

3.3.  Standard  RRs3.3.  標準のRRs

111

3.3.1.  CNAME  RDATA  format+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/
CNAME
/
/
/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:CNAME

A <domain-name> which specifies the canonical or primaryname for the owner. The owner name is an alias.

CNAME RRs cause no additional section processing, but name servers may
choose to restart the query at the canonical name in certain cases. See
the description of name server logic in [RFC-1034] for details.

112

3.3.9.  MX  RDATA  format+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
PREFERENCE|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+/EXCHANGE///+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE

A 16 bit integer which specifies the preference given tothis RR among others at the same owner. Lower values
are preferred.

EXCHANGE

A <domain-name> which specifies a host willing to act asa mail exchange for the owner name.

MX records cause type A additional section processing for the hostspecified by EXCHANGE. The use of MX RRs is explained in detail in[RFC-974].

113

3.3.11.  NS  RDATA  format+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+/NSDNAME///+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:NSDNAME

A <domain-name> which specifies a host which should be
authoritative for the specified class and domain.

NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of thezone in which they reside for glue information.

114

3.3.12.  PTR  RDATA  format+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+/PTRDNAME/+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:PTRDNAME

A <domain-name> which points to some location in thedomain name space.

PTR records cause no additional section processing. These RRs are usedin special domains to point to some other location in the domain space.
These records are simple data, and don't imply any special processing
similar to that performed by CNAME, which identifies aliases. See thedescription of the IN-ADDR.ARPA domain for an example.

115

3.3.13.  SOA  RDATA  format+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/
MNAME
/
/
/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/
RNAME
/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|SERIAL|||+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|REFRESH|||+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
RETRY
|
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
EXPIRE|||+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|MINIMUM|||+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

116

3.3.13.  SOA  RDATA  format• MNAME▫ このゾーンのデータのオリジナルあるいはプライマリであるネームサーバーのドメイン名。
▫ RFC  2181  Clariﬁcations  to  the  DNS  Speciﬁcation  "7.3.  The  SOA.MNAME  ﬁeld"
 SOAレコードのMNAMEフィールドはゾーンのマス
ターサーバの名前を設定する。
 ゾーン⾃自体の名前を書くべきではない。

117

3.3.13.  SOA  RDATA  format• RNAME▫ このゾーンの責任者のメールアドレス。
▫ 訳注）メールアドレスの"@"を"."に置き換える。

 例例）"foo@example.com"は"foo.example.com"に。

• SERIAL▫ ゾーンのオリジナルコピーの符号無し32ビットバージョン番号。ゾーン転送はこの値を維持する。
この値は周回し、sequence  space  arithmeticを使って⽐比較する。
▫ RFC  1982  Serial  Number  Arithmeticで⽐比較について詳細な説明がある。

118

3.3.13.  SOA  RDATA  format• REFRESH▫ ゾーンをリフレッシュするまでの32ビット時間間隔。

• RETRY▫ 失敗したリフレッシュを再試⾏行行するまでの32ビッ
ト時間間隔。

• EXPIRE▫ ゾーンが権威をなくすまでの時間の上限を⽰示す32
ビットの時間の値。

119

3.3.13.  SOA  RDATA  format• MINIMUM▫ このゾーンのRRを送信するときに指定されるTTLの最⼩小値。符号無し32ビット。
▫ RFC  2308  Negative  Caching  of  DNS  Queries  (DNS  NCACHE)により否定応答のキャッシュのTTLとして再定義された。

120

3.3.14.  TXT  RDATA  format+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+/TXT-DATA/+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:TXT-DATAOne or more <character-string>s.

TXT RRs are used to hold descriptive text.
depends on the domain where it is found.

The semantics of the text

121

3.4.  Internet  speciﬁc  RRs3.4.1.  A  RDATA  format+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|ADDRESS|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:ADDRESSA 32 bit Internet address.

Hosts that have multiple Internet addresses will have multiple A
records.
A records cause no additional section processing. The RDATA section of
an A line in a master file is an Internet address expressed as fourdecimal numbers separated by dots without any imbedded spaces (e.g.,"10.2.0.52" or "192.0.5.6").

122

3.5.  IN-‐‑‒ADDR.ARPA  domain• 概要▫ IN-‐‑‒ADDR.ARPAドメインは逆引き（IPアドレスか
らホスト名へのマッピング）のために⽤用いられる。

123

3.6.  Deﬁning  new  types,  classes,  and  special  namespaces• 概要▫ 新しいタイプやクラスや特別な名前空間の定義の仕⽅方を説明。

124

4.  MESSAGES
4.  メッセージ• 4.1.  Format            フォーマット
• 4.2.  Transport            転送1254章の位置づけ
ネームサーバー

ゾーン転送（権威サーバー）

ネームサーバーロード（権威サーバー）

マスター
ファイル
ゾーン内のリソース
レコードを記述

メッセージ
ネームサーバー

ドメイン名空間（フルサービス
リゾルバー）

メッセージ

リソースレコードcomjp

example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

リゾルバー

ドメイン名
exampleexample

ns

www

co

ns.example.jp.
192.0.2.1

タイプ

126

4.1.  Format
4.1.  フォーマット

+---------------------+|Header|+---------------------+|
Question| the question for the name server+---------------------+|
Answer| RRs answering the question+---------------------+|
Authority| RRs pointing toward an authority+---------------------+|
Additional| RRs holding additional information+---------------------+

127

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
ID|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|QR|
Opcode |AA|TC|RD|RA|
Z
|
RCODE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|QDCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|ANCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
NSCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
ARCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

128

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
• ID▫ 16ビットの識識別⼦子。

• QR▫ Query(0)かResponse(1)かを⽰示す1ビット• OPCODE▫ 問い合わせの種類を⽰示す4ビット。

• AA▫ Authoritative  Answer（権威ある回答）であるかを⽰示
す1ビット。
▫ 対応したネームサーバーがquestionセクションのドメ
イン名に対する権威を持っているかを⽰示す。

129

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
• TC▫ TrunCation  –  メッセージが⼤大きくて切切り詰められたことを⽰示す。

• RD▫ Recursion  Desired  –  ネームサーバーに再帰問い合わ
せをすることを指⽰示する。

• RA▫ Recursion  Available  –  ネームサーバーが再帰問い合
わせをサポートしているかを⽰示す。

•Z▫ 将来のための予約。0にする。

130

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
• RCODE▫ Response  code  –  応答コード

 0:  No  error  condition
 1:  Format  error 2:  Server  failure 3:  Name  Error 4:  Not  Implemented
 5:  Refused 6-‐‑‒15:  Reserved  for  future  use.

131

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
• QDCOUNT▫ questionセクションのエントリーの数を⽰示す符号無し
16ビット整数• ANCOUNT▫ answerセクションのエントリーの数を⽰示す符号無し
16ビット整数• NSCOUNT▫ authorityレコードセクションのリソースレコードの数を⽰示す符号無し16ビット整数• ARCOUNT▫ additionalレコードセクションのリソースレコードの数を⽰示す符号無し16ビット整数

132

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
ID|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|QR|
Opcode |AA|TC|RD|RA|
Z
|
RCODE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|QDCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|ANCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
NSCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
ARCOUNT|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

133

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
$ dig @127.0.0.1 emaillab.jp. NS
略略;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33981;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2;; QUESTION SECTION:;emaillab.jp.

IN

NS;; ANSWER SECTION:
emaillab.jp.
emaillab.jp.

86400
86400

IN
IN

NS
NS

ns.emaillab.jp.
ns2.emaillab.jp.

;; ADDITIONAL SECTION:
ns.emaillab.jp.
ns2.emaillab.jp.

86400
86400

IN
IN

A
A

49.212.17.32
49.212.24.158

134

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
$ dig +norec @ns.emaillab.jp. emaillab.jp. NS
略略;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24693;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2;; QUESTION SECTION:;emaillab.jp.

IN

NS;; ANSWER SECTION:
emaillab.jp.
emaillab.jp.

86400
86400

IN
IN

NS
NS

ns.emaillab.jp.
ns2.emaillab.jp.

;; ADDITIONAL SECTION:
ns.emaillab.jp.
ns2.emaillab.jp.

86400
86400

IN
IN

A
A

49.212.17.32
49.212.24.158

135

4.1.1.  Header  section  format
4.1.1.  Headerセクションフォーマット
$ dig +norec @a.dns.jp. emaillab.jp. NS;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35302;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2;; QUESTION SECTION:;emaillab.jp.

IN

NS;; AUTHORITY SECTION:
emaillab.jp.
emaillab.jp.

86400
86400

IN
IN

NS
NS

ns.emaillab.jp.
ns2.emaillab.jp.

;; ADDITIONAL SECTION:
ns.emaillab.jp.
ns2.emaillab.jp.

86400
86400

IN
IN

A
A

49.212.17.32
49.212.24.158

136

4.1.2.  Question  section  format
4.1.2.  Questionセクションフォーマット
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|
/
QNAME
/
/
/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QTYPE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|QCLASS|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

137

4.1.3.  Resource  record  format
4.1.3.  リソースレコードフォーマット 　 　

1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|
/
/
/
NAME
/
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|
TYPE|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
CLASS
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
TTL
|
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|RDLENGTH|+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/
RDATA
/
/
/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

138

4.2.  Transport
4.2.  転送
• 概要

▫ DNSのメッセージがUDPあるいはTCPで転送されることを説明している。

139

4.2.1.  UDP  usage• メッセージは512バイトに制限される。
• 512バイトより⼤大きいメッセージは切切り詰められ、ヘッダーにTCビットを⽴立立てる。
• RFC  2181  Clariﬁcations  to  the  DNS  Speciﬁcation  "9    The  TC  (truncated)  header  bit"にTCビットがどういうときにセットされるかについての説明がある。
• RFC  2671  Extension  Mechanisms  for  DNS  (EDNS0)  により、UDPで512バイトより⼤大きいメッセージを送ることが可能である。

140

4.2.2.  TCP  usage• RFC  5966  DNS  Transport  over  TCP  -‐‑‒  Implementation  RequirementsによりDNS  over  TCPの仕様が更更新されている。

141

5.  MASTER  FILES
5.  マスターファイル• 5.1.  Format• 5.2.  Use  of  master  ﬁles  to  deﬁne  zones• 5.3.  Master  ﬁle  example

142

5章の位置づけ
ネームサーバー

ゾーン転送（権威サーバー）

ネームサーバーロード（権威サーバー）

マスター
ファイル
ゾーン内のリソース
レコードを記述

メッセージ
ネームサーバー

ドメイン名空間（フルサービス
リゾルバー）

メッセージ

リソースレコードcomjp

example.jp.

IN SOA ns.exampele.jp. ..

example.jp.

IN NS

ns.example.jp. IN A

リゾルバー

ドメイン名
exampleexample

ns

www

co

ns.example.jp.
192.0.2.1

タイプ

143

5.1.  Format• エントリーは⾏行行毎に。
• アイテムが⾏行行を跨がる場合には括弧（）で囲む。
• アイテム間のデリミターとしてスペースとタブ
およびその組み合わせが使える。
• ⾏行行の終わりはコメントで終わることができる。
• コメントは";"で始まる。
• @はオリジンを元に戻す。

144

5.1.  Format• エントリーの形式▫ <blank>[<comment>]▫ $ORIGIN  <domain-‐‑‒name>  [<comment>]▫ $INCLUDE  <ﬁle-‐‑‒name>  [<domain-‐‑‒name>]  [<comment>]▫ <domain-‐‑‒name><rr>  [<comment>]▫ <blank><rr>  [<comment>]• <rr>の定義▫ [<TTL>]  [<class>]  <type>  <RDATA>▫ [<class>]  [<TTL>]  <type>  <RDATA>

145

6.  NAME  SERVER  IMPLEMENTATION6.  ネームサーバーの実装• 6.1.  Architecture• 6.2.  Standard  query  processing• 6.3.  Zone  refresh  and  reload  processing• 6.4.  Inverse  queries  (Optional)• 6.5.  Completion  queries  and  responses• 本章はネームサーバーの開発者向けの内容であり、チュートリアルには向かない内容なので、説明は省省略略する。

146

7.  RESOLVER  IMPLEMENTATION
7.  リゾルバーの実装• 7.1.  Transforming  a  user  request  into  a  query
• 7.2.  Sending  the  queries• 7.3.  Processing  responses• 7.4.  Using  the  cache• 本章はネームサーバーの開発者向けの内容であり、チュートリアルには向かない内容なので、説明は省省略略する。

147

8.  MAIL  SUPPORT
8.  メールサポート• 省省略略148

9.  REFERENCES  and  BIBLIOGRAPHY
9.  出典と参考⽂文献• 省省略略149

150

RFC  1123

Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Support• タイトル▫ Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Support▫ インターネットホストの要求事項  –  アプリケーションとサポート• 概要▫ インターネットに接続するホストが満たすべき要求事項を定めている。
▫ もちろん、ホスト名やDNSのサポートについても

151

RFC  1123

Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Support• 2.1    Host  Names  and  Numbers
ホスト名と数▫ ホスト名の⽂文法の改訂（RFC  952の改訂）

 ホスト名の最初の⽂文字は英⽂文字のみであったが、数字も使えるようになった。
 ホスト名の⻑⾧長さは24⽂文字までであったが、下記のようになった。

▫ ホスト名 英⽂文字あるいは数字で始まる
 英⽂文字あるいは数字で終わる
 間の⽂文字は英⽂文字、数字、ハイフンが使える▫ ホストソフトウェアは 63⽂文字までのホスト名を扱わなければならない（MUST）
 255⽂文字までのホスト名を扱うべきである（SHOULD）

152

RFC  1982

Serial  Number  Arithmetic• タイトル▫ Serial  Number  Arithmetic▫ シリアル番号演算• 概要▫ RFC  1034とRFC  1035ではゾーン転送におけるSOAレコードのシリアル番号の⽐比較に"sequence  space  arithmetic"を使うと記述されている。
▫ しかし、"sequence  space  arithmetic"そのものの定義がない。
▫ RFC  1982ではその定義を⾏行行う。

153

RFC  1982

Serial  Number  Arithmetic• おおざっぱにまとめると▫ シリアル番号の扱い

 32ビットの符号無し整数
 範囲は[0  ..  4294967295]（2^32  -‐‑‒  1）
 最⼤大値から0に周回する。つまり、4294967295+1は0 増加の範囲は[0  ..  2147483647]    (2^31  -‐‑‒  1)▫ シリアル番号の増分が増加の最⼤大値以下であれば「シリアル番号の増加(increment)」と判断する。
 例例）「4294967295  →  0」は増分が1なので、「増加」と判断できる。

154

RFC  1982

Serial  Number  Arithmetic• シリアル番号の保守▫ RFC  2182  "Selection  and  Operation  of  Secondary  DNS  Servers"
 "7.  Serial  Number  Maintenance"

 間違って⼤大きすぎる番号を付けてしまった場合に、⼩小
さい番号に付け直す⽅方法が書いてある。

155

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• タイトル▫ Clariﬁcations  to  the  DNS  Speciﬁcation▫ DNSの仕様の明確化• 概要▫ この⽂文書はDNSの仕様の問題として確認されている分野について考察し、確認された⽋欠陥の改善を
提案する。

156

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 4.  Server  Reply  Source  Address  Selection▫ マルチホームのサーバにおける応答の送信元アドレスの選択⽅方法• 4.1.  UDP  Source  Address  Selection

 問い合わせの宛先アドレスを応答の送信元アドレス
としてセットする。

• 4.2.  Port  Number  Selection

 問い合わせの送信元ポート番号を応答の宛先ポート
番号として使う。
 応答は指⽰示されたポート番号から送信される。
 DNSのウェルノウンポート、53

157

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 5.  Resource  Record  Sets

▫ 同じラベル、クラス、タイプのリソースレコードの集まりを「リソースレコードセット」（RRset）と定義する。
▫ 問い合わせに対して、関連するRRが複数あるときには、RRsetのすべてのRRを返す。
▫ RRsetのすべてのRRは同じTTLを使う。

158

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 5.4.1.  Ranking  data

▫ データの信頼性の順位について論論じている。下に⾏行行くほど低い。

 Data  from  a  primary  zone  ﬁle,  other  than  glue  data, Data  from  a  zone  transfer,  other  than  glue, The  authoritative  data  included  in  the  answer  section  of  an  authoritative  reply.
 Data  from  the  authority  section  of  an  authoritative  answer, Glue  from  a  primary  zone,  or  glue  from  a  zone  transfer, Data  from  the  answer  section  of  a  non-‐‑‒authoritative  answer,  and  non-‐‑‒authoritative  data  from  the  answer  section  of  authoritative  answers,
 Additional  information  from  an  authoritative  answer,  Data  from  the  authority  section  of  a  non-‐‑‒authoritative  answer,  Additional  information  from  non-‐‑‒authoritative  answers.

159

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 6.  Zone  Cuts

▫ zone▫ zone  cut▫ "child"  zone
▫ "parent"  zone
▫ zone's  "origin"• 6.1.  Zone  authority▫ ゾーンの権威について

160

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 7.  SOA  RRs

▫ SOAレコードに関する記述を3つ修正

161

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 7.1.  Placement  of  SOA  RRs  in  authoritative  answers▫ RFC  1034  "4.3.4  Negative  response  caching  (Optional)"の内容が間違っている。

 The  method  is  that  a  name  server  may  add  an  SOA  RR  to  the  additional  section  of  a  response  when  that  response  is  authoritative.

▫ ネガティブキャッシュのときにもSOAレコードを
authorityセクションにおいて回答する。
 SOA  records,  if  added,  are  to  be  placed  in  the  authority  section.

162

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 7.2.  TTLs  on  SOA  RRs

▫ RFC  1035  "3.2.1.  Format"の内容が間違っている。

 SOA  records  are  always  distributed  with  a  zero  TTL  to  prohibit  caching.

• 7.2.  TTLs  on  SOA  RRs

▫ どこにも⾔言及されていないし、そのような実装は⾏行行われていない。実装はTTLが0であることを想定すべきではないし、0のTTLを持つSOAレコードを送信することを要求してもいけない。
 This  is  mentioned  nowhere  else,  and  has  not  generally  been  implemented.  Implementations  should  not  assume  that  SOA  records  will  have  a  TTL  of  zero,  nor  are  they  required  to  send  SOA  records  with  a  TTL  of  zero.

163

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 7.3.  The  SOA.MNAME  ﬁeld

▫ 仕様では明確になっているが広く無視されている。
▫ SOAレコードのMNAMEフィールドはゾーンのマ
スターサーバの名前を設定する。
▫ ゾーン⾃自体の名前を書くべきではない。

164

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 8.  Time  to  Live  (TTL)▫ RFC  1035におけるTTLの定義
 2.3.4.  Size  limits positive  values  of  a  signed  32  bit  number.

 3.2.1.  Format

 a  32  bit  signed  integer  that  speciﬁes  the  time  interval

 4.1.3.  Resource  record  format

 a  32  bit  unsigned  integer  that  speciﬁes  the  time  interval▫ 明確にする

 符号無し整数
 最⼩小値:  0
 最⼤大値:  2147483647    (2^31  -‐‑‒  1)
 最上位ビットが1であるときにはTTLを0と扱うべき

165

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 9.  The  TC  (truncated)  header  bit
▫ TCビットについての説明

166

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 10.  Naming  issues

167

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 10.1.  CNAME  resource  records▫ CNAMEの意味を明確化

 CNAME  ("canonical  name")「正式名」は"alias  name"「別名」と関連づけるために使う
 CNAMEは「別名」を⽰示すのでなく、「別名」に対する「正式名」を⽰示す。
 別名  IN  CNAME  正式名

168

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 10.2.  PTR  records▫ PTRレコードは⼀一つだけ持つというのは誤り。
▫ PTRレコードの値には（CNAMEで定義される）
別名であってならない。

169

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 10.3.  MX  and  NS  records▫ MXレコードとNSレコードの値は（CNAMEで定義される）別名であってはならない。

170

RFC  2181

Clariﬁcations  to  the  DNS  Speciﬁcation• 11.  Name  syntax▫ DNSはホスト名からデータへ、IPアドレスからホスト名へとマッピングするためだけのものではない。
▫ DNSは汎⽤用的な階層型データベースであり、様々なデータを様々な⽬目的で格納できる。

171

RFC  2308

Negative  Caching  of  DNS  Queries  (DNS  NCACHE)• タイトル▫ Negative  Caching  of  DNS  Queries  (DNS  NCACHE)▫ DNS問い合わせのネガティブキャッシュ• 概要▫ ネガティブキャッシュについての詳細な説明と再定義を⾏行行っている。

172

RFC  2308

Negative  Caching  of  DNS  Queries  (DNS  NCACHE)• RFC  1034からの変更更点（8  -‐‑‒  Changes  from  RFC  1034）▫ ネガティブキャッシュはoptionalであったが、RFC  2308ではキャッシュする場合は、ネガティブキャッ
シュもしなければならないよう（must）になった。
▫ AuthorityセクションのSOAレコードはキャッシュしなければならない（MUST）。
▫ キャッシュしたSOAレコードは応答に加えなければならない（MUST）。

• SOA  Minimumフィールド▫ 否定応答のTTLとして使われる。
▫ 元々別の意味で定義されていたが再定義された。

173

RFC  4343

Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation• タイトル▫ Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation▫ DNSの⼤大⽂文字⼩小⽂文字を区別しないことの明確化• 概要▫ ドメイン名の⼤大⽂文字⼩小⽂文字を区別しない。
 ASCII⽂文字が対象▫ この⽂文書はその意味を説明し、仕様を明確にする。

174

RFC  4343

Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation• 問い合わせにおいては⼤大⽂文字⼩小⽂文字を区別すべきでない。

▫ 次の2つのドメイン名の問い合わせは同じ結果となる。
 foo.example.net.
 Foo.ExamplE.net.

▫ 実装

 ⽐比較前に0x61-‐‑‒0x7Aの範囲の⽂文字（⼩小⽂文字）であれば0x20を引く。

• ⼤大⽂文字⼩小⽂文字の維持▫ 可能な限りオリジナルの⼤大⽂文字⼩小⽂文字を維持すべきで
ある。

175

RFC  4343

Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation• ラベルのエスケープ⽅方法▫ DNSのプロトコル上は8ビット⽂文字も使える。
▫ ⽂文字コードが0x00-‐‑‒0x20,0x2E(.),0x7F-‐‑‒0xFFである
⽂文字をバックスラッシュでエスケープする記法
 バックスラッシュ(\)  +  ⽂文字コードの3桁の⼗十進数
 バックスラッシュ(\)  +  ⽂文字（ASCII印字可能⽂文字の場
合）

▫ 例例

 バックスラッシュ"\"  →  "\092"  or  "\\"
 ピリオド"."  →  "\046"  or  "\."
 スペース" "  →  "\032"

176

RFC  4343

Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation• Use  of  Bit  0x20  in  DNS  Labels  to  Improve  Transaction  Identity▫ というInternet  Draftがかつて提案されていた。
▫ 通称"dns  0x20"
 ⼤大⽂文字のコードに対して0x20ビットを⽴立立てると⼩小
⽂文字のコードになる。
 0x41  (A)  +  0x20  =  0x61  (a)▫ キャッシュポイズニングへの耐性を向上させることを⽬目的とする。
▫ 問い合わせとその回答において⼤大⽂文字⼩小⽂文字を維持する仕様を利利⽤用する。

177

RFC  4343

Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation• Use  of  Bit  0x20  in  DNS  Labels  to  Improve  Transaction  Identity▫ リゾルバーは問い合わせに⼤大⽂文字⼩小⽂文字をランダ
ムに設定する。
 FoO.ExAmplE.nEt.

▫ 権威サーバーは問い合わせの名前を⼤大⽂文字⼩小⽂文字を維持したままコピーして回答する。
 FoO.ExAmplE.nEt.

▫ リゾルバーは問い合わせと回答の⽂文字列列を⽐比較して同じであれば信⽤用する。異異なれば偽の回答と判
断する。

178

RFC  5452

Measures  for  Making  DNS  More  Resilient  against  Forged  Answers• タイトル▫ Measures  for  Making  DNS  More  Resilient  against  Forged  Answers▫ DNSを偽の回答に対する耐性の強化⽅方法• 概要▫ DNSを不不正な応答を受け付けることに対して耐性を強化する⽅方法について説明する。

179

RFC  5452

Measures  for  Making  DNS  More  Resilient  against  Forged  Answers• 9.1.    Query  Matching  Rules▫ RFC  2181  "5.4.1.  Ranking  data"のDNSの信頼性規則を適応する前に▫ リゾルバーの実装は次のような問い合わせの属性のすべてに、応答が⼀一致していなければならない（MUST）。
 問い合わせの宛先アドレスに対する送信元アドレス
 問い合わせの送信元アドレスに対する宛先アドレス
 問い合わせの送信元ポートに対する宛先ポート
 問い合わせID
 問い合わせの名前
 問い合わせのクラスとタイプ▫ ⼀一致しない応答は不不正と判断しなければならない（MUST）。

180

RFC  5452

Measures  for  Making  DNS  More  Resilient  against  Forged  Answers• 9.2.    Extending  the  Q-‐‑‒ID  Space  by  Using  Ports  and  Addresses▫ リゾルバーの実装（MUST）:

 外部への問い合わせには、実際に利利⽤用できて可能な限り⼤大きい範囲のポート番号から予測不不能な送信元
ポート番号を使う
 同時に複数の問い合わせが起こる場合には、複数の異異なる送信元ポート番号を使う
 外部への問い合わせには、全範囲（0-‐‑‒65535）を利利⽤用して、予測不不能な問い合わせIDを使う。

181

RFC  5452

Measures  for  Making  DNS  More  Resilient  against  Forged  Answers• 9.3.    Spoof  Detection  and  Countermeasure▫ リゾルバは詐称を検出したら、UDP問い合わせを破棄し、TCPで再発⾏行行させてもよい（MAY）
 TCPは詐称に対する耐性が強い

182

RFC  5936

DNS  Zone  Transfer  Protocol  (AXFR)• タイトル▫ DNS  Zone  Transfer  Protocol  (AXFR)▫ DNSのゾーン転送プロトコル  (AXFR)• 概要▫ RFC  1034とRFC  1035におけるAXFRの定義が不不⼗十分であり、仮定して実装しなければならないところがあり、相互運⽤用性を阻害している。
▫ この⽂文書はAXFRの新しい定義である。
▫ 「新しい」は相互運⽤用できるAXFR機能の正確な定義を記録する的な意味合いで。

183

RFC  5966

DNS  Transport  over  TCP  -‐‑‒  Implementation  Requirements• タイトル▫ DNS  Transport  over  TCP  -‐‑‒  Implementation  Requirements▫ DNSのTCP転送  –  実装と要求事項• 概要▫ この⽂文書はDNSのTCPでの転送の要求事項を更更新する。
▫ TCPサポートがSHOULDであったのをMUSTにす
る。

184

RFC  5966

DNS  Transport  over  TCP  -‐‑‒  Implementation  Requirements• 4.    Transport  Protocol  Selection▫ すべての通常の⽬目的のDNSの実装はUDPとTCPの両⽅方をサポートしなければならない（MUST）
 権威サーバーの実装は、応答のサイズを⼀一つのUDPパケットに収めるサイズに制限しないようにTCPをサポートしなければならない（MUST）。
 再帰検索索サーバー（あるいはフォワーダー）の実装は、TCPを利利⽤用できるサーバーからの⼤大きなサイズの応答をTCPが利利⽤用できるクライアントに達するのを妨げないよ
うに、TCPをサポートしなければならない（MUST）。
 スタブリゾルバーの実装は、⾃自⾝身のクライアントと上流流のサーバーとの相互運⽤用性を制限しないように応答サイ
ズを、TCPをサポートしなければならない（MUST）。

185

DNSの基本仕様およびアップデート（再掲）
RFC  1982  /  PS
Serial  Number  Arithmetic
RFC  1034  /  STD  13
DOMAIN  NAMES  -‐‑‒  CONCEPTS  AND  FACILITIESRFC  1035  /  STD  13
DOMAIN  NAMES  -‐‑‒  IMPLEMENTATION  AND  SPECIFICATION
RFC  1123  /  STD  3
Requirements  for  Internet  Hosts  -‐‑‒-‐‑‒  Application  and  Supportアップデート参照

RFC  2181  /  PS
Clariﬁcations  to  the  DNS  Speciﬁcation

RFC  2308  /  PS
Negative  Caching  of  DNS  Queries  (DNS  NCACHE)

RFC  3425  /  PS
Obsoleting  IQUERYRFC  4343  /  PS
Domain  Name  System  (DNS)  Case  Insensitivity  Clariﬁcation

RFC  5452  /  PS
Measures  for  Making  DNS  More  Resilient  against  Forged  Answers

RFC  5936  /  PS
DNS  Zone  Transfer  Protocol  (AXFR)

RFC  5966  /  PS
DNS  Transport  over  TCP  -‐‑‒  Implementation  Requirements

186

187

RFC  2671

Extension  Mechanisms  for  DNS  (EDNS0)• タイトル▫ Extension  Mechanisms  for  DNS  (EDNS0)▫ DNSの拡張機構（EDNS0）• 概要▫ DNSのプロトコルを機能する。
▫ これにより、UDPで512オクテットを超えるメッセージを扱うことができる。

188

RFC  1995

Incremental  Zone  Transfer  in  DNS

• タイトル▫ Incremental  Zone  Transfer  in  DNS
▫ DNSの差分ゾーン転送• 概要▫ DNSのプロトコルにIXFR（差分ゾーン転送）機
能を提供するための拡張を提案する。

189

RFC  1996

A  Mechanism  for  Prompt  Notiﬁcation  of  Zone  Changes  (DNS  NOTIFY)• タイトル▫ A  Mechanism  for  Prompt  Notiﬁcation  of  Zone  Changes  (DNS  NOTIFY)▫ ゾーン変更更の通知機能（DNS  NOTIFY）• 概要▫ マスターサーバーがスレーブサーバーにゾーンの変更更を通知するNOTIFY  opcodeを提案する。

190

RFC  2845

Secret  Key  Transaction  Authentication  for  DNS  (TSIG)• タイトル▫ Secret  Key  Transaction  Authentication  for  DNS  (TSIG)▫ DNSの秘密鍵によるトランザクション認証（TSIG）• 概要▫ 共有秘密鍵を⼀一⽅方向ハッシュを使ったトランザク
ションレベルの認証を提案する。

191

RFC  3645

Generic  Security  Service  Algorithm  for  Secret  Key  Transaction  Authentication  for  DNS  (GSS-‐‑‒TSIG)• タイトル▫ Generic  Security  Service  Algorithm  for  Secret  Key  Transaction  Authentication  for  DNS  (GSS-‐‑‒TSIG)▫ DNSの秘密鍵トランザクション認証のためのGSS-‐‑‒API（GSS-‐‑‒TSIG）• 概要▫ TSIGでGSS-‐‑‒APIを使う拡張を提案する。

192

RFC  4635

HMAC  SHA  TSIG  Algorithm  Identiﬁers• タイトル▫ HMAC  SHA  TSIG  Algorithm  Identiﬁers▫ HMAC  SHA  TSIGアルゴリズム識識別⼦子• 概要▫ TSIGでHMAC  SHAを扱う⽅方法を提案する。

193

RFC  2136

Dynamic  Updates  in  the  Domain  Name  System  (DNS  UPDATE)• タイトル▫ Dynamic  Updates  in  the  Domain  Name  System  (DNS  UPDATE)▫ DNSにおける動的更更新（DNS  UPDATE）• 概要▫ UPDATE  opcodeを使って、指定したゾーンのRR
やRRsetの追加や削除を⾏行行う⽅方法を提案する。

194

RFC  3007

Secure  Domain  Name  System  (DNS)  Dynamic  Update• タイトル▫ Secure  Domain  Name  System  (DNS)  Dynamic  Update▫ セキュアなDNS動的更更新• 概要▫ DNS動的更更新に認証機能を追加する。

195