マルチキャストDNS
コンピュータネットワークにおいて、マルチキャストDNS(mDNS) はローカルネームサーバーの存在しない小さなネットワーク内でホスト名からIPアドレスを解決するプロトコルである。Zeroconfサービスであり、基本的にユニキャストのDomain Name System (DNS) と同じプログラミングインターフェース、パケットフォーマット、意味論をもつ。Stuart Cheshire (英語版)はmDNSをスタンドアロンプロトコルとして設計したが、標準的なDNSサーバーと協調して動作することもできる[1] 。
RFC 6762として公開されたmDNSプロトコルはIPマルチキャストUDPパケットを用いたもので、AppleのBonjourやオープンソースのAvahiとして実装されており、Avahiは多くのLinuxディストリビューションに同梱されている。Windows 10でも実装されており、これは当初ネットワークプリンタの検出にのみ使用できたが[2] 、後にホスト名の解決も可能になった。
mDNSはRFC 6763で別に定義されたZeroconf技術であるDNS-SD (DNS based Service Discovery)と併せて動作させることが可能である[3] 。
概要
[編集 ]ホスト名を解決するとき、mDNSクライアントはIPマルチキャストクエリメッセージを送信し、そのホスト名を自分のものとしているホストに呼びかける。その後対象の機器は自身のIPアドレスを含むメッセージをマルチキャストする。サブネット内にいるすべての機器はこの情報を基に自身のmDNSキャッシュを更新できる。この情報はTime to Live (TTL) をゼロにした応答パケットを送ることで任意のホストが破棄できる。
デフォルトでは、mDNSは.local (英語版)トップレベルドメインで終わるホスト名のみを解決する。これはmDNSを実装していないが従来のユニキャストDNSサーバーで解決できるホストが.localドメインに含まれている際に問題となりうる。そのような衝突を解決するにはmDNSが衝突を回避するようネットワーク設定を変更する必要がある。
パケット構造
[編集 ]mDNSメッセージは以下のアドレスに送信されるマルチキャストUDPパケットである。
- IPv4アドレス 224.0.0.251 または IPv6アドレス ff02::fb
- UDPポート 5353
- イーサネットフレームを使用する場合、標準IPマルチキャストMACアドレス 01:00:5E:00:00:FB (IPv4の場合) または 33:33:00:00:00:FB (IPv6の場合)
ペイロードの構造はユニキャストDNSパケットフォーマットを基にしており、ヘッダーとデータの2部からなる[4] 。
ヘッダーはユニキャストDNSと同一であり、クエリ、応答、権威DNSサーバー、追加レコードのようなデータ部のサブセクションも同じである。各サブセクションのレコード数はヘッダーの対応するCOUNTフィールドの値と一致する。
クエリ
[編集 ]クエリセクションのレコードはユニキャストDNSからわずかに変更されており、1ビットのUNICAST-RESPONSEフィールドが追加されている。[1]
| フィールド | 説明 | 長さ ビット |
|---|---|---|
| QNAME | クエリに関するノード名 | 可変 |
| QTYPE | クエリのタイプ、つまりレスポンスが返すべきリソースレコードのタイプ。 | 16 |
| UNICAST-RESPONSE | ユニキャスト応答が望まれることを示すブール値のフラグ | 1 |
| QCLASS | クラスコード。インターネットとIPネットワークでは"IN"に対応する1 | 15 |
ユニキャストDNSの場合と同じように、QNAMEフィールドはラベルと呼ばれる長さと値からなる一連のサブフィールドからなる。各ラベルは完全修飾ドメイン名 (FQDN) のドットで分けられた部分文字列を表現している。 リストはDNSの"root"を表現するヌルバイトで終了する。
UNICAST−RESPONSEフィールドは不必要なブロードキャストを最小化するために使われる。このビットがセットされている場合、応答者はネットワーク全体に応答をブロードキャストする代わりに、問い合わせたノードに対してユニキャスト応答を直接送ることが望ましい (SHOULD)。
QCLASSフィールドはユニキャストDNSのものと同じである。
リソースレコード
[編集 ]応答、権威DNSサーバー、追加レコードセクション内のすべてのレコードは同じフォーマットを持ち、まとめてリソースレコード (RR) と呼ばれる。
リソースレコードもユニキャストDNSのものからわずかに変更されている。
| フィールド | 説明 | 長さ ビット |
|---|---|---|
| RRNAME | クエリに関するノード名 | 可変 |
| RRTYPE | リソースレコードのタイプ | 16 |
| CACHE-FLUSH | 期限切れのキャッシュされたレコードを破棄すべきかを示すブール値のフラグ | 1 |
| RRCLASS | クラスコード。インターネットとIPネットワークでは"IN"に対応する1 | 15 |
| TTL | RRをキャッシュすべき時間 (秒) | 32 |
| RDLENGTH | RDATAフィールドの長さ (オクテット) の整数表現 | 16 |
| RDATA | リソースデータ。RRTYPEによって構造は異なる | 可変 |
CACHE-FLUSHビットはそのRRNAMEとRRTYPEに対応するキャッシュエントリをこのレコードで追記でなく上書きすべきであることを近隣ノードに指示する。
RDATAのフォーマットはユニキャストDNSの対応物と同じである。ただしmDNSの一般的な使用場面であるDNS Service Discovery (英語版)はフォーマットをわずかに (特にTXTレコードを) 変更している。
関連項目
[編集 ]- Bonjour Sleep Proxy (英語版)
- Link-Local Multicast Name Resolution (英語版) (LLMNR)
- Name Service Switch (NSS)
脚注
[編集 ]出典
[編集 ]- ^ a b Multicast DNS (英語). Internet Engineering Task Force (IETF). doi:10.17487/RFC6762 . RFC 6762。
- ^ mDNS and DNS‐SD slowly making their way into Windows 10, Ctrl blog, https://ctrl.blog/entry/windows-mdns-dnssd 2017年8月30日閲覧。
- ^ DNS Service Discovery (英語). Internet Engineering Task Force (IETF). doi:10.17487/RFC6763 . RFC 6763。
- ^ P. Mockapetris (November 1987). DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION (英語). Network Working Group, IETF. doi:10.17487/RFC1035 . RFC 1035。
外部リンク
[編集 ]- Multicast DNS - mDNSの設計者であるStuart Cheshireが運営する情報サイト
- LLMNR, Multicast DNS and names on your LAN