■第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のアルゴリズム実装要件と使用ガイドライン | －
