ワイルドカードDNSレコード
ワイルドカードDNSレコードは、 DNSゾーン内の、存在しないドメイン名へのリクエストに一致するレコードです。ワイルドカードDNSレコードは、*ドメイン名の左端のラベル（部分）として を使用することで指定されます（例： ）*.example.com。ワイルドカードが一致する正確なルールはRFC 1034で規定されていますが、そのルールは直感的ではなく、明確に規定されていません。そのため、ワイルドカードを使用すると、実装に互換性がなくなり、予期しない結果が生じることがあります。
DNSワイルドカードの定義
ゾーン ファイル内のワイルドカード DNS レコードは次の例のようになります。
*.example.com。3600 IN MX 10 host1.example.com 。このワイルドカードDNSレコードにより、存在しない で終わるドメイン名のDNSルックアップが行われexample.com、それらのMXレコードが合成されます。つまり、 のMXレコードルックアップは、somerandomname.example.comを指すMXレコードを返しますhost1.example.com。
DNS のワイルドカードは、他のコンピュータ システムで使用される他のワイルドカード文字よりもはるかに制限されています。ワイルドカード DNS レコードは、 のように、*左端のDNS ラベルとして単一の (アスタリスク) を持ちます*.example.com。ドメイン内の他の場所にあるアスタリスクはワイルドカードとして機能しないため、 も*abc.example.comもabc.*.example.comワイルドカード DNS レコードとしては機能しません。さらに、ワイルドカードは、クエリされた種類の一致するレコードがない場合だけでなく、ドメインが存在しない場合にのみ一致します。RFC 1034 セクション 4.3.3 の検索アルゴリズムで定義されている「存在しない」の定義でさえ、他の種類のワイルドカードで予想されるケースにワイルドカードが一致しない結果になることがあります。
DNSワイルドカードの動作に関する本来の定義は、RFC 1034のセクション4.3.2および4.3.3で規定されていますが、検索アルゴリズムの特定のステップによって間接的にしか定義されておらず、その結果、ルールは直感的ではなく、明確に規定されていません。その結果、20年後、ルールを明確化するためにRFC 4592「ドメインネームシステムにおけるワイルドカードの役割」が策定されました。
RFC 1912を引用すると、「よくある間違いは、ゾーンのワイルドカード MX がゾーン内のすべてのホストに適用されると考えることです。ワイルドカード MX は、DNS にまったくリストされていないゾーン内の名前にのみ適用されます。」つまり、 にワイルドカード MX があり、 に A レコード（MX レコードはない）がある場合、の MX 要求に対する正しい応答（RFC 1034による）は「エラーなし、データなし」です。これは、 に添付された MX レコードの予想される応答とは対照的です。 *.example.comwww.example.com www.example.com*.example.com
使用例
次の例はRFC 4592セクション 2.2.1 からのもので、ワイルドカードの動作を明確にするのに役立ちます。
次のリソース レコードを持つ DNS ゾーンがあるとします。
$ORIGIN example. example. 3600 IN SOA <SOA RDATA> example. 3600 NS ns.example.com. example. 3600 NS ns.example.net. *.example. 3600 TXT "これはワイルドカードです" *.example. 3600 MX 10 host1.example. sub.*.example. 3600 TXT "これはワイルドカードではありません" host1.example. 3600 A 192.0.2.1 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.net.ドメイン名をツリー構造で見ると役に立ちます。
例 ├─ * │ └─ サブ ├─ ホスト1 │ └─ _tcp │ └─ _ssh ├─ ホスト2 │ └─ _tcp │ └─ _ssh └─ サブデル
次の応答は、ゾーン内のワイルドカードの 1 つから合成されます。
| クエリされたドメイン | 照会されたRRタイプ | 結果 |
|---|---|---|
host3.example. | MX | 答えは「host3.example. IN MX ...」になります。 |
host3.example. | あ | に「A」リソース レコード (RR) が設定されていないため、答えは「エラーはないが、データはない」となります*.example。 |
foo.bar.example. | TXT | 答えは「foo.bar.example. IN TXT ...」になります。bar.example.存在しないのにワイルドカードが存在するためです。 |
次の応答は、ゾーン内のどのワイルドカードからも合成されません。
| クエリされたドメイン | 照会されたRRタイプ | 結果 |
|---|---|---|
host1.example. | MX | ワイルドカードが存在するため、一致するものはありませんhost1.example.。代わりに、「エラーはありませんが、データはありません」という応答が返されます。ワイルドカードMXレコードは、存在するドメインのMXレコードを提供しません。 |
sub.*.example. | MX | sub.*.example.ワイルドカードが存在するため、一致しません。sub.*.example.ドメインにアスタリスクが含まれていても、ワイルドカードとして機能しません。 |
_telnet._tcp.host1.example. | SRV | _tcp.host1.example.ワイルドカードが存在するため（データなし）、 一致するものはありません。 |
host.subdel.example. | あ | subdel.example.が存在し、ゾーンカットされているため、ワイルドカードは一致しません。これhost.subdel.example.は別のDNSゾーンに配置されます。他のゾーンに存在しない場合でもhost.subdel.example.、親ゾーンのワイルドカードは使用されません。 |
ghost.*.example. | MX | ワイルドカードが存在するため*.example.、一致するワイルドカードは存在しません。これはワイルドカード ドメインですが、それでも存在します。 |
最後の例は、ワイルドカードに関するよくある誤解を浮き彫りにしています。ワイルドカードは、自身のサブドメインには一致しないという意味で、「自身をブロックする」のです。つまり、 はゾーン*.example. 内のすべての名前に一致せずexample.、 の下にある名前には一致しません*.example.。 の下にある名前をカバーするには、自身のサブドメインを除くすべてのサブドメインをカバーする *.example.別のワイルドカードドメイン名 が必要です。*.*.example.
実際には
RFC 4592から引用すると、多くのDNS実装は、ワイルドカードの本来の定義から、さまざまな点で逸脱しています。そのバリエーションには、次のようなものがあります。
- djbdnsでは、現在のレベルでのワイルドカードのチェックに加えて、サーバーはルートまでのすべてのスーパードメインでワイルドカードをチェックします。上記の例では、
_telnet._tcp.host1.exampleMXレコードのクエリは、ドメインが存在するにもかかわらず、ワイルドカードと一致します_tcp.host1.example。 - MicrosoftのDNSサーバー（設定されている場合[ 1 ]）とMaraDNS（デフォルト）には、ワイルドカードが空のリソースレコードセット（つまり、目的の種類のレコードが存在しないドメイン名）へのすべてのリクエストに一致します。上記の例では、MXレコードのクエリは、 TXTレコードのみで明示的に存在するにもかかわらず、
sub.*.example一致します。*.examplesub.*.example
登録者
ワイルドカードドメインは、 WordPressやBlogspotなどのブログサイトで広く利用されています。これらのサイトでは、ユーザーが必要に応じてサブドメインを作成できます。また、ISPのDHCPサーバーによって定期的にIPアドレスが変更されるたびに、ホストIPに合わせてDNS名が変化する無料のダイナミックDNSサイトでも広く利用されています。
新しいTLD
ICANN新gTLDベースレジストリ契約の仕様6により、新gTLDはワイルドカードの公開（または同等のネームサーバーメカニズムの使用）を禁止されています。ただし、ICANNの名前衝突発生管理フレームワーク（PDF ）では、新gTLDに対し、ドメイン検索パスで相対ドメイン名を使用することで発生する可能性のある名前衝突を警告する特別なMXレコード、SRVレコード、TXTレコード、および127.0.53.53 Aレコードのワイルドカードを（少なくとも90日間）公開することが明示的に義務付けられています。
レジストリ/ISP
いくつかのドメイン名登録機関は、様々な時期に、広告プラットフォームを提供するためにトップレベルドメインにワイルドカードレコードを導入してきました。中でも特に有名なのは、 .comと.netのVeriSignのSite Finderシステム（現在は削除されています）です。.museum TLD にもワイルドカードレコードがありましたが、現在は削除されています。2018年3月現在、ワイルドカード A レコードを使用しているトップレベルドメイン（127.0.53.53 以外）は、.fm、.la、.ph、.pw、.vg、.wsです。国際化TLD の.中国（.xn--fiqs8s または .xn--fiqz9s、つまり「China」）と .გე（.xn--node、つまりジョージアの国コード「GE」のジョージア文字）にもワイルドカード A レコードがあります。ワイルドカードは (Chrome によって安全でないとフラグが付けられます) に解決され、 ワイルドカードは.ge TLDの Web サイトに解決されます。 *.中国ibaidu.com*.გე
また、ISPが同一人物の誤字脱字のアドレス記録を合成することも一般的になっており、これは「キャッチオール」タイポスクワッティングと呼ばれる行為であるが、これらは真のワイルドカードではなく、むしろキャッシングネームサーバーを改造したものである。[ 2 ]
他者からのワイルドカードを無視する
インターネットソフトウェアコンソーシアム（ISC）は、特定のドメインからのワイルドカードDNSレコードをフィルタリングするように設定できるBIND DNSソフトウェアのバージョンを開発しました。複数の開発者がBINDおよびdjbdns用のソフトウェアパッチを作成しています。
他の DNS サーバー プログラムもこれに追随し、設定されたワイルドカード DNS レコードを無視する機能を提供しています。
参考文献
外部リンク
