DNSプロトコルの進化 2020
(IETFでの標準化)
藤原 和典
fujiwara@jprs.co.jp
株式会社日本レジストリサービス (JPRS)Internet Week 2020, DNS Day
2020年11月27日
Copyright © 2020 Japan Registry Services Co., Ltd.

1

自己紹介
• 氏名:
藤原和典
• 個人ページ: http://member.wide.ad.jp/~fujiwara/• 勤務先: 株式会社日本レジストリサービス (JPRS)
技術研究部• 業務内容:DNS関連の研究・開発 (具体的には標準化、試作、論文)– Internet Week プログラム委員 (2016～)• IETFでの活動 (2004~)– ENUMプロトコル: RFC 5483 6116 (2004~2011)– メールアドレスの国際化 :RFC 5504 5825 6856 6857 (2005~2013)– DNS関連の問題提起など• RFC 7719, 8499: DNS Terminology → rfc8499bis• RFC 8198: DNSSECを用いた名前解決の性能向上• draft-ietf-dnsop-avoid-fragmentation: DNSでIP断片化を避ける提案• draft-fujiwara-dnsop-delegation-information-signer: 委任情報への署名提案
Copyright © 2020 Japan Registry Services Co., Ltd.

2

IANA: DNS Parameters: RR Types (1)https://www.iana.org/assignments/dnsparameters/dns-parameters.xhtml

TYPE
A
NS
CNAME
SOA
PTR
MX
TXT
AAAA
SRV
NAPTR
CERT
DNAME

Value
Meaning
1 a host address
2 an authoritative name server
5 the canonical name for an alias
6 marks the start of a zone of authority
12 a domain name pointer15 mail exchange
16 text strings
28 IP6 Address
33 Server Selection
35 Naming Authority Pointer37 CERT
39 DNAME

Copyright © 2020 Japan Registry Services Co., Ltd.

概要
DNS
DNS
DNS
DNS
DNS
DNS
DNS
IPv6
DNS SRV[RFC3403][RFC4398][RFC6672]

3

IANA: DNS Parameters: RR Types (2)
TYPE

Value
Meaning
OPT
41 OPTDS
43 Delegation Signer
SSHFP
44 SSH Key Fingerprint
IPSECKEY
45 IPSECKEY
RRSIG
46 RRSIG
NSEC
47 NSEC
DNSKEY48 DNSKEY
DHCID
49 DHCID
NSEC350 NSEC3
NSEC3PARAM 51 NSEC3PARAM概要EDNS
DNSSEC[RFC4255][RFC4025]
DNSSECDNSSECDNSSEC[RFC4701]
DNSSECDNSSEC

SSHFP
man ssh によるとssh-keygen -r host.example.com.
でSSHFPリソースレコードを作ってくれるクライアントでの検証は、ssh -o "VerifyHostKeyDNS ask"
(DNSSECで守る方がいいデータ)
Copyright © 2020 Japan Registry Services Co., Ltd.

4

TYPE
TLSA
SMIMEA
CDS

Value
Meaning
概要
Registration
52 TLSADANE
53 S/MIME cert association DANE
2015/12/1
59 Child DS
DNSSEC自動化 2011/6/6
DNSKEY(s) the Child wants
60
DNSSEC自動化 2014/6/16
reflected in DS
OPENPGPKEY 61 OpenPGP Key
DANE
2014/8/12
CSYNC
62 Child-To-Parent
DNSSEＣ自動化 2015/1/27
message digest for DNS
63
最近の拡張提案 2018/12/12
zone
64 Service Binding
最近の拡張提案 2020/6/30
65 HTTPS Binding
最近の拡張提案 2020/6/30
CDNSKEY

ZONEMD
SVCB
HTTPS

IANA: DNS Parameters: RR Types (3)
TYPE
Value
Meaning
概要
TLSA
52
TLSA
DANE
SMIMEA
53
S/MIME cert association
DANE
CDS
59
Child DSDNSSEC自動化
CDNSKEY60
DNSKEY(s) the Child wants reflected in DS DNSSEC自動化
OPENPGPKEY 61
OpenPGP Key
DANE
CSYNC
62
Child-To-Parent Synchronization
DNSSEＣ自動化
ZONEMD63
message digest for DNS zone
最近の拡張提案
SVCB
64
Service Binding
最近の拡張提案
HTTPS
65
HTTPS Binding
最近の拡張提案
SPF
99
廃止[RFC7208]
CAA
257
Certification Authority Restriction[RFC8659]

Copyright © 2020 Japan Registry Services Co., Ltd.

Registration Date
2015/12/1
2011/6/6
2014/6/16
2014/8/12
2015/1/27
2018/12/12
2020/6/30
2020/6/30
2014/4 廃止
2011/4/7

5

本日の概要• Internet Week 2016 DNS DAYにて最近のIETF事情を紹介し、2017年にDNS Privacy, 2019年にDNSプロトコルの変化を紹介した。
• 本日は、これまで紹介していないことを中心に、2016年からの変化をまとめる。
• IETFの概要• DNSを取り扱っているワーキンググループ• 新しい標準• 新しい利用例 (Webサーバ、ブラウザでの使用)• Multicast DNSの拡張
Copyright © 2020 Japan Registry Services Co., Ltd.

6

IETF
• IETF (Internet Engineering Task Force)– インターネット標準(RFCなど)を決める団体• IETFの活動への参加(貢献)– ドキュメントを書くこと– メーリングリストにメールを書くこと– 年三回開催される会議に参加することなど: 2020年はすべて遠隔– だれでも参加可能• 会議への参加費は必要• メーリングリストへの参加、標準化提案には費用はかからない– 原則として個人での参加• IETFの活動は公開原則– メーリングリスト、会議の議事録、音声
Copyright © 2020 Japan Registry Services Co., Ltd.

7

DNS関連WG• dnsext (DNS Extensions) WG– DNSプロトコルの拡張– 2013年7月に完了、プロトコル拡張機能をdnsopへ• dnsop (DNS Operations) WG– DNS運用ガイドライン作成– DNSプロトコル拡張を作る機能– 1999年以前に設立• dprive (DNS Privacte Exchange)
WG– DNS通信路を暗号化– 2014年10月設立– 2016年5月にRFC 7858 DNS over TLS(DoT) を発行

• dane (DNS-based Authentication of Named Entities) WG• dnssd (Extensions for Scalable DNS Service Discovery) WG– .localを使用するMulticast DNS (RFC6762), DNS-SD (RFC 6763)の拡張– 2013年10月設立• doh (DNS over HTTPS) WG– 2017年10月設立 DoHの標準化を目的– 2018年10月にRFC 8484: DNS Queries
over HTTPS (DoH)発行– 2020年3月完了、続く議論をadd WGへ• add (Adaptive DNS Discovery) WG– DNSクライアントがDoT, DoHサーバを見つける方法を定義する– 2020年3月設立

赤字は完了したWG 青字は変化– DNS(SEC)にTLSの証明書を載せる– 2010年10月設立、2017年3月完了
Copyright © 2020 Japan Registry Services Co., Ltd.

8

dnsop (DNS Operations ) WG
• DNS運用ガイドラインを作るWG– DNSプロトコル拡張を作る機能– dprive WGはdnsop WGから独立– 唯一のDNSそのものを扱うWGとして、ドメイン名全般、DNSプロトコルの話題に関して、IESG, IABなどから意見を求められる– 多数の提案を取り扱っている– RFCを着実に発行中• 2016年1月～2020年11月で28本/5年• RFC Editor queueに1本• IESG対応中1本• WG draft 16本• 最近のdnsop WGでのテーマ– 標準の明確化と修正• DNS用語• クエリ名情報漏洩の最小化• DNSSECアルゴリズム• Serve stale– 新しい要求• ブラウザがHTTPSサーバを見つけるた
めの、新しいリソースレコード (SVCB,HTTPS)– セキュリティ対策• ゾーン情報のダイジェスト• 委任情報確認の厳格化• Delegation only
• DNS Cookies• IP断片化回避

Copyright © 2020 Japan Registry Services Co., Ltd.

9

dnsop WG: 2016～2020年のRFC (1/2)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

RFC 7766, 2016/3/3: DNS Transport over TCP - Implementation Requirements
RFC 7816, 2016/3/22: DNS Query Name Minimisation to Improve Privacy
RFC 7828, 2016/4/6: The edns-tcp-keepalive EDNS0 Option
RFC 7871, 2016/5/20: Client Subnet in DNS Queries
RFC 7873, 2016/5/27: Domain Name System (DNS) Cookies
RFC 7901, 2016/6/21: CHAIN Query Requests in DNS
RFC 8020, 2016/11/8:NXDOMAIN: There Really Is Nothing Underneath
RFC 8027, 2016/11/28: DNSSEC Roadblock Avoidance
RFC 8078, 2017/3/10: Managing DS Records from the Parent via CDS/CDNSKEY
RFC 8109, 2017/3/15: Initializing a DNS Resolver with Priming Queries
RFC 8145, 2017/4/15: Signaling Trust Anchor Knowledge in DNS Security Extensions(DNSSEC)
RFC 8198, 2017/7/25: Aggressive Use of DNSSEC-Validated Cache
RFC 8244, 2017/10/19: Special-Use Domain Names Problem Statement
RFC 8501, 2018/11/28: Reverse DNS in IPv6 for Internet Service Providers
RFC 8509, 2018/12/18: A Root Key Trust Anchor Sentinel for DNSSEC
Copyright © 2020 Japan Registry Services Co., Ltd.

10

dnsop WG: 2016～2020年のRFC (2/2)• RFC 8482, 2019/1/10: Providing Minimal-Sized Responses to DNS Queries That Have
QTYPE=ANY• RFC 8490, 2019/3/15: DNS Stateful Operations• RFC 8499, 2019/1/2: DNS Terminology (RFC 7719の更新)• RFC 8552, 2019/3/20 Scoped Interpretation of DNS Resource Records through "Underscored"
Naming of Attribute Leaves• RFC 8553, 2019/3/20: DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node
Names
• RFC 8618, 2019/9/3: Compacted-DNS (C-DNS): A Format for DNS Packet Capture• RFC 8624, 2019/6/11: Algorithm Implementation Requirements and Usage Guidance for
DNSSEC• RFC 8749, 2020/3/27: Moving DNSSEC Lookaside Validation (DLV) to Historic Status• RFC 8767, 2020/3/31: Serving Stale Data to Improve DNS Resiliency• RFC 8806, 2020/6/18: Running a Root Server Local to a Resolver (RFC7706の更新)• RFC 8901, 2020/9/24: Multi-Signer DNSSEC Models• RFC 8906, 2020/9/22: A Common Operational Problem in DNS Servers: Failure to
Communicate• RFC 8914, 2020/10/23: Extended DNS Errors
Copyright © 2020 Japan Registry Services Co., Ltd.

11

RFC 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC• 現在 (2019/6/11) 推奨されるDNSSECアルゴリズム– 署名側と検証側それぞれで規定 (アルゴリズム、DS Digest Type)– 署名、検証でMUST (実装必須 → おすすめ)• 8(RSASHA256), 13(ECDSAP256SHA256), Digest Type 2 (SHA-256)– 署名、検証でRecommended (実装ほぼ必須 ): 15(ED25519)– 署名MAY、検証Recommended (普及まだとか、オーバースペック)• 14(ECDSAP384SHA384), 16(ED448), Digest Type 4 (SHA-384)– 署名Not Recommended、検証MUST (今後使うべきでないもの)• 5(RSASHA1), 7(RSASHA1-NSEC3-SHA1), 10(RSASHA512)– 署名MUST NOT, 検証MUST (いまある設定は有効): Digest Type 1 (SHA-1)– 署名、検証 MUST NOT (使用禁止):• 1(RSAMD5), 3(DSA), 6(DSA-NSEC3-SHA1)– 署名MUST NOT、検証MAY (ロシアの古い標準規格なのでもう不要)• 12(ECC GOST), Digest Type 3(GOST R34.11-94)
Copyright © 2020 Japan Registry Services Co., Ltd.

12

RFC 8767: Serving Stale Data to Improve DNS Resiliency• RFC 8767, 2020/3/31発行– DNS耐性向上のための古いデータの提供– DoS攻撃などで権威サーバからの応答が得られない場合に、フル
サービスリゾルバでキャッシュ有効期限を過ぎたデータを提供する– キャッシュから消えて最大7日までのデータをTTL 30で応答する– RFC 1034, 1035のTTLの定義、RFC 2181のTTL値の解釈を変更• すでに実装が進んでいる– BIND 9.12以降: stale-answer-enable yes;
– Unbound 1.8以降: serve-expired: yes– Knot resolver: modules = { 'serve_stale < cache' }Copyright © 2020 Japan Registry Services Co., Ltd.

13

ZONEMD RR• draft-ietf-dnsop-dns-zone-digest で提案、11/19 IESG通過、RFC Editorへ• ゾーン全体の情報のハッシュ値を保持するZONEMD RRを定義– domain TTL IN ZONEMD serial scheme hash_algorithm digest– scheme: 1=SIMPLEのみ定義 Hash_algorithm: 1=SHA384, 2=SHA512• 例: root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 (FEBE…)• ZONEMDの作成– 既存のゾーン頂点のZONEMD RRを削除– 空のZONEMD RR追加 (NSEC, NSEC3 type bitmapのため)– (DNSSEC署名)– DNSSECの順序でゾーン内のリソースレコードを並べかえ– 追加したZONEMD以外の、すべてのリソースレコードを連結して、ダイジェストを計算– ZONEMD RRを作成 (ZONEMD RRのRRSIGを作成)• 使用イメージ– DNSSEC署名時にZONEごとにZONEMD追加– DNSSEC非署名の場合は、プライマリでゾーン情報ロード時に作成– ゾーン転送を受け取ったセカンダリサーバでZONEMDをみて確認
Copyright © 2020 Japan Registry Services Co., Ltd.

14

SVCB, HTTPS RR• draft-ietf-dnsop-svcb-https で提案、議論中– Service binding and parameter specification via the DNS (DNS SVCB and HTTPSRRs)• HTTPSなどの接続先情報 (ホスト名、ポート、証明書情報)を保持するSVCB(Service Binding)、HTTPSリソースレコードを定義する• 目的– ドメイン名に対するサービスの複数のエンドポイント情報を保持– ドメイン名に複数のSVCB/HTTPSを書いて複数のCDNに対応• SVCB/HTTPSごとに異なるCDNサーバ名、サーバ証明書情報– ゾーン頂点の別名 (SOA/NSがあるゾーン頂点にはCNAME書けない)– Encrypted Server Name Indication(ESNI)で使用する Encrypted ClientHello の key を
DNSから得たい– 443ではないポート番号の使用– HSTSを示す機能 (HTTPS強制)– QUICでの接続の強制– SVC RRの負荷分散と同じ機能の提供
Copyright © 2020 Japan Registry Services Co., Ltd.

15

SVCB, HTTPS RR (2)• オーナー名 TTL IN SVCB/HTTPS SvcPriority TargetName SvcParams– SvcPriorityは16ビットの優先度 (0のときはAliasMode)– TargetNameはドメイン名で、CNAMEのような別名を示す (.の場合はオーナー名)– SvcParams はRDATAの残り、 (2バイトのキー、2バイトの長さと、バイト列)の列• port: ポート番号: 接続先ポート番号指定• alpn: TLSのApplication-Layer Protocol Negotiation 指定 h3=QUIC, h2=HTTP/2• echconfig: ESNIで使用するEncrypted ClientHelloの設定データ• ipv4hint, ipv6hint: TargetNameの指すIPv4,IPv6アドレス (名前解決を省略)– 汎用のSVCBと、HTTPSに特化したHTTPS RR• SVCBのオーナー名は _port._protocol.ドメイン名 (SRVと同じ)• HTTPS RRのオーナー名はURLのドメイン名部• domainname HTTPS は _443._tcp.domainname SVCB に相当するが、HTTPSを使うこと• 使用例– simple.example. 7200 IN HTTPS 1 . alpn=h3
QUIC対応(HTTP/3)– @ 7200 IN HTTPS 0 pool.svc.example.
ゾーン頂点の別名– pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 echconfig=“123...” QUIC/H2+ESNIHTTPS 2 .
alpn=h2 echconfig=“abc...”HTTP/2のみ+ESNI
Copyright © 2020 Japan Registry Services Co., Ltd.

16

SVCB, HTTPS RR (3)• DNSサーバの変更 (権威サーバ、フルリゾルバ両方)– SVCB, HTTPS の TargetName のA, AAAAを知っていたら、Additional
sectionに追加する (MXと同じ、メールサーバのA/AAAAを追加する)• クライアントの動作 (HTTPSの場合)
1. クライアントは、webサーバのドメイン名の HTTPS, A, AAAA の問い合わせを同時に送る2. HTTPS RR応答がAliasModeなら、TargetNameで1.を行う
3. HTTPS RR応答がServiceModeなら対応するサーバにHTTPS接続•

ALPN, ECHConfigなどを使用 (場合によってはQUIC)

4. HTTPS RR応答がなければA, AAAA応答のアドレスにHTTPS接続• 著者所属Google, Akamai, 謝辞に Apple, Mozilla, Cloudflare の人達– Browser開発組織、CDNの人たちが議論に参加しているため、標準化が進むと(DoHのように) すぐにブラウザとCDNでの実装が進む可能性あり
Copyright © 2020 Japan Registry Services Co., Ltd.

17

Extended DNS Error (EDE)• RFC8914, 2020/10/23• 従来:DNSヘッダのRCODE 4ビット
0=NoError, 2=ServFail, 3=NameError• EDNS0ヘッダ中の8ビットのExtended RCODE (既存RCODEの上位8ビット)0– 使いにくかった: 16=BADVERS

5• EDNS0にExtended DNS Errorオプ
ションを追加6

DNSSEC Bogus

18 Phohibited

7

Signature Expired19

8

Signature Not Yet
Valid

20 Not Authoritative

9

DNSKEY Missing

21 Not Supported

10

RRSIGs Missing

22

11
12

No Zone Key Bit Set
NSEC Missing– RCODEでエラーを示し、詳細をEDE• フォーマット
16ビット: Option-Code 15
16ビット: オプション長
16ビット: INFO-CODE(0から24が定義)
可変長: EXTRA-TEXT: UTF8文字列• 近いうちにDNSサーバなどに入る見込み(BIND 9 gitlab mainに若干ある)

1
2

3
4

Other Error
Unsupported DNSSEC
13 Cached Error
Algorithm
Unsupported DS
14 Not Ready
Digest Type
Stale Answer
15 Blocked
Forged Answer
16 CensoredDNSSEC
17 Filtered
Indeterminate

Copyright © 2020 Japan Registry Services Co., Ltd.

Stale NXDomain
Answer

No Reachable
Authority
23 Network Error
24 Invalid Data18

dprive (DNS Privacate Exchange) WG• スタブリゾルバとフルサービスリゾル
バの間の通信を暗号化• 2014年10月に設立し、ほぼ完了• RFC 7858 (DNS over TLS)が発行され、使える状態になった• IETF 97 (2016/11)にて、フルサービ
スリゾルバから権威サーバ間の通信
暗号化の検討を開始することが提案されたが IETF 109(2020/11)でも、要求条件の議論を継続– 2016/5/17発行– 詳細は本日のDoT/DoH入門参照

暗号化
の検討

フルリゾルバ• DNS over DTLSは使われていない(キャッシュ)• DNS over QUICは継続
port 853/TCP/TLS• ゾーン転送をDNS over TLSで行う拡張の議論は進捗している
標準化完了1 Unbound– DNS Zone Transfer-over-TLS– サーバ証明書でサーバ名確認など

実装あり

8

2
3
4
5
7

getdns api

Copyright © 2020 Japan Registry Services Co., Ltd.

スタブリゾルバ

6

ルート階層
Root

TLD
JP

NET COM

example.jp

nic.ad.jp

組織の階層
権威DNSサーバ19

dane (DNS-based Authentication of Named Entities) WG• DNS(SEC)にTLSの証明書をのせるWG• 2010年10月設立、標準化を完了し、2017年5月に完了– TLSA: RFC 6698, 2012年8月発行、 サーバ証明書を載せるRR_port._proto.DOMAIN IN TLSA CertUsage Selector MatchingType
Certificate_Association_Data• CertUsage: 0..CA証明書, 1..エンドエンティティ証明書(CAにより発行), 2..トラストア
ンカー, 3..自己署名などのエンドエンティティ証明書• Selector: 0.. Full certificate, 1.. SubjectPublicKeyInfo• MatchingType: 0..証明書そのもの, 1..SHA-256 hash, 2..SHA-512 hash
• Certificate_association_data: 証明書そのものかhash値、16進表記– 例: www.isc.orgのtcpポート443のサーバ証明書問い合わせ% dig _443._tcp.www.isc.org TLSA
443._tcp.www.isc.org. 7185 IN
TLSA 3 0 1
7C31F5B6D577A06448C67BAE690E1A3905CA34146BDA86C664EB26
90 710D085C
Copyright © 2020 Japan Registry Services Co., Ltd.

20

dane WG (2)• OpenPGPKEY: RFC 7929, 2016年8月発行, Experimental– hex(先頭28バイト(sha256(localpart)))._openpgpkey.domain IN
OPENPGPKEY 証明書– 例: hugh@example.com のOpenPGP証明書をのせる場合– c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c1afd6._openpgp
key.example.com IN OPENPGPKEY mQCNAzIG[...]– PGP Key serverではなく、メールアドレスに対応するDNSクエリでOpenPGP証明書を得る– メールアドレスは、大文字小文字どちらでも許容されるため、localpartを一位に決めにくく、議論がまとまらず、Experimental (実験的)プロトコルとして標準化された• SMIMEA: RFC 8162, 2017年5月発行, Experimental– S/MIMEクライアント証明書をのせるもの– hex(先頭28バイト(sha256(localpart)))._smimecert.domain IN SMIMEA (TLSAと同じ形式)• 2017年5月に完了
Copyright © 2020 Japan Registry Services Co., Ltd.

21

dnssd (Extensions for Scalable DNS Service Discovery) WG• DNSを使ったサービスディスカ
バリを作るWG– Multicast DNS (RFC 6762,
mDNS)とDNS-SD (RFC 6763)をベースに、複数ネットワークセグメ
ントに対応したものを標準化– 主にApple社のBonjourとAvahiとして実装されているプロトコルをIETFで標準化したプロトコルにするために拡張を行っている• Multicast DNS (RFC 6762)– link-localでのDNS-likeな名前解決機構• DNS-SD (RFC 6763)– サービスディスカバリ

Copyright © 2020 Japan Registry Services Co., Ltd.

22

dnssd: Multicast DNS (RFC 6762)• link-localでのDNS-likeな名前解決
機構• 各ノードがラベル一つの名前を持ち、.local TLDを用いることでDNSと共存– MyComputer.local– スペースや' UTF-8も許容• Apple社のOSや、Avahiが対応– Avahi - Service Discovery forLinux using mDNS/DNS-SD -compatible with Bonjour• 各ノードは、multicastでクエリ"Smith's Computer.local" AAAAをクエリ– 224.0.0.251. ff02::fb port 5353 UDP– パケットフォーマットはDNSと同じ• 各ノードは、自分のホスト名宛クエリを受け取ると、ホスト名とＩＰアドレスの対応を応答• 169.254.0.0/16, fe80::/10の逆引き

multicast
自分のアドレス
を応答"Smith's Computer.local""MyComputer.local"
fe80::2222
fe80::1111

Copyright © 2020 Japan Registry Services Co., Ltd.

23

dnssd: DNS-Based Service Discovery (RFC 6763)• 構造化されたサービス名– <Instance>.<Service>.<Domain>– SRVと同じ形式 (_sip._udp.domain)– ホスト名と違い、スペースやUTF-8許可• サービスの列挙 (enumeration)– サービス名に PTRを書き、サービスを列挙– _http._tcp.dns-sd.org PTR¥032*¥032eBay,¥032online¥032auctions.
_http._tcp.dns-sd.org.

• サービスへのアクセス– SRV RRを使用– _http._tcp.dns-sd.org. SRV 0 100 80
www.dns-sd.org.

• Well known service– b._dns-sd._udp.domain PTR
ブラウズ: ドメイン名にあるサービスを列挙– db._dns_sd._udp.domain PTR
ブラウズすべき既定ドメイン名– r._dns_sd._udp.domain PTR
DNSSDの登録サービス (Dynamic Update)– dr._dns_sd._udp.domain PTR
登録サービスの規定ドメイン名– lb._dns_sd._udp.domain PTR
legacy browsingドメイン名: ???

• Multicast DNSでのDNS-SD– domain = .local– _ipp._tcp.local PTRクエリに対して、同じリンクにある別の名前を持つ複数のプリンタが応答• _ipp._tcp.local PTR color._ipp._tcp.local• _ipp._tcp.local PTR mono._ipp._tcp.local– User Interfaceでcolorを選ぶ、– color._ipp._tcp.local 0 0 49152 SRVcolor.local.
– color.local IN A 192.0.2.11– 192.0.2.11 ポート 49152 に接続

Copyright © 2020 Japan Registry Services Co., Ltd.

24

dnssd: コアプロトコル• RFC 8766, 2020/6/22発行– Discovery Proxy for Multicast
DNS-Based Service Discovery– mDNSとDNSのHybrid proxy– リンクごとにドメイン名を設定、ルータなどでproxyを動かす– ブラウズ設定、リンクのドメイン名の設定を管理者が行う• b._dns-sd._udp.example.com
PTR link1.example.com• _link1.example.com でHybrid Proxy

link1.example.com

HybridProxy

1. 通常のDNSから⇦の問い合わせ• 例: link1.example.com• Proxy link1.local ⇔1. プリンタを使いたい
link1.example.com
X Printer
2. ブラウズ:• インターネットから
b._dns-sd._udp.example.com_ipp._tcp.local
PTR<name>.link1.example.com PTR→ link1がある"X
Printer._ipp._tcp.local"
クエリを受け取ると、<name>.local
3. _ipp._tcp.link1.example.com"X Printer._ipp._tcp.local
PTRクエリをlink1でmDNSで送り、を調べる
SRV ….
4. Proxyが_ipp._tcp.localクエリに応答を書き換えて変換して問い合わせ<name>.link1.example.com応答と5. プリンタ情報を得られる
して返す
Copyright © 2020 Japan Registry Services Co., Ltd.

25

dnssd: 追加プロトコル• RFC 8766 Discovery Proxyはキャッシ
ュを持ち、担当するゾーン情報を管理– 例では link1.example.comゾーン– Multicast DNSの応答のキャッシュデータ• RFC 8764, 2020/6/22発行– Apple社のDNS Long-Lived-Queries– 2005-2020にBonjourで実装・使用したもの– RFC 8765で置き換える• RFC 8765, 2020/6/22発行• RFC 8490, 2019/3/15発行– dnsop WGで標準化– DNS Stateful Operations– DNSの全く新しい接続方式で、クライアントはサーバとつなぎっぱなしで新しいDSOメッセージをやり取り– 新しいOpcode 6 (0 Query, 4 Notify, 5 Update)

link1.example.com

Discovery
Proxy

1. 通常のDNSから⇦の問い合わせ– DNS Push Notifications: Discovery
Proxyの管理するゾーンの変更を通知
1. プリンタを使いたい– クライアントはDiscovery ProxyのDNSサー
X Printer
バにつなぎっぱなしにしておくと、Discovery
2. ブラウズ:Proxyが管理するゾーン情報が変化する度
b._dns-sd._udp.example.com PTR_ipp._tcp.local
PTRにクライアントに変更点を送る"X Printer._ipp._tcp.local" → link1がある– RFC 8490使用
3. _ipp._tcp.link1.example.com PTR• Apple社はBonjourのプロトコルをIETFのプロトコルとして標準化"X Printer._ipp._tcp.local
SRV ….

– 著者はAppleのS. Cheshire氏 (mDNS,DNSSD)
Copyright © 2020 Japan Registry Services Co., Ltd.

を調べる
4. Proxyが_ipp._tcp.local PTR
クエリに変換して問い合わせ
5. プリンタ情報を得られる

26

dnssd: 残務• 提案されているプロトコル– draft-ietf-dnssd-mdns-relay (著者はAppleの人たち)• Discovery Proxyの機能を離れたセグメントにリレーするプロトコル (軽量化Discovery Proxy)– draft-ietf-dnssd-srp: DNSSDサービス登録プロトコル (著者はAppleの人たち)• Discovery ProxyのDNSサーバにDNS Dynamic Updateで情報を登録する• Multicast DNSに対応していなくても、Discovery ProxyがMulticast DNSに答えてくれる• dnssdプライバシーの検討– Multicast DNS (RFC 6762) では、マルチキャストが届く範囲(同じイーサネット、
同じWiFiなど)では誰からでも問い合わせ、応答が見える– 自分のデバイスもdnssdで扱いたいけど、他人からは見られたくないという要求– RFC 8882, 2020/9/10発行: DNSSDプライバシーとセキュリティの要求仕様– 見られたくないクライアントに暗証番号を指定するなどの提案はあったが難しいので議論が止まっている
Copyright © 2020 Japan Registry Services Co., Ltd.

27

最近の提案 (宣伝)

Copyright © 2020 Japan Registry Services Co., Ltd.

28

draft-ietf-dnsop-avoid-fragmentation• 動機– IP Fragmentationを使ったキャッシュ汚染攻撃が話題になった– EDNS0でIP Fragmentationを使って大きなパケットを返せるようにしたことが間違いだった• EDNS0 RFC著者のPaul Vixie氏と共著 (EDNS0ではIP Fragmentationを許容して大きなDNSデータをUDPで扱えるようにした)• 提案– UDP応答ではIP_DONTFRAG, IPV6_DONTFRAGオプションをつけて応答を送る → フラグメントしそうなときはエラー– 問い合わせを送る側、応答する側双方で、Path MTUを意識して、フラグメント
しない範囲でDNS応答をUDPで送る– 問い合わせを送る側は EDNS0 での UDPサイズをPath MTUからIPヘッダ、
UDPヘッダを引いたサイズ以内とする• DNS Flag Day のひとたちは、1232 を推奨している• 現状: dnsop WGで、かなり好意的に扱われている
Copyright © 2020 Japan Registry Services Co., Ltd.

29

draft-fujiwara-dnsop-delegation-information-signer• 概要: DNSSECで、委任情報に署名を追加する提案• 動機– DNSSECでは、委任情報は署名されない (攻撃されても防御できない)– TLDなどでは、顧客から委任情報を受け取る (ネームサーバ情報とホスト情報とDS)が署名対象はDSだけ• 提案– 委任情報の親側のNSと、内部名(in-domain)グルーA/AAAAは一意に決まるので、DSを転用してそこにハッシュ値を入れる– SHA-256 hash( parent side NS RRSet | in-domain glue records)– NS RRSet, in-domain glue recordsはDNSSEC canonical orderで並べる– 例: example.jp IN DS 0 0 XX _SHA256_hash(NS|glue)– DS RRSetとして署名– DNSSEC ValidatorがDigest type XXを受け取ったら委任情報を検証し、一致しなければ捨てる
Copyright © 2020 Japan Registry Services Co., Ltd.

30

An example of DiS record generation• dig +norec +dnssec @a.dns.jp wide.ad.jp
1. Remove old DiS;; AUTHORITY SECTION:
2. Generate new DiS
wide.ad.jp. 86400 IN NS ns.tokyo.wide.ad.jp.
2.1 Collect referral NS RRSet and in-domain glue
wide.ad.jp. 86400 IN NS ns-wide.wide.ad.jp.
2.2 Reorder NS RRSet and in-domain glue as DNSSEC
canonical order [RFC 4034]
wide.ad.jp. 86400 IN NS mango.itojun.org.
wide.ad.jp. 7200 IN DS 32584 8 2 1D7EEF8BC...2.3 Calculate SHA-256 hashSHA-256(
wide.ad.jp. 7200 IN RRSIG DS …
wide.ad.jp. 86400 IN NS ns.tokyo.wide.ad.jp.
;; ADDITIONAL SECTION:
wide.ad.jp. 86400 IN NS ns-wide.wide.ad.jp.
ns.tokyo.wide.ad.jp. 86400 IN AAAA
2001:200:0:1::6
wide.ad.jp. 86400 IN NS mango.itojun.org.
ns-wide.wide.ad.jp. 86400 IN AAAA
ns-wide.wide.ad.jp. 86400 IN A 203.178.136.59
2001:200:0:1::fns-wide.wide.ad.jp. 86400 IN AAAA 2001:200:0:1::fns.tokyo.wide.ad.jp. 86400 IN A 203.178.136.35 ns.tokyo.wide.ad.jp. 86400 IN A 203.178.136.35
ns-wide.wide.ad.jp. 86400 IN A 203.178.136.59 ns.tokyo.wide.ad.jp. 86400 IN AAAA 2001:200:0:1::6)
2.4 Generated DiS datawide.ad.jp 7200 IN DS 0 0 XX _SHA256_hash(NS|glue)
3. Sign DS RRSet (contains generated DiS and originalDS)draft-fujiwara-dnsop-delegation-information-signer (4)• IETF 109でいただいたコメント– なぜ、委任情報を守らなかったか？
→ DNSへの変更を最小限としたため (元dnsext WG co-chair のOlaf Kolkman氏より)– DNS関係者からは、嬉しさがわかりにくい• DNSSEC検証すれば、案内された委任先でエラーにできるため– dprive WGの人たちからは、興味を持たれた• DSを利用するアイデアは、IETF 108でのdprive WGでの提案 draftvandijk-dprive-ds-dot-signal-and-pin を参考にしたもの– 無視されたり討ち死にするつもりだったのに、時間をもらえ、コメントももらえてよかった
Copyright © 2020 Japan Registry Services Co., Ltd.

32

まとめ
• dnsop WG• dane WG– 名前解決の効率化や攻撃耐性の強化、新機能追加のための拡張が盛んに行なわれ、実装も進む– DNSソフトウェア開発者、ブラウザ
開発者、CDNなどの開発者が多数集まっている– サーバ証明書と、OpenPGP、
SMIMEの個人証明書をDNSに載せることができるようになった– 今後ブラウザやメールソフトウェア
での実装が期待される• dnssd• dprive WG– クライアントからフルリゾルバ間の通信路暗号化の標準化は完了し、すでに使用可能– 今後、フルリゾルバから権威DNS
サーバ間の暗号化に取り組む– ゾーン転送の暗号化に取り組む– Multicast DNSを複数セグメントで使用する拡張が標準化された– Apple社のOSで実装されている• IETF– 既存のプロトコルの問題や、新しい提案は歓迎される

Copyright © 2020 Japan Registry Services Co., Ltd.

33

参考• www.ietf.org → datatracker.ietf.org– IETFミーティングの資料、議事録– ワーキングループの情報• 標準化したRFCへのリンク• 議論中のdraftへのリンクや状態• メーリングリストアーカイブ• www.rfc-editor.org– RFC

Copyright © 2020 Japan Registry Services Co., Ltd.

34