为应用配置域名解析

介绍

应用已能响应 HTTP 请求，但用户需要通过名称访问它。创建 Route 53 托管区域和 A 记录，观察实际 DNS 应答，再用返回的地址访问预置应用。

请先完成 AWS Foundations。本实验从独立 VM 开始，已提供配置好的 AWS CLI、DNS 查询端点和一个无关的参考区域，无需个人 AWS 账号或购买域名。上方 AWS View 用于观察记录，下方 Terminal 用于执行命令。练习域名以 .test 结尾，本实验不注册或委派公共域名。

认证考点

实验概览

创建应用名称

本步骤为预置应用创建托管区域和 A 记录。

DNS 将名称转换为 IP 地址等信息。托管区域（hosted zone） 保存一个域的记录。A 记录 将名称映射到 IPv4 地址；创建记录不会启动应用或建立网络连接。

域为 labex-n01.test，应用名称为 app.labex-n01.test。预置应用监听 127.0.0.1 的 HTTP 8081 端口。该回环地址指向当前 VM，因此请求保持在练习环境内。

创建区域：

cd /home/labex/project
ZONE_ID=$(aws route53 create-hosted-zone \
  --name labex-n01.test \
  --caller-reference labex-n01-application \
  --query HostedZone.Id \
  --output text)

$(...) 将命令输出保存到 Shell 变量 ZONE_ID。--query 选择新区域的 ID，--output text 使它可作为下一条命令的参数。CallerReference 区分本次创建请求。请保持此 Terminal 打开，以保留变量。

记录变更以 JSON 提供。下方带引号的 here-document 将字面文本写入 record.json。TTL 的单位为秒，告诉 DNS 缓存可复用应答的时长；此端点直接返回权威应答，本实验不测量递归缓存。

cat > record.json <<'JSON'
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

将变更应用到自己的区域。file:// 读取本地 JSON 文件：

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://record.json

响应标识本次变更，证明配置已写入；下一步骤将测试实际 DNS 应答。查看保存的记录：

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

找到应用名称、A、TTL 60 和 127.0.0.1。AWS View 会将该记录显示在自己的区域中，旁边仍有独立参考区域。不要修改参考区域；继续前运行记录检查。

查询 DNS 并访问应用

本步骤区分成功的 DNS 应答、不存在的名称和成功的 HTTP 请求。

dig 是 DNS 查询工具。@127.0.0.1 选择预置 DNS 服务，-p 1053 选择练习端口；+norecurse 请求不进行递归查找的权威应答。这样可以显式测试该服务，而不改变 VM 的系统解析器。

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

应看到 status: NOERROR，ANSWER 记录包含应用名称、TTL 60、类型 A 和地址 127.0.0.1。此 DNS 应答来自实际 Route 53 记录。再查询一个尚未创建的名称：

dig +norecurse @127.0.0.1 -p 1053 missing.labex-n01.test A

预期为 status: NXDOMAIN 且没有应答记录。这表示 DNS 交互成功，但名称不存在，并非无法连接 DNS 服务。AWS View 显示最近一次真实查询及其应答数量。

现在保存地址。+short 仅输出应答：

APP_IP=$(dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A +short)
printf '%s\n' "$APP_IP"

curl 发起 HTTP 请求。--resolve 将刚获得的地址用于此请求的确切名称和端口；它不会注册域名或修改系统 DNS。

curl --fail --noproxy '*' \
  --resolve "app.labex-n01.test:8081:${APP_IP}" \
  http://app.labex-n01.test:8081/

预期输出：

Delivery application ready

DNS 返回地址，HTTP 随后访问该地址上的应用，这是两个不同的结果。有效 DNS 应答本身不能证明应用正在运行。运行查询与应用检查。

仅删除应用区域

本步骤删除自己的记录和托管区域，并观察名称不再解析。

区域中仍有应用记录时，通常不能删除该区域。DELETE 变更必须与原记录的名称、类型、TTL 和值一致。写入相同记录，并将操作设为删除：

cat > delete-record.json <<'JSON'
{
  "Changes": [{
    "Action": "DELETE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

应用删除变更，然后移除已清空的应用区域：

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://delete-record.json
aws route53 delete-hosted-zone \
  --id "$ZONE_ID"

再次查询已删除的名称：

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

预期为 NXDOMAIN。预置应用属于无关的准备资源，进程可能仍在运行：删除 DNS 记录只移除名称映射，并不删除应用本身。AWS View 应仅保留参考区域。运行清理检查。

总结

你创建了托管区域和 A 记录，读取实际 DNS 应答，用返回的地址访问应用，并仅删除自己创建的 DNS 资源。你区分了记录配置、名称解析和应用可用性。接下来学习 CloudFront 如何从受限 S3 源站提供内容。