■第7刷での変更点について
第7刷において、以下の点を更新しています。
1. G Suite→Google Workspaceへの名称変更と、内容更新への対応
2. QNAME minimisationに関するコラムを追加
3. DNS over QUICに関するコラムを追加
4. 付録AにRFCを追加
以下、それぞれの項目における、第6刷からの変更点をご紹介します。
1. G Suite→Google Workspaceへの名称変更と、内容更新への対応
p.262 本文下から3行目
変更前）
特に、2013年8月にGoogleのメールサービスGmailにおいてIPv6の逆引き設定が必須化されたことから、本件が改めて注目・認識されるようになりました。以下に、G Suite管理者ヘルプの内容を引用します。
変更後）
逆引きDNSをメールの受信許可に使っている例として、Google Workspace管理者ヘルプの内容を以下に引用します。
p.263 上の囲みの内容
変更前）
＜IPv6認証エラーを修正する＞
送信元サーバーのPTRレコードでIPv6が使用されていない場合、IPv6認証エラーが返される場合があります。メールサービスプロバイダを利用している場合は、プロバイダがIPv6のPTRレコードを使用していることを確認してください。
変更後）
＜送信元サーバーのPTRレコードを確認する＞
送信元IPアドレスにはPTRレコードが必要です。PTRレコードによって、送信元ホスト名が送信元IPアドレスに関連付けられていることが検証されます。すべてのIPアドレスは、PTRレコードのホスト名にマッピングされる必要があります。PTRレコードで指定されたホスト名には、送信元IPアドレスを参照する正引きDNSが必要です。
p.263 囲みの下の説明文
変更前）
一括送信ガイドライン：G Suite管理者ヘルプ（https://support.google.com/a/answer/81126?hl=ja）より引用
変更後）
Gmailユーザーへのメールがブロックされたり迷惑メール扱いされたりしないようにする（https://support.google.com/a/answer/81126?hl=ja）より引用
p.263 囲みの中が変更されたことによる、続きの文章の修正
変更前）
なお、上記に引用したとおりGmailでは、逆引きで得られたホスト名を名前解決（AAAAリソースレコードを検索）して得られたIPv6アドレスとの照合も実施しています。
変更後）
なお、上記に引用したとおりGmailでは、逆引きで得られたホスト名を名前解決（A/AAAAリソースレコードを検索）して得られたIPアドレスとの照合も実施しています。
2. QNAME minimisationに関するコラムを追加
p.303 新規コラム「QNAME minimisationの運用で得られた知見とその対応」
——————
［COLUMN］ QNAME minimisationの運用で得られた知見とその対応
QNAME minimisationでは階層構造をたどる際、クライアントが指定したドメイン名をそのまま使わず、必要最小限のドメイン名を使って問い合わせます。この問い合わせは委任情報（NSリソースレコードとグルーレコード）を得るためのものであるため、2016年に発行されたRFC 7816では問い合わせのタイプとして、NSリソースレコードを使っていました。
しかし、QNAME minimisationを運用する中で、インターネットにはNSリソースレコードを適切にサポートしないDNSソフトウェアやミドルボックス[*1]が存在し、それらに対してQNAME minimisationで問い合わせた場合、名前解決に失敗してしまう場合があることが報告されました。
この問題を避けるため、2021年に発行されたRFC 9156ではそれまでの運用で得られた知見を反映する形で、仕様と動作の改良が行われています。
RFC 9156ではQNAME minimisationの問い合わせのタイプとして、AまたはAAAAリソースレコードの使用を勧めています[*2]。これにより前述した問題を回避でき、かつ、QNAME minimisationの問い合わせを従来の問い合わせに紛れ込ませることができるため、プライバシーをより高めることができます。
なお、QNAME minimisationにおいて委任情報をより確実に得られるようにするため、必要最小限のドメイン名に「_.」を追加したドメイン名（例えば「_.example.jp」）を問い合わせに使うDNSソフトウェアもあります。
[*1] ファイアウォール、ロードバランサー、ネットワークアドレス変換（NAT）装置など、通信路の間（middle）に存在し、ルーティング以外の動作をする装置（box）の総称です。ミドルボックスはRFC 3234で分類・定義されています。
[*2] NSリソースレコードを使った問い合わせも引き続き許可されています。本書の動作説明では、NSリソースレコードを用いて解説しています。
——————
3. DNS over QUICに関するコラムを追加
p.305 新規コラム「DNS over QUIC」
——————
［COLUMN］ DNS over QUIC
DNSの通信をQUIC[*1]で保護（暗号化）する「DNS over QUIC」が、2022年5月にRFC 9250として標準化されました。DNS over QUICの通信にはDNS over DTLSと同じ、UDPのポート853番が割り当てられており、従来のDNS通信との混乱を避けるため、UDPのポート53番の使用は禁止されています。
DNS over QUICにおけるDNSメッセージの形式は、従来のTCPのDNSと同じです。
[*1] Googleが2013年に公開した、汎用の通信プロトコルです。TLSで実現していた通信路の暗号化など、TCPに追加されたさまざまな機能が標準でサポートされています。Googleの公開後にIETFで標準化作業が進められ、RFC8999～9002として発行されました。
——————
4. 付録AにRFCを追加
p.308 DNS関連の表に追加
RFC 9250 | 2022年5月 | DNS over QUICの仕様 | 14章03
p.309 DNSSEC関連の表に追加
RFC 9364 | 2023年2月 | DNSSECのRFCをまとめて紹介し、単一の参照先を提供 | 13章
