2019.08.01

『DNSがよくわかる教科書』第3刷での変更点について

DNSがよくわかる教科書

■第3刷での変更点について

第3刷では誤りの修正はありませんが、以下の4点に関する変更を加えています。

1. 内容を読みやすくするための説明の追補、コラムの追加
2. DNSの用語を定義するRFC 7719がRFC 8499に置き換えられたことによる内容の更新
3. DNS over TLS / DNS over HTTPS の実装が進捗したことによる内容の更新
4. RFCの新規発行・置き換えに伴う付録Aの更新

以下、それぞれの項目における、第2刷からの変更点をご紹介します。

 


1. 内容を読みやすくするための説明の追補、コラムの追加

 

p.90 最終部分に2行追加
——————
キャッシュがクリアされた後でjprs.jpのIPアドレスの問い合わせが来たら、再度jprs.jpの権威サーバーに問い合わせて、結果を入手します。
なお、ネガティブキャッシュのTTLについては、6章04の「ゾーンそのものに関する情報 ~SOAリソースレコード」(p.123~124)を参照してください。
——————

p.248 第3段落の変更
——————
そこで、いくつかのCDNサービスやクラウドサービスを提供する事業者は、この問題を解決するために、独自のDNSサービスを開発・提供しています。例えば~
——————

p.249 1-2行目の変更
——————
これら独自のDNSサービスではゾーン頂点のドメイン名に、自らが提供するCDNサービスやクラウドサービスの設定を組み込むことができます。この場合~
——————

p.249 5-7行目の変更
——————
すように設定されます。そのため、これら独自のDNSサービスを使って自分のサービスを提供する場合、サービス提供用のサーバー(Webサーバーなど)と権威サーバーの双方を、そのDNSサービスを提供する事業者と同じ事業者に預ける形になります。
——————

p.288 新規コラム「DNSSECにおける鍵の作成・運用」の追加
——————
[COLUMN] DNSSECにおける鍵の作成・運用

電子署名では、署名に使う鍵の作成・運用をデータの作成者が行います。13章01の「電子署名のDNSSECへの適用」(p.281)で説明したように、DNSSECではそれぞれのゾーンの管理者が電子署名におけるデータの作成者、つまり鍵の作成・運用者となります。
ルートゾーンはICANNが管理運用の責任を負い、Verisignがゾーンファイルを作成しています。そのため、ルートゾーンの鍵は、ICANNとVerisignが作成・運用しています[*1]
jpやcomといったTLDはJPRSやVerisignといったTLDレジストリが管理し、ゾーンファイルを作成しています。そのため、TLDの鍵は、それぞれのTLDレジストリが作成・運用しています。
同様に、各組織のゾーンはそれぞれのゾーンの管理者が管理し、ゾーンファイルを作成しています。そのため、各組織のゾーンをDNSSECに対応させる場合、そのゾーンの鍵はそれぞれのゾーンの管理者が作成・運用する必要があります。
なお、DNSサービスを提供する事業者が、顧客から預かったゾーンの鍵の作成・運用とゾーンファイルへの署名・公開を、付加サービスのひとつとして提供している場合があります。各組織においてこうしたサービスを利用する場合、事業者がそのゾーンの管理者から未署名のゾーンファイルを預かり、鍵の作成・運用と署名・公開を代行します。

[*1] KSKをICANNが管理し、ZSKをVerisignが管理しています。KSKとZSKについては次節「DNSSECで使われる2種類の鍵(KSKとZSK)を参照。
——————

 


2. DNSの用語を定義するRFC 7719がRFC 8499に置き換えられたことによる内容の更新

 

p.79 コラム「統一されていない名称に注意」最終段落内
——————
~DNSの用語を定義しているRFC 8499で定められています。そのため~
——————

p.176 コラム「内部名と外部名」の内容を以下のものに変更
——————
内部名(In-bailiwick)は、委任先の権威サーバーのホスト名を分類するための用語です。In-bailiwickは、以下の2つのタイプに分割されます(図8-10)。

(a)In-domain:ホスト名がNSリソースレコードを設定しているゾーンカットのドメイン名、またはその子孫である。この場合、親ゾーンにグルーレコードの設定が必要になり、設定しない場合、名前解決に失敗する
(b)Sibling domain:ホスト名が委任元のドメイン名、またはその子孫であるが、In-domainではない。この場合、親ゾーンにグルーレコードを設定することは許可されるが、必須ではない

図8-10の(a)がIn-domain、(b)がSibling domainとなります。In-bailiwickではない名前は、外部名(Out-of-bailiwick)と呼ばれます。これらの用語の詳細については、DNSの用語を定義しているRFC 8499を参照してください。


——————

 


3. DNS over TLS / DNS over HTTPS の実装が進捗したことによる内容の更新

 

p.305 第1段落の変更
——————
DNS over TLSは、NLnet Labsが開発しているUnbound、CZ.NICが開発しているKnot Resolverが実装しています。パブリックDNSサービスではGoogle Public DNS、Quad9、1.1.1.1が、DNS over TLSを実装しています。
また、スタブリゾルバーとしては~
——————

p.306 「DNS over HTTPSの実装状況」の変更
——————
パブリックDNSサービスのGoogle Public DNS、Quad9、1.1.1.1が、DNS over HTTPSを実装しています。1.1.1.1では~
——————

 


4. RFCの新規発行・置き換えに伴う付録Aの更新

 

p.308 付録A「DNS関連」
・RFC 7719の行を削除
・RFC 8499の行を最後に追加
RFC 8499 | 2019年 1月 | DNS用語の定義 | 4章01

p.309 付録A「DNSSEC関連」
・RFC 8624の行を最後に追加
RFC 8624 | 2019年 6月 | DNSSECのアルゴリズム実装要件と使用ガイドライン |