人気のツール

テーマ

CNAME検索

CNAME検索で、あらゆる名前のDNSのCNAMEレコードを確認できます：各ゾーン自身のネームサーバーに問い合わせてCNAMEチェーンを1ホップずつたどり、すべての別名とそのTTL、応答したサーバー、参照先の背後にあるプラットフォーム、最終的なアドレスを表示します。参照先のない別名、ループ、長すぎるチェーンは、修正方法とともに指摘します。

情報源：ルートサーバーからたどった、各ゾーン自身のネームサーバー · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

入力したとおりに検索します：www.やサブドメインはそのまま使い、IDN（国際化ドメイン名）はPunycodeで送信します。

例

CNAMEレコードとは？

CNAME（canonical name、正規名）レコードは、ある名前を別の名前の別名にするレコードです。別名を問い合わせると、DNSは「代わりにこちらの名前を検索してください」と答えます。値は常に名前で、IPアドレスになることはありません（RFC 1034 §3.6.2）。

リゾルバーが別名を自動でたどり、参照先のアドレスを同じ応答の中で返すため、ブラウザーが気づくことはありません。プラットフォームがCNAMEを求めるのはそのためです：wwwを一度そのプラットフォームの名前に向けておけば、こちらがDNSに手を加えなくても、プラットフォーム側でサーバーを移せます。

厳密には正規名とは参照先のほうで、別名を「CNAME」と呼ぶのは一般的な略し方です。CNAMEを持つ名前はほかに何も持てず、CNAMEも1つしか持てません（RFC 2181 §10.1）。そのため、SOAレコードとNSレコードを持たなければならないゾーンの頂点には、CNAMEを置けません（RFC 1034 §4.2.1）。

CNAMEレコードの構造www.microsoft.com · 2026/10/23に記録
www.microsoft.com.別名（所有者名）3600TTLINクラスCNAMEタイプwww.microsoft.com-c-3.edgekey.net.正規名（参照先）
別名利用者が入力したり、リンクしたりする名前です。このレコード1つだけを持ち、ほかには何も持ちません。
TTL · 1 時間リゾルバーがこのレコードを保持してから、再び問い合わせるまでの時間です。
参照先次に検索する場所で、ここではAkamaiのエッジの名前です。常に名前で、アドレスになることはありません。
  1. 検索する名前www.github.com
  2. CNAME · 1 時間
  3. 正規名github.com
  4. A · 1 分
  5. アドレス · AS8075 Microsoft20.207.73.82
  • www.github.comCNAMEgithub.com同じドメイン
  • www.rust-lang.orgCNAMErust-lang.github.ioGitHub Pages
  • www.cursor.comCNAMEcname.vercel-dns.comVercel
  • docs.github.comA185.199.108.154ほか3件別名なし：自身のアドレス
各ゾーン自身のネームサーバーで記録しました。www.github.comを問い合わせたリゾルバーは、別名とgithub.comのアドレスを1つの応答で受け取ります。

CNAMEレコードの確認方法

上の欄に名前を入力してCNAMEを検索を押すと、ツールが各ゾーン自身のネームサーバーに1ホップずつ問い合わせ、チェーンを図示します。コンピューターではdigを使えば1行で済みます：タイプAを問い合わせると、応答にはまずすべての別名が、次にアドレスが並びます。

最初の別名だけを確認するには、タイプCNAMEを問い合わせます。Windowsではnslookup -type=cname、PowerShellではResolve-DnsName -Type CNAMEを使います。host -t cnameは結果を1文で表示します。

注意点が2つあります：リゾルバーが示すのはゾーンが設定したTTLではなく、キャッシュに残っているTTLです。また、dig +shortはTTLと所有者名を省くため、チェーンはただの一覧として表示されます。

dig www.example.com A +noall +answer

すべての別名とそのTTL、次にアドレスを表示します。+shortでは参照先だけが表示され、TTLは表示されません。

digの応答の読み方8.8.8.8経由のwww.nytimes.com · 2026/10/23
bash · dig
$ dig www.nytimes.com A +noall +answer
www.nytimes.com.                  12902IN  CNAME www.prd.map.nytimes.com.3
www.prd.map.nytimes.com.             482   IN  CNAME www.prd.map.nytimes.xovr.nyt.net.
www.prd.map.nytimes.xovr.nyt.net.    260   IN  CNAME nytimes.map.fastly.net.
nytimes.map.fastly.net.               28   IN  A     151.101.1.1644
nytimes.map.fastly.net.               28   IN  A     151.101.129.164
nytimes.map.fastly.net.               28   IN  A     151.101.193.164
nytimes.map.fastly.net.               28   IN  A     151.101.65.164

$ dig www.nytimes.com +short5
www.prd.map.nytimes.com.          # TTLも所有者名もなし
www.prd.map.nytimes.xovr.nyt.net.
nytimes.map.fastly.net.
151.101.1.164
151.101.129.164
151.101.193.164
151.101.65.164
  1. 問い合わせた名前。 各行の最初の列は、そのレコードの所有者名です。
  2. Googleのキャッシュに残っている秒数： ゾーンの600 秒のうち290 秒。ゾーン自身のサーバーは完全なTTLを返します。
  3. CNAME → 次の名前。 ここでは別名が3件あるため、このような行も3行あります。
  4. アドレス： チェーンの最後の名前、つまりFastlyのアドレスです。ゾーンでのTTLは1 分です。
  5. +shortはTTLを隠します。 所有者名も隠すため、残るのは参照先とアドレスだけです。

ほかのツールでの同じ問い合わせ

nslookup
$ nslookup -type=cname www.nytimes.com
Non-authoritative answer:
www.nytimes.com	canonical name = www.prd.map.nytimes.com.
PowerShell
PS> Resolve-DnsName www.nytimes.com -Type CNAME
# レコードごとに1行：名前、タイプ、TTL、参照先
host
$ host -t cname www.nytimes.com
www.nytimes.com is an alias for www.prd.map.nytimes.com.

nslookupの出力はmacOSのものです。Windowsでは、同じ応答が少し異なるレイアウトで表示されます。

CNAME検索の結果の見方

冒頭の1文で、名前がどこに行き着くか、いくつの別名を経由するかを、プラットフォームのマークとともに示します。その下の注記が、重要な指摘事項です。数えるのはCNAMEレコードの数です：www.github.com → github.comは2件ではなく1件です。

「チェーン」表示では、各レコードを、そのゾーンのサーバーが返したとおりに、ゾーン、サーバー、AAフラグ、TTLとともに一覧にし、続いてチェック項目（ループ、長さ、存在しない参照先、CNAMEと併存するほかのデータ）を示します。「コピー」表示では、各レコードについて、GoogleとCloudflareのキャッシュのコピーをゾーンの応答と並べます。右側の濃紺の列はチェーンを図示し、ループは輪で、存在しない参照先は途切れた形で描きます。

www.nytimes.comのCNAME検索の結果：Fastlyに至る3つの別名、各レコードのTTLとゾーン、アドレスまでのチェーンの図www.nytimes.comのCNAME検索の結果：Fastlyに至る3つの別名、各レコードのTTLとゾーン、アドレスまでのチェーンの図判定名前の行き着く先、経由する別名の数、プラットフォーム、アドレスのネットワーク。キャッシュのコピー各レコードのGoogleとCloudflareのコピー、それぞれの残り時間、最初のレコードへの変更が反映される時刻。各レコード、1ホップずつゾーンが保持しているとおりの参照先とTTL、応答したサーバー、AAフラグ、応答時間。チェーン名前、ゾーンとTTL付きの各別名、そして最終的なアドレスとそのネットワーク。
www.nytimes.comのCNAME検索の例です。判定、ゾーンのサーバーが返したとおりの各別名、チェック項目、右側に描かれたチェーンを表示します。番号を選ぶと、各部分に何が表示されているかを確認できます。

CNAMEとAレコードの違い

Aレコードはアドレスを持ちます：docs.github.com → 185.199.108.154。CNAMEは名前を持ちます：www.github.com → github.comで、アドレスはその名前自身のAレコードから得られます。

自分のサーバーとルートドメインにはAレコードを使います。プラットフォームから向け先の名前を渡された場合（Vercel、GitHub Pages、CDN、メールサービスのDKIM鍵）はCNAMEを使います：相手がサーバーを移しても、レコードが自動で追従します。

その代わり、別名1つごとに問い合わせが1回増え、厳しい規則もあります：その名前にはほかに何も置けず、ゾーンの頂点には決して置けません。

CNAMEとAの比較実際のレコード、2026/10/23に記録
CNAME別名www.github.comAアドレスdocs.github.com
指す先別の名前：github.comIPv4アドレス：185.199.108.154
ルート（example.com）に置けるか不可：頂点にはSOAとNSがある可
同じ名前のほかのレコードなし：MX、TXT、Aも置けない何でも可：AAAA、MX、TXT…
追加の問い合わせ別名1つにつき1回：ここでは1回、www.nytimes.comでは3回なし
ホストの移転時参照先に自動で追従アドレスを自分で編集
用途プラットフォームの名前、CDN、DKIMの鍵自分のサーバー、ルートドメイン
CNAME：2段階www.github.comgithub.com20.207.73.82
A：1段階docs.github.com185.199.108.154

ルートドメインのCNAME：ALIAS、ANAME、CNAMEフラット化

ドメインのルート（github.com）はゾーンの頂点で、頂点にはゾーンのSOAレコードとNSレコードがなければなりません。CNAMEは横にほかのものを置けないため、そこには置けません：2つの規則がぶつかるのです（RFC 1034 §4.2.1、RFC 2181 §10.1）。

DNSホスティング各社は、自社のサーバーでこれを回避しています：参照先を自分でたどり、そのアドレスで応答するのです。CloudflareはCNAMEフラット化（CNAME flattening）、Route 53はエイリアスレコード、DNSimpleとNS1はALIAS、DNS Made EasyはANAMEと呼んでいます。リゾルバーから見えるのはAとAAAAだけなので、その背後の別名はどの検索でも表示できません。

ANAMEに標準はありません：IETFのドラフトは2019年に失効しました。標準の方法はAliasModeのHTTPSレコード（RFC 9460）ですが、使うのはそれを問い合わせるクライアントだけなので、ルートには引き続きAレコードが必要です。

ルートにCNAMEを置けない理由github.com · ゾーンの頂点、2026/10/23

github.com.ゾーンの頂点

  • SOAdns1.p08.nsone.net. hostmaster.nsone.net. …
  • NSサーバー8台： NS1 + Route 53
  • MX github-com.mail.protection.outlook.com.
  • A20.207.73.82
  • CNAMEanything.example.net.

CNAMEは単独で置く必要があり、これらのレコードはここに必要です：そのため、ルートにCNAMEは置けません。

DNSホスティングが代わりに提供する機能リゾルバーから見えるもの

  • Cloudflare · CNAMEフラット化ルートでは、すべてのプランで既定で有効A · AAAA
  • Amazon Route 53 · エイリアスレコードAWSリソースまたは同じゾーンのレコードが対象A · AAAA
  • DNSimple · ALIAS問い合わせを受けた時点で参照先を検索A · AAAA
  • NS1 (IBM) · ALIASA · AAAA
  • DNS Made Easy · ANAMEA · AAAA
  • Azure DNS · エイリアス レコード セットA · AAAA
  • AliasModeのHTTPSレコード · RFC 9460唯一の標準：サービスごとに、問い合わせるクライアント向けHTTPS
どのベンダーの機能もただのアドレスで応答するため、その背後の別名はどの検索ツールにも表示できません。

CNAMEチェーンとTTL、変更が反映されるまでの時間

別名は、別の別名を指すこともできます：www.microsoft.comは2つ、www.nytimes.comは3つの別名を経由します。チェーン内の各レコードはそれぞれ独自のTTLを持ち、個別にキャッシュされるため、コピーの期限はばらばらに切れます（RFC 1034 §5.3.3）。

そのため、最小のTTLが待ち時間になるわけではありません。Microsoftの最終的なアドレスの寿命は20秒ですが、最初のレコード、つまりmicrosoft.com自身のゾーンにあるレコードへの変更は、そのレコードのコピーの期限切れを待つことになります：確認した時点でGoogleのコピーは残り37分、Cloudflareのコピーはほぼ1時間まるごと残っており、どのリゾルバーも最大でその1時間保持する可能性があります。

チェーンは短く保ってください。RFC 9460は、連続する別名を8件以内にするよう推奨しています。BINDとUnboundは11件、PowerDNSは10件、Knotは13件で諦めます。GoogleとCloudflareは上限を公開していません。

レコードごとに別々の時計www.microsoft.com · 2026/10/23 07:22:26（UTC）に確認
  1. www.microsoft.comCNAME → www.microsoft.com-c-3.edgekey.net所有者が編集するレコード1 時間ゾーンでのTTL
    • Google残り36:37 · 07:59:03まで
    • Cloudflare残り59:48 · 08:22:14まで

    このレコードへの変更が反映されるのは、Googleでは07:59:03まで、Cloudflareでは08:22:14（UTC）までで、どのリゾルバーでも1 時間以内です。

  2. www.microsoft.com-c-3.edgekey.netCNAME → e13678.dscb.akamaiedge.net15 分ゾーンでのTTL
    • Google残り6:58 · 07:29:24まで
    • Cloudflare残り14:48 · 07:37:14まで
  3. e13678.dscb.akamaiedge.netA 23.2.78.94最小のTTL20 秒ゾーンでのTTL
    • Google残り0:20 · 07:22:46まで
    • Cloudflare残り0:08 · 07:22:34まで

公開されている上限と、実際のチェーン

www.github.com別名1件www.microsoft.com別名2件www.nytimes.com別名3件www.apple.com別名3件
  • 8 RFC 9460：8件を超えるのは非推奨
  • 10 PowerDNS
  • 11 BIND, Unbound
  • 13 Knot
  • Google, Cloudflare: 公開なし
棒：確認した時点で各キャッシュのコピーに残っていた時間。変更が反映されるのは、編集したレコードのコピーの期限が切れたときです。最小のTTLが示すのは、その部分が取得し直される頻度だけです。

参照先のないCNAME（dangling CNAME）とサブドメインの乗っ取り

参照先がなくなったCNAMEは、参照先のないCNAME（dangling CNAME）になります：削除されたクラウドアプリ、空になったバケット、期限切れのドメインなどです。ほかの誰かがその名前でリソースを作成できれば、その人がこちらのサブドメインでコンテンツを配信し、有効な証明書まで取得できてしまいます。

DNSでは、CNAMEをまだ含んだNXDOMAINの応答として現れます：存在しないのは名前ではなく参照先です（RFC 6604 §3）。これが判断の手がかりになるのは、リソースごとに独自のDNS名を割り当てるプラットフォームだけです。どの名前にも応答するプラットフォームでは、削除されたサイトも名前解決されるため、サイトそのものを確認してください。

対策は順序です：リソースより先にDNSレコードを削除し、ドメインの認証を提供しているプラットフォームではドメインを認証してください。参照先を修正しても、しばらくは存在しないように見えることがあります：リゾルバーは、参照先ゾーンのSOAのTTLとMINIMUMフィールドのうち小さいほうの期間、ネガティブな応答を保持するからです（RFC 2308 §5）。

NXDOMAINでわかる場合プラットフォームの動作、2026/10/23に確認

存在しない参照先はNXDOMAINを返す

削除されたリソースの名前は名前解決されなくなります：当サイトの判定は参照先なしです。

  • *.azurewebsites.netApp Service
  • *.trafficmanager.netTraffic Manager
  • *.blob.core.windows.netBlob Storage
  • *.cloudapp.netCloud Services
  • *.elasticbeanstalk.comElastic Beanstalk
  • *.elb.amazonaws.comElastic Load Balancing
  • *.pages.devCloudflare Pages
  • *.edgekey.netエッジホスト名
  • *.map.fastly.netマップ名

プラットフォームがどの名前にも応答する

削除されたサイトも名前解決されます：当サイトの判定はプラットフォームを指している：サイトが今も自分のものか確認です。

  • *.github.ioGitHub Pages
  • *.netlify.appNetlify
  • *.herokuapp.comHeroku
  • *.vercel.appVercel
  • *.myshopify.comShopify
  • *.pantheonsite.ioPantheon
  • *.go-vip.netWordPress VIP
  • *.webflow.ioWebflow
  • *.zendesk.comZendesk
  • *.s3.amazonaws.comAmazon S3
  • *.azurefd.netAzure Front Door
  • *.global.ssl.fastly.netTLSホスト名
架空の例 · RFC 2606の名前
$ dig shop.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; ANSWER SECTION:     # 設定したレコードは存在する
shop.example.com.   3600  IN  CNAME  example-shop.example.net.
;; AUTHORITY SECTION:  # その参照先はない。リゾルバーはこの結果を5 分保持することがある
example.net.         300  IN  SOA    ns1.example.net. …

乗っ取りを防ぐ所有権の確認

  • GitHub PagesTXT _github-pages-challenge-<user>.<domain>
  • Azure App ServiceTXT asuid.<subdomain>
  • WebflowTXT _webflow one-time-verification=…
  • Cloudflare for SaaSホスト名の検証（TXTまたはHTTP）
  • Netlifyドメインロック（サポート経由）
CNAMEが残ったままのNXDOMAINの応答は、存在しないのが名前ではなく参照先であることを意味します。

CNAMEレコードの追加方法（GoDaddy、Cloudflare、Namecheap、Squarespace）

どのDNS管理画面でも、求められるのは同じ3つです：タイプ（CNAME）、ホスト、プラットフォームから渡された参照先です。ホストの欄にはwwwやshopのようにラベルだけを入力します：ドメインは管理画面が自動で付け加えます。

完全な名前を入力するとwww.example.com.example.comになります。新しいCNAMEが「機能しない」最もよくある原因です。ゾーンファイルでも同じことが起こり、末尾のドットがない名前は相対名として扱われます。Cloudflareでは、Proxiedのレコードは検索からCNAMEを隠します：プラットフォームがCNAMEを確認する必要がある場合はDNS onlyにしてください。

その後、ここで確認してください。ホスティング各社の説明は1分から72時間までさまざまですが、変更したレコードの実際の待ち時間は古いレコードのTTLで、新しく作った名前は通常すぐに表示されます。

4つの管理画面での同じレコードホストの欄にはラベルだけ

GoDaddy参照先の提供元： Shopify

TypeCNAMENamewwwValueshops.myshopify.com

Name：blogやshopのように、ドメイン名を含めずに入力します。@は使いません。

Cloudflare参照先の提供元： Webflow

TypeCNAMENamewwwTargetcdn.webflow.comProxy statusDNS only

Name：サブドメインを入力します。DNS onlyならCNAMEは検索で見え、Proxiedでは隠れます。

Namecheap参照先の提供元： Google

TypeCNAMEHostwwwValueghs.googlehosted.com

Host：mysubdomain.domain.tldではなく、mysubdomainのように入力します。

Squarespace参照先の提供元： Framer

TypeCNAMENamewwwDatasites.framer.app

Name：Nameの欄に@を入れてCNAMEを追加することはできません。

入力したホスト： www.example.com管理画面はwww.example.com.example.comとして保存します：wwwと入力してください。

ホストの説明とTTLの比較

  • Route 53自社のサーバーでは1 分以内
  • Namecheap30 分
  • GoDaddy1 時間、最大48 時間既定のTTL 1 時間
  • Hostinger最大24 時間既定のTTL 4 時間
  • Squarespace24 時間〜48 時間既定のTTL 4 時間
  • Gandi最大72 時間

ホストの説明既定のTTL：リゾルバーが古いレコードを保持できる時間

表示している参照先は、それぞれのプラットフォームが公開しているCNAMEの参照先です。棒は時間単位の共通の目盛りで、新しく作った名前は通常すぐに表示されます。

Cloudflareのエラー1014：CNAME Cross-User Banned

エラー1014は、Cloudflare上の名前が、CNAMEで別のCloudflareアカウントの名前を指している場合に表示されます。ある顧客が別の顧客の設定を通じてトラフィックを流せないよう、Cloudflareがこれをブロックしています。

1つのゾーンの中、同じアカウントのゾーン同士、そして参照先の所有者がこちらの名前をカスタムホスト名として追加するCloudflare for SaaSを通じてなら許可されます。Cloudflare上で動くSaaSにドメインを向ける場合は、これが解決策です。ほかの原因：ゾーンが保留中のR2カスタムドメイン、または禁止されたゾーン。

検索でわかるのはヒントだけです：両方のゾーンがCloudflareのネームサーバーを使っている場合、別々のアカウントにあれば1014の可能性があります。DNSからわかるのはゾーンであってアカウントではなく、プロキシされたレコードはCNAME自体を隠すため、ここに表示されるのはDNS onlyのレコードだけです。

2つのアカウント、1つのCNAME架空の例 · RFC 2606の名前

アカウントA

shop.example.comCNAME → shops.example.net

1014Cross-User Banned

アカウントB

shops.example.netプロキシ · SaaSプロバイダー自身のゾーン

  • 同じゾーンwww → example.com
  • 同じアカウントあるゾーン → その姉妹ゾーン
  • Cloudflare for SaaS参照先の所有者がホスト名を追加

ほかの原因：ゾーンが保留中のR2カスタムドメイン、または禁止されたゾーン。

このツールでわかること：両方のゾーンが*.ns.cloudflare.comから応答している場合、アカウントが異なれば1014の可能性があります。DNSからわかるのはゾーンであって、アカウントではありません。*.cdn.cloudflare.netの参照先はCloudflareのCNAME (partial) setupで、SaaSではありません。

CNAMEとリダイレクトの違い

CNAMEはリダイレクトではありません。DNSにアドレスの場所を伝えるだけで、ブラウザーはアドレスバーに入力された名前をそのまま保ち、その名前をサーバーに送って、その名前の証明書を期待します。

プラットフォームが自社側でもドメインの追加を求めるのはそのためです：プラットフォームのサーバーがwww.example.comを認識し、その名前の証明書を提供しなければなりません。名前を知らないサーバーにCNAMEを向けると、既定のページか証明書のエラーが表示されます。

あるURLから別のURLへ訪問者を送るには、WebサーバーでHTTPリダイレクト（301または308）を使うか、DNSホスティングの転送機能（そうしたサーバーを代わりに運用してくれる機能）を使います。リダイレクトチェッカーで、リダイレクトの各段階を確認できます。

ブラウザーから見えるもの架空の例 · RFC 2606の名前

CNAME名前はそのまま

www.example.com

  • DNS： www.example.com → CNAME sites.example.net → そのアドレス
  • TLS： 証明書にwww.example.comが記載されている必要がある
  • HTTP： Host: www.example.com。サーバーがこの名前を知っている必要がある

301URLが変わる

www.example.net/

  • DNS： example.com → WebサーバーのAレコード
  • HTTP： 301 Location: https://www.example.net/
  • ブラウザー： 新しいURLを読み込み、そのURLについて改めてDNSを検索

CNAME検索：よくある質問

CNAMEレコードとは何ですか？

CNAMEレコードは、ある名前を別の名前、つまり正規名の別名にするレコードです。リゾルバーが別名を問い合わせると、応答は代わりに参照先を検索するよう示し、参照先自身のAまたはAAAAレコードがアドレスを返します。値は常に名前で、IPアドレスになることはなく、CNAMEを持つ名前はほかのレコードを持てません。

CNAMEレコードを確認するにはどうすればよいですか？

上のCNAME検索に名前を入力してください：各ゾーン自身のネームサーバーに問い合わせ、すべての別名とそのTTL、背後のプラットフォーム、最終的なアドレスを表示します。コンピューターでCNAMEを確認するには、macOSやLinuxではdig www.example.com CNAME、Windowsではnslookup -type=cname www.example.com、PowerShellではResolve-DnsName www.example.com -Type CNAMEを実行します。

CNAMEとAレコードの違いは何ですか？

AレコードはIPv4アドレスを持ち、CNAMEは別の名前を持って、その名前のアドレスを借ります。ルートドメインと自分のサーバーにはAレコードを使います。Vercel、GitHub Pages、CDNなどのプラットフォームから向け先の名前を渡された場合はCNAMEを使えば、相手がサーバーを移したときもレコードが追従します。

ルートドメインにCNAMEを設定できますか？

できません。ルートはゾーンの頂点で、SOAレコードとNSレコードを持たなければならず、CNAMEは横にほかのレコードを置けないからです。DNSホスティング各社は、ただのアドレスで応答する回避策を提供しています：CloudflareのCNAMEフラット化、Route 53のエイリアスレコード、DNSimpleとNS1のALIAS、DNS Made EasyのANAMEです。唯一の標準は、AliasModeのHTTPSレコードです。

設定したCNAMEが表示されないのはなぜですか？

よくある理由は4つです：Cloudflareでレコードがプロキシまたはフラット化されていて、リゾルバーにはCloudflareのアドレスしか見えない。ホストの欄に完全な名前を入力して、www.example.com.example.comができている。CNAMEと共存できないAレコードが、まだその名前に残っている。リゾルバーがTTLが切れるまで古い応答を保持している。上の検索では、ゾーンのDNSホスティング、名前が保持しているもの、各コピーの残り時間がわかります。

CNAMEの変更が反映されるまでどのくらいかかりますか？

古いレコードのTTLの長さだけかかり、各リゾルバーが最後にそれを取得した時点から数えます。チェーン内の各レコードは個別にキャッシュされるため、自分が管理するCNAMEへの変更は、最終的なアドレスのTTLが数秒であっても、そのレコードのコピーの期限切れを待つことになります。新しく作った名前は通常すぐに表示されますが、作成前に誰かがその名前を問い合わせていた場合は別です。

参照先のないCNAME（dangling CNAME）とは何ですか？

参照先がもう存在しないCNAMEです：削除されたクラウドアプリ、空になったバケット、期限切れのドメインなどです。ほかの誰かがその参照先の名前でリソースを作成できれば、そのサブドメインでコンテンツを配信できてしまいます。リソースごとに独自のDNS名があるプラットフォームでは、検索結果はCNAMEが残ったままのNXDOMAINになります：レコードを削除するか、稼働中の参照先に向けてください。

CNAMEは何段までチェーンできますか？

DNSに決まった上限はありませんが、RFC 9460は連続する別名を8件以内にするよう推奨しています。リゾルバーはそれぞれの上限で諦めます：BINDとUnboundは11件、PowerDNSは10件、Knotは13件で、GoogleとCloudflareは上限を公開していません。実際のチェーンは短く、当サイトが記録した有名な12サイトの別名は0〜3件です。

CNAMEにIPアドレスを指定できますか？

できません。CNAMEの値はホスト名でなければなりません。192.0.2.1のようなアドレスをCNAMEに入力すると、4つの数字のラベルからなる名前として読まれ、その名前は存在しないため、別名はどこにも行き着きません。名前をアドレスに向けるには、代わりにIPv4ならAレコード、IPv6ならAAAAレコードを使います。

CNAMEはリダイレクトと同じですか？

違います。CNAMEが変えるのはDNSがアドレスを見つける場所だけで、ブラウザーはアドレスバーに元の名前を保ったまま、その名前でサーバーにリクエストします。そのため参照先は、そのドメインを受け入れ、その証明書を持っている必要があります。訪問者を別のURLに送るには、WebサーバーでHTTPの301または308のリダイレクトを使うか、DNSホスティングの転送機能を使います。

Cloudflareのエラー1014とはどういう意味ですか？

CNAME Cross-User Bannedのことで、Cloudflare上の名前が、CNAMEで別のCloudflareアカウントの名前を指しているという意味です。1つのゾーンの中、同じアカウントのゾーン同士、または参照先の所有者がホスト名を追加するCloudflare for SaaSを通じてなら機能します。Cloudflare上で動くSaaSに向けている場合は、ドメインをカスタムホスト名として設定するよう、そのサービスに依頼してください。

DKIMのセレクターにCNAMEが使われるのはなぜですか？

メールサービスはDKIMの鍵を自社のゾーンで公開し、セレクターをそこに向けるよう求めます。そうすれば、利用者の手を借りずに鍵を切り替えられるからです。Microsoft 365はselector1とselector2、SendGridはs1とs2、Mailchimpはk2とk3を使います。CNAMEの終点はアドレスではなくTXTレコードです：「よく使われるサブドメイン」モードで、それらをすべて確認できます。

その他のDNSツール