公開2026.07.14更新2026.09.12 インフラ・クラウド

Aレコードとは？IPv4アドレスへの対応付けとAAAA/CNAMEとの違い・書き方・digでの確認を実装者向けに解説

Aレコード（Address record）とは、DNSで「www.example.com」のようなドメイン名を「192.0.2.10」といったIPv4アドレスに対応付けるレコードです。ブラウザやアプリがサーバーへ接続する直前、名前解決の最終段でこのAレコードが引かれ、実際の接続先IPが決まります。この記事では、ゾーンファイルでのAレコードの書き方とTTLの意味、AAAA・CNAME・ALIASとの使い分け、同名に複数のAレコードを置くラウンドロビン、Route 53でのapex（ルートドメイン）設計、そしてdigでの確認と切り替え、引けないときの切り分けまでを、実装者が手を動かせる粒度で整理しました。DNS全体の流れを先に押さえたい場合は名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説を土台にすると、本記事のAレコードの位置づけが掴みやすくなります。

まとめ：Aレコードの役割と実装者がまず押さえる要点

Aレコードは「ドメイン名 → IPv4アドレス」という正引きの答えそのものを保持するレコードです。名前解決の反復問い合わせが権威DNSサーバーへたどり着いた最後に、この1行が返ってIPが確定します。IPv6アドレスを返す場合は同じ役割のAAAAレコードを使い、両者はレコードタイプが違うだけで用途は対になる関係です。レコードタイプの番号はIANAのDNS Parametersレジストリで管理されており、Aは1番、AAAAは28番、CNAMEは5番として登録されています。

実装者の観点では、次の3点を分けて理解すると設計と障害切り分けが速くなります。第一に、Aレコードは「名前」と「IPv4アドレス」の対応を1対1でも1対多でも持て、同名に複数書けばDNSラウンドロビンで粗い分散ができるのが利点です。第二に、別名を張るCNAMEはゾーンの頂点（apex、例：example.com そのもの）には置けず、頂点でロードバランサーへ向けたいときはAレコードやクラウド固有のAlias機能を使います。第三に、Aレコードの答えはTTL（Time To Live）秒数だけ各所にキャッシュされ、書き換えても即座には反映されません。以降の章で、この3点を順に掘り下げます。

ゾーンファイルにAレコードを書いて名前とIPv4を対応付ける

Aレコードが対応付ける「名前」と「IPv4アドレス」の基本関係

Aレコードの左辺は名前、右辺はIPv4アドレスです。左辺の名前は完全修飾ドメイン名（FQDN）で解釈され、右辺は「192.0.2.10」のようなドット区切りの32ビットアドレスを取ります。レコード自体の定義とゾーンファイルの書式はRFC 1035（Domain Names — Implementation and Specification）にあり、Aレコードのデータ部が32ビットのインターネットアドレス1個であることもここに書かれています。左辺に何を書けるか、ホスト名とドメイン名がどう連なるかを厳密に押さえたい場合はFQDNとは？ドメイン名・ホスト名との違いと書き方・確認コマンドを実装者向けに解説を先に確認してください。右辺のIPv4アドレスがインターネットに公開する種類なのか内部専用なのかという区分はグローバルIPとは？プライベートIPとの違い・確認方法・仕組みを実装者向けに解説で整理しています。公開サーバーのAレコードにはグローバルIPを、社内システムのAレコードにはプライベートIPを対応付けるのが基本の切り分けです。なお本記事に出てくる192.0.2.0/24はRFC 5737が文書用に予約した範囲で、実機の設定値としてそのまま写すものではありません。

ゾーンファイルでのAレコードの記法とTTL・末尾ドットの意味

権威DNSサーバーが読むゾーンファイルでは、Aレコードは次のように1行で表します。

フィールド	例	意味
名前	www.example.com.	対応付ける名前（末尾ドットは絶対表記）
TTL	300	この答えをキャッシュしてよい秒数
クラス	IN	インターネットを表すクラス（通常IN）
タイプ	A	IPv4アドレスを返すレコードであること
値	192.0.2.10	返すIPv4アドレス

並べるとwww.example.com. 300 IN A 192.0.2.10となります。名前の末尾ドットは「ルートを起点とした絶対表記」を意味し、ドットを付け忘れるとゾーンのドメイン名が補われて意図しない名前（www.example.com.example.com）になる事故が起きます。この取り違えは運用上の定番の誤りとしてRFC 1912（Common DNS Operational and Configuration Errors）にも挙げられており、目視レビューではなく後述の構文チェックで機械的に潰すのが現実的な対処です。ゾーンファイルの先頭の$TTLで既定TTLをまとめて指定し、個々のAレコードで上書きもできます。GUIのDNS管理画面ではこの各フィールドが入力欄に分かれているだけで、内部で持つ情報は同じです。

BINDのゾーンファイルを書いてnamed-checkzoneで検証する

実際に手を動かす形にすると、Aレコードを含むゾーンファイルは次のようになります。同名のwwwにAレコードを2行、apexにも1行置き、AAAAを併記した構成です。

$TTL 300
@   IN SOA ns1.example.com. hostmaster.example.com. (
        2026091201 ; serial
        7200       ; refresh
        900        ; retry
        1209600    ; expire
        300 )      ; negative cache TTL
@       IN NS   ns1.example.com.
@       IN NS   ns2.example.com.
@       IN A    192.0.2.10
www     IN A    192.0.2.10
www     IN A    192.0.2.11
www     IN AAAA 2001:db8::10
api     IN A    192.0.2.20
mail    IN A    192.0.2.30

書き終えたら、反映の前に構文と整合を機械で確かめます。BIND 9に同梱されるnamed-checkzoneは、末尾ドットの付け忘れやSOA・NSの不足といった誤りを読み込み時に弾くコマンドで、使い方はBIND 9公式ドキュメントのmanpagesにまとまっています。

named-checkzone example.com /var/named/example.com.zone
named-checkconf /etc/named.conf
rndc reload example.com

1本目で「OK」と出てシリアル値が表示されれば、ゾーンとして読める状態です。ここを通さずに配信してしまうと、ゾーン全体の読み込みが失敗して当該ドメインの名前解決がまるごと止まるため、Aレコードを1行足すだけの変更でも検証コマンドは挟みます。

AAAA・CNAME・ALIASとAレコードの使い分けと注意点

IPv4のAとIPv6のAAAA、名前を返すCNAMEの違い

混同しやすい3つのレコードを対比します。AレコードはIPv4アドレスを、AAAAレコードはIPv6アドレスを返し、どちらも右辺はアドレスです。AAAAレコードはRFC 3596（DNS Extensions to Support IP Version 6）で定義され、128ビットのIPv6アドレスを1個持ちます。対してCNAMEレコードの右辺はアドレスではなく別の名前で、「この名前は実体としてあちらの名前」と別名を張る仕組みです。CNAMEを引いた解決側は、示された先の名前をあらためて引き直してAレコード（またはAAAA）へ到達します。IPv4とIPv6の両方でサービスを公開するなら、同じ名前にAとAAAAを併記するのが一般的な構成です。

レコード	右辺が返すもの	主な用途	ゾーン頂点(apex)への設置
A	IPv4アドレス	名前をIPv4へ対応付け	可
AAAA	IPv6アドレス	名前をIPv6へ対応付け	可
CNAME	別の名前	別名（www→本体など）	不可（規格上置けない）

ゾーン頂点でCNAMEが使えない制約とALIAS/ANAMEでの回避

実装で最初にぶつかる制約が、ゾーンの頂点（example.com そのもの、いわゆるネイキッドドメイン）にはCNAMEを置けない点です。頂点にはSOAやNSレコードが必須である一方、RFC 2181（Clarifications to the DNS Specification）はCNAMEが同じ名前で他のデータと共存できないと明記しており、両立しません。ところがロードバランサーやCDNのエンドポイントは名前で払い出されIPが変動するため、頂点をそこへ向けたいときにCNAMEが使えず困ります。前段に置く機器の選択そのものを整理したい場合はロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説【2026年版】、配信側の都合を押さえたい場合はCDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説が前提整理に使えます。

この回避策として各社が用意するのがALIAS（Route 53のAlias、他社ではANAME等の名称）で、権威側が対象の名前を解決してAレコードとして応答する擬似レコードです。AWSのAlias レコードと非Alias レコードの選び方（公式ドキュメント）では、AliasがELBやCloudFrontなどAWS側のリソースを対象に取れること、Aliasのクエリに課金しない扱いであることが説明されています。利用者から見た応答はAレコードなので頂点にも配置可能です。素のDNSにはこの機能がなく、事業者ごとの拡張である点は設計時に確認します。

複数Aレコードによるラウンドロビンと内部向けAレコードの設計

同名に複数のAレコードを置くDNSラウンドロビンの挙動と限界

1つの名前に複数のAレコードを登録すると、権威DNSサーバーは応答のたびに順序を入れ替えて複数IPを返します。これがDNSラウンドロビンで、問い合わせごとに先頭のIPが変わるため、結果的にアクセスが複数サーバーへ分散する仕組みです。同じ名前・同じタイプのレコード群はRFC 2181の言うRRSetとして扱われ、同一RRSet内のTTLは揃えるべきだとされています。片方だけTTLを短くするような書き方は、キャッシュ側で解釈が割れる原因になるため避けます。

ただしこれは粗い分散であり、正確な負荷分散ではありません。サーバーがダウンしてもDNSは死活を見ずにそのIPを返し続け、TTLの間はクライアントが故障IPを掴む恐れがあります。可用性を担保するなら、DNSラウンドロビン単体に頼らず、死活監視と連動するロードバランサーや、後述するフェイルオーバー機能を併用する設計が要ります。

内部システム向けAレコードとプライベートDNSでの管理と設計

社内システムやクラウドのVPC内部では、外部に公開しないプライベートIPをAレコードで名前に対応付けます。この内部向けのAレコードは、社内DNSやクラウドのプライベートホストゾーンで管理し、インターネットの権威DNSには載せません。AWSでの具体的な仕様はプライベートホストゾーンの使用（公式ドキュメント）にあり、VPCに関連付けたホストゾーンの内容がそのVPC内からのみ解決されることが示されています。同じ名前を外部と内部で別のIPへ解決させる構成（スプリットビュー）もこの仕組みで実現します。

内部名前解決の設計はプライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説で扱っており、どのAレコードを外に出しどれを内に閉じるかの線引きが設計の勘所です。内部Aレコードを誤って公開ゾーンへ書くと、社内アドレス構成が外部から読めてしまうため、公開範囲は登録先ゾーンで厳密に分けます。公開ゾーン側の応答そのものを改ざんから守る話は別軸で、署名による検証の仕組みはDNSSECとは？DNSの安全性を守る仕組みと役割・導入手順をわかりやすく解説にまとめています。

クラウドでのAレコード設計とdigコマンドでの確認・切り替え手順

Route 53などマネージドDNSでのAレコードとフェイルオーバー設計

クラウドのマネージドDNSでは、Aレコードに各社固有の付加機能を組み合わせます。ロードバランサーやCDNを頂点へ向けるにはAlias、複数リージョンの切り替えにはヘルスチェックと連動したフェイルオーバールーティング、地理や遅延に応じた振り分けには対応するルーティングポリシーを、いずれもAレコード（またはAlias）に紐づけて設定します。フェイルオーバーの構成条件はDNSフェイルオーバーの設定（公式ドキュメント）にあり、プライマリとセカンダリのレコードにヘルスチェックを結び付ける形が基本形です。DNSラウンドロビンでは拾えなかった「故障時に生きているIPだけを返す」挙動が、ここで実現できます。Route 53側の機能全体を先に俯瞰したい場合はAmazon Route 53とは？DNS・ドメイン登録・ルーティング設計を実装者目線で解説を参照してください。

こうしたAレコードのルーティング設計や、ハイブリッド構成での内部・外部の名前設計は初期の切り分けが難しく、要件に合わせた設計から任せたい場合は一創のインフラ構築（AWS・Google Cloud・Azure）でご相談ください。名前が正しいIPへ解決されるかは可用性そのものに直結するため、冗長化とあわせて初期設計で固めます。

AWS CLIでRoute 53のAレコードを作成・更新するJSON例

Route 53のAレコードをコンソールではなくCLIから入れ替える場合、変更内容をJSONで渡します。UPSERTは「無ければ作成、あれば置換」の指定で、切り替え作業ではこれを使うと既存レコードの有無を気にせず適用できます。

{
  "Comment": "switch www A record to 192.0.2.11",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com.",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [
          { "Value": "192.0.2.11" }
        ]
      }
    }
  ]
}

このファイルをchange-a.jsonとして保存し、次のコマンドで適用します。適用結果はPENDINGで返り、全ネームサーバーへ行き渡るとINSYNCへ変わります。

aws route53 change-resource-record-sets \
  --hosted-zone-id Z123456789EXAMPLE \
  --change-batch file://change-a.json

aws route53 list-resource-record-sets \
  --hosted-zone-id Z123456789EXAMPLE \
  --query "ResourceRecordSets[?Type=='A']"

2本目で適用後のAレコードだけを抜き出して確認できます。TTLの値もここに出るので、切り替え前にTTLを下げたつもりが反映されていなかった、という取り違えを事前に潰せます。

digでAレコードを確認する手順とTTLを踏まえた切り替えの実務

Aレコードの確認はdigが第一候補です（Windowsは標準のnslookupでも確認できます）。よく使う形は次の通りです。

dig www.example.com A +short：AレコードのIPv4アドレスだけを簡潔に表示。
dig www.example.com A +noall +answer：TTL付きで回答行を確認。
dig www.example.com A @8.8.8.8：問い合わせ先のキャッシュDNSサーバーを明示して切り分け。
dig www.example.com AAAA +short：対になるIPv6（AAAA）の有無も併せて確認。

回答行がwww.example.com. 300 IN A 192.0.2.10なら、左から名前・TTL・クラス・タイプ・値で、TTLは300秒です。Aレコードを別IPへ切り替える作業では、まず数日前にTTLを短く（例：300秒）下げておき、旧IPのキャッシュが各所から抜けるのを待ってから値を書き換えます。切り替え後に旧サーバーへ届く残存アクセスがTTLの経過で収束したのを確認し、TTLを元へ戻すのが定石です。ステータスがNXDOMAINなら名前自体が無く、応答はあるがAが無いなら他タイプ（CNAMEやAAAA）だけが登録されている状態を疑います。

Aレコードが引けないときにdigの応答から原因を切り分ける手順

NXDOMAINとNOERROR/NODATAを見分けて登録漏れを特定する

「Aレコードが引けない」と言われたとき、まず見るのはdigのstatus行です。NXDOMAINはその名前自体がゾーンに存在しない状態で、レコードの書き忘れかゾーンの取り違えを疑います。statusがNOERRORなのにANSWER SECTIONが空（ANSWER: 0）なら、名前は存在するがAというタイプのデータが無い状態で、CNAMEやAAAAだけを入れたケースがほとんどです。SERVFAILは権威側の応答不全やDNSSEC検証の失敗を含み、レコードの中身より配信側の問題を先に見ます。

digのstatus	読み取れる状態	次に見る場所
NXDOMAIN	名前そのものが無い	ゾーンの綴りと登録漏れ
NOERROR / ANSWER 0	名前はあるがAが無い	CNAMEやAAAAの有無
SERVFAIL	権威側の応答不全	ゾーン読込とDNSSEC
NOERROR / 旧IP	キャッシュが残存	回答行のTTL残り秒数

権威サーバーへ直接問い合わせてキャッシュの影響を切り離す確認

キャッシュDNS経由の応答は、書き換え直後ほど当てになりません。権威サーバーへ直接、しかも再帰を切って聞けば、いま配信されている値そのものを読めます。次の順で叩くと、権威の値・経路・キャッシュの差が分かれて見えます。

dig example.com NS +short
dig @ns1.example.com www.example.com A +norecurse +noall +answer
dig www.example.com A +trace
dig www.example.com A @8.8.8.8 +noall +answer
dig www.example.com A +nssearch

2本目で新しいIPが返り、4本目で旧IPが返るなら、権威は更新済みでキャッシュだけが古い状態です。この場合は回答行のTTL残り秒数を見て待つのが正解で、レコードを触り直しても解決しません。逆に2本目の時点で旧IPなら、変更がそもそも配信に載っていないため、ゾーンの反映（Route 53ならINSYNCかどうか、BINDならシリアル値の更新とreload）へ戻ります。5本目の+nssearchは各権威サーバーへ順に聞く形で、複数台のうち1台だけ古いといった不揃いを見つけられます。

よくある質問

Aレコードの実務でつまずきやすい点を、5つの質問に絞って答えます。

AレコードとAAAAレコードは両方登録すべきですか？

IPv6でもサービスを公開するなら、同じ名前にAレコード（IPv4）とAAAAレコード（IPv6）を併記します。多くのクライアントはRFC 8305（Happy Eyeballs Version 2）の考え方に沿ってAAAAとAを並行して問い合わせ、IPv6を先に試しつつ遅ければIPv4へ回るという挙動です。IPv6の受け口を用意していないのにAAAAだけ残っていると、IPv6優先の端末で接続が遅延・失敗することがあるため、公開する実体に合わせてAとAAAAの整合を取ります。IPv4のみで公開するなら、Aレコードだけで問題ありません。

AレコードとCNAMEレコードはどう使い分けますか？

名前を直接IPv4アドレスへ向けるのがAレコード、ある名前を別の名前の別名にするのがCNAMEです。IPが固定のサーバーへ向けるならA、複数の名前を1つの本体名にまとめたいならCNAMEが向きます。ただしCNAMEはゾーンの頂点（example.com そのもの）には置けず、同名に他のレコードを共存できないのが規格上の制約です。頂点をロードバランサーへ向けたいときはAレコードか、Route 53のAlias等の擬似レコードを使います。

ルートドメイン（example.com）にAレコードは設定できますか？

設定できます。ゾーンの頂点にAレコードを置くのは規格上問題なく、固定IPのサーバーへ向けるなら頂点に直接Aレコードを書く形です。問題になるのは、頂点をIPが変動するロードバランサーやCDNへ向けたい場合で、そこではCNAMEが使えないためAliasやANAMEといった事業者拡張を用います。固定IPならAレコード1本で完結し、変動する宛先なら拡張機能を検討する、という切り分けです。

Aレコードを変更したのに反映されないのはなぜですか？

各所のキャッシュにTTLの秒数だけ古いIPが残るためです。digの回答行のTTL値が保持時間で、これがゼロになるまで新しいIPは配られません。切り替え作業の前にTTLを短く（例：300秒）下げ、旧値の伝播が抜けるのを待ってから書き換え、完了後に戻すのが定石です。権威が更新済みかどうかはdig @権威サーバー名前 A +norecurseで切り分けられます。加えてブラウザやOSのローカルキャッシュも残るため、端末側でのキャッシュクリアも合わせて確認してください。名前解決全体の伝播やキャッシュの考え方は名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説で整理しています。

1つの名前に複数のAレコードを登録するとどうなりますか？

権威DNSサーバーが応答のたびに順序を入れ替えて複数IPを返し、DNSラウンドロビンとしてアクセスが分散します。ただしDNSは各IPの死活を見ないため、故障したサーバーのIPもTTLの間は返り続けるのが弱点です。障害時に自動で生きたIPだけを返したいなら、ヘルスチェックと連動するマネージドDNSのフェイルオーバーや、前段のロードバランサーを併用します。複数Aレコードは手軽な分散ですが、可用性の担保には別の仕組みを重ねる前提で設計します。