问题[cname-record](server)

我们的网站已关闭，因为我们的托管服务提供商已停止营业，并且用于在 AWS 上配置生产和开发服务器的后台域名已过期。我们无法访问此域名，也无法联系到旧提供商的任何人。当前的 DNS 设置如下：

companyname.com [CNAME www is an alias of prod.company-deadhost.com] ->

companyname-deadhost.com [NS ns-2048.awsdns-64.com, ns-2049.awsdns-65.net, ns-2050.awsdns-66.org, ns-2051.awsdns-67.co.uk] ->

[IP we don't know] The website server

我们对 companyname.com 具有完全访问权限，但对 companyname-deadhost.com 没有访问权限，并且我们无法检查是否曾经存在任何 A 或其他记录。我看过 AWS / Route 53 文档，其中说设置域名并使用 Route 53 NS 记录是将 Web 服务器连接到域名所需的全部操作（即，您不需要 IP 地址或任何东西）呃，没有，我还没有 - 看起来我们也需要 IP 地址。

我们无法访问 companyname-deadhost.com，但我可以使用这些 NS 记录（不是上面的记录，我们找到了原始记录）设置一个新的“中间”域，例如：

companyname.com [CNAME www is an alias of prod.newmiddledomain.com] ->

newmiddledomain.com [NS ns-2048.awsdns-64.com, ns-2049.awsdns-65.net etc etc] ->

[IP we don't know] The website server

Web 服务器上的流量仍将来自“companyname.com”，并且必须设置 Web 服务器以允许这样做 - 所以它应该可以正常工作？或者尽管如此它还是会失败，因为它来自 newmiddledomain.com 而不是 companyname-deadhost.com。

我需要尽快在域名上获取一些东西，如果这不可能奏效，我宁愿不浪费时间尝试这个并等待 DNS 记录传播...如果没有 EC2 实例的 IP，我们看起来就会陷入困境，所以这更像是一个假设......

我有一个域名，比方说 Sameer.com，在 namecheap 中管理。
还有一个域，product.com，在 AWS Route53 中管理。

Sameer.com 存在以下 DNS 记录：
CNAME quotes.sameer.com sameer.product.com
CAA sameer.com 0 issue "lenscrypt.org"

以及product.com 的以下记录：
A *.product.com <AWS_LOADBALANCER>

现在，如果我运行dig quotes.sameer.com，它会解析为 AWS 负载均衡器 IP 地址。

到目前为止，一切都很好。

现在，如果我尝试通过 AWS 为域颁发证书quotes.sameer.com，ACM 会抛出 CAA 错误，因为不允许 Amazon 颁发证书。

现在我可以做两件事。

1. 在根域 Sameer.com 下添加 CAA 记录（在 namecheap 中）
2. 在 Sameer.product.com 下添加 CAA 记录（在 Route53 中）

现在，如果我添加 CAA 记录
CAA sameer.product.com 0 issue "amazon.com"，
AWS 就能够成功颁发证书。

但是，一旦我添加此 CAA 记录，该dig quotes.sameer.com命令就无法解析。
当我 时ping quotes.sameer.com，它显示“未知主机”。

我认为 CAA 记录不应干扰解析 CNAME。
请帮忙。我在这里缺少什么？

如果我跑

dig @ns5.laposte.net conversation.ees.labanquepostale.fr A

我得到一个 SERVFAIL，但如果我运行

dig @ns5.laposte.net conversation.ees.labanquepostale.fr CNAME

我得到了我的 CNAME：

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48072
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;conversation.ees.labanquepostale.fr. IN    CNAME

;; ANSWER SECTION:
conversation.ees.labanquepostale.fr. 300 IN CNAME prod-lbpee.web-application-front-customer.as8677.net.

我想知道这种行为有多有效（至少要知道我们是否可以期望这种行为会更频繁地发生），并且从RFC 1034我可以看到：

• If a CNAME RR is present at a node, no other data should be present
• When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response

所以我认为这不是标准行为。我也没有在“常见的 DNS 操作和配置错误”中看到任何建议。有没有人对这类问题有建议或经验？如果名称服务器回复 REFUSED 或 SERVFAIL，我想这里只是为了寻找 CNAME？

我已经使用 Route53 中的 CNAME 记录将旧子域重定向blog.mysite.com到我的主页mysite.com，但是....它不起作用。我根本没有得到服务器响应。

有什么我做错了吗？

更新：现在我从 Cloudfront 获得 403。

由于知识上的差距，我在 Azure 上设置了一个 Windows VM，然后我去了 Namecheap 并注册了一个域。在某个地方，我想到了针对 @ 和 FQDN 输入 CNAME 记录，并且它有效。

在我的姓名记录中，针对 Azure VM FQDN 的 CNAME 字面上有 2 个条目 @ 和 www。一切都很顺利。

昨天，我正在为其工作的人去切换不在 Namecheap 的计划域上的名称服务器（我使用的是我在 Namecheap 注册的虚拟域）并且无法做我所做的，我们花了几个小时调查它。

今天，我使用了一个工具来查找站点，似乎 Namecheap 使用我提供的域来查找 IP 地址并针对该 IP 输入 A 记录，但它没有出现在管理页面上。所以它是在后台完成的。昨天我重置了 VM，IP 发生了变化，几分钟后域就恢复了。

这有多正常？这有多稳定？我在 Azure 上没有专用 IP。

我现在明白非 www 域上的 @ 是不正常的（即通常不能将 @ 放在 CNAME 记录中）。但是是否有信誉良好的域名托管服务商免费提供这项服务？它是我可以搜索的吗？（第二个问题是 Namecheap 目前不愿意转移这个域，因为显然 .com.au 域很难转移）。

如果这种情况很少见，我唯一的选择是向 Azure 支付静态 IP 并使用 A 记录吗？

我正在使用 Cloudflare（无代理）来管理 DNS 记录。我有两台带 IP 的服务器：

• 128.xxx.xxx.xxx
• 174.xxx.xx.x

这些是我创建的 DNS 记录：

现在，我想将主域（example.com）指向新 IP（174.xxx.xx.x），子域（sub1、sub2、sub3）继续使用 128.xxx.xxx.xxx。

我当然可以通过将所有子域指向 IP 128.xxx.xxx.xxx 来将每个子域的 DNS 记录更改为类型 A，如下所示：

问题是，我有很多子域，而且数量还在增长，我不想手动为子域写IP，除了很多，我还担心我以后会切换不同IP地址的服务器。

有没有办法解决这个问题？

我真的很感激任何答案，在此先感谢。

我有一个看起来像这样的 DNS 配置：

www.example.com                 600  IN   CNAME prod.myzone.l2.company.example
prod.myzone.l2.company.example      600  IN   CNAME ssl-endpoint-12345.hostcorp.example
ssl-endpoint-12345.hostcorp.example 60   IN   A     192.0.2.4

所以链中前两条 CNAME 记录的 TTL 为 10 分钟，最后一条 A 记录的 TTL 为 1 分钟

CNAME在prod.myzone.l2.company.example多个端点之间进行区域负载平衡，如果我的 DNS 提供商确定当前端点不健康，它会自动更新。出于这个原因，我想尽快将更改传播到prod.myzone.l2.company.exampleCNAME。

如果我想减少客户在prod.myzone.l2.company.example更改时看到的整体 TTL，仅减少prod.myzone.l2.company.example记录的 TTL 就足够了，还是我还需要减少www.example.com记录上的 TTL？

我在现有的主域下有几个子域，例如：

eg.domain1.com
ie.domain1.com

该公司正在更名，并设置了一个新的主域，所有这些子域现在都需要存在于相同的 DNS IP 地址下，例如：

eg.domain2.com
ie.domain2.com

我需要将旧的子域重定向/转发到新的子域，例如：

sub.domain1.com -> sub.domain2.com
dom.domain1.com -> dom.domain2.com

这两个域都托管在 Network Solutions 上。我尝试设置 Web 转发来进行重定向，但 Network Solutions 表示 Web 转发无法做到这一点，并且在寻找任何其他解决方案方面没有提供任何帮助。

我也尝试删除“旧”域的 A 记录并添加 CNAME 记录以将旧子域别名为新子域，但等待 18 小时左右后，更改仍未生效。

有没有其他方法可以做到这一点？

我有一个在 Azure 上运行的 webapp，并使用 Google Domains 作为域名 (mywebapp.com) 和 DNS。Azure 自动为不同的资源/服务生成 URL（例如：https://black-cat-12345.azurestaticapps.net、https://my-webapp-api.azurewebsites.net），我使用 CNAME 创建子域：

mywebapp.com  A  3600  {Google IP}
mywebapp.com  MX  3600 {Google mail servers}
mywebapp.com  SPF  "v=spf1 include:_spf.google.com ~all"

login.mywebapp.com  CNAME  3600  black-cat-12345.azurestaticapps.net
api.mywebapp.com  CNAME  3600  my-webapp-api.azurewebsites.net
etc

我被告知强烈考虑为子域添加 SPF 记录以防止邮件欺骗和网络钓鱼电子邮件，但根据为一个子域添加 CNAME 和 TXT DNS 记录，我在使用 CNAME 时不能有 SPF 记录。我不知道如何实现这一目标。

如果我从不从子域发送邮件，并且没有 MX 记录，是否需要 SPF 记录？

如果我应该添加 SPF 记录，是通过将 CNAME 更改为 A 记录来实现此目的的唯一方法吗？我不能使用 Azure 资源/服务的底层 IP（例如：my-webapp-api.azurewebsites.net -> 52.175.36.249），所以我对想法持开放态度。

更新：我在这篇文章的底部附加了第二次尝试。它正在“工作”，但我想让我最初的想法发挥作用。

我正在尝试通过重定向服务器将域的 https 请求重定向到另一个域。

我将使用https://website.com,https://website2.com和https://myredirectserver.com作为示例。

我购买了一个 SSL 证书website.com，它的 DNS 是 CNAMEDwww到的myredirectserver.com。也有一个 SSL 证书mywebsite2.com，它目前位于服务器上。一切都很好作为一个独立的域。

myredirectserver.com有两个指向两个 IP 地址的流量管理 A 记录（高可用性）。

这两个 IP 地址在防火墙中通过 NAT 转换为代理服务器。

在该代理服务器上，有一个运行 Alpine/Nginx 的 Docker 容器。

容器的 Dockerfile：

FROM nginx:1.17.7-alpine    
RUN apk add --no-cache tzdata    
ENV TZ America/Chicago    
RUN rm /etc/nginx/conf.d/default.conf    
COPY myredirectserver.com.conf /etc/nginx/conf.d/myredirectserver.com.conf
RUN rm /etc/nginx/nginx.conf    
COPY nginx.conf /etc/nginx/nginx.conf    
COPY myredirectserver.com.crt /etc/nginx/ssl/myredirectserver.com.crt    
COPY myredirectserver.com.key /etc/nginx/ssl/myredirectserver.com.key    
COPY proxy_params /etc/nginx/proxy_params

启动它的docker run部分（通过后端代码安装了用于动态配置文件创建的卷）：

docker run --name=myredirectserver --restart always --log-opt max-size=50m --log-opt max-file=5 -d -v /etc/nginx/myredirectserverBuild:/etc/nginx/myredirectserverBuild -v /etc/nginx/myredirectserverSSL:/etc/nginx/myredirectserverSSL -p 8224:443 -p 8223:80 myredirectserver

在该 Docker 容器中，Nginx 配置文件位于/etc/nginx/conf.d/myredirectserver.com.conf：

 #I DO NOT KNOW IF THIS IS CORRECT FOR WHAT I NEED
    server {
                listen 443 ssl;
    
                server_name myredirectserver.com www.myredirectserver.com;
                ssl_certificate /etc/nginx/ssl/myredirectserver.com.crt;
                ssl_certificate_key /etc/nginx/ssl/myredirectserver.com.key;
            }
            server {
                listen 80;
                server_name myredirectserver.com www.myredirectserver.com;
                return 301 https://www.myredirectserver.com$request_uri;
            }
    
    include /etc/nginx/myredirectserverBuild/*.conf;

最后的包含文件包含原始请求的域，mywebsite.com.conf：

 ## www.mywebsite.com virtual host
        server {
            listen 443 ssl;

            server_name mywebsite.com www.mywebsite.com;
            ssl_certificate /etc/nginx/myredirectwebsiteSSL/mywebsite.com.crt;
            ssl_certificate_key /etc/nginx/myredirectwebsiteSSL/mywebsite.com.key;               
        }
        server {
            listen 80;
            server_name mywebsite.com www.mywebsite.com;
            return 301 https://www.mywebsite2.com$request_uri; <--- The redirect
        }
        

该website2.com域位于主机服务器上，我可以正常请求该域。我只是无法弄清楚我哪里出错了。我觉得它在我的 Nginx 配置中，但我的 Nginx 语法并不是最好的。为什么我return 301不工作并将我重定向到域？

故障排除期间的几点注意事项：

wget 0.0.0.0:8223返回：

  --2021-07-26 23:44:19--  http://0.0.0.0:8223/
Connecting to 0.0.0.0:8223... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.mywebsite2.com/ [following]
--2021-07-25 23:44:19--  https://www.mywebsite2.com/
Resolving www.mywebsite2.com (www.mywebsite2.com)... XX.XXX.XXX.XXX
Connecting to www.mywebsite2.com (www.mywebsite2.com)|XX.XXX.XXX.XXX|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html                                               [ <=>                                                                                                                  ]  37.56K   231KB/s    in 0.2s    

2021-07-25 23:44:20 (231 KB/s) - ‘index.html’ saved [38461]

curl --resolve www.myredirectserver.com:8223:0.0.0.0 http://www.myredirectserver.com/返回超时，浏览器也是如此。

在本地网络上，在地址栏 ( 192.168.69.140:8223) 中输入 Docker 容器的 IP 会将我带到https://www.website2.com.

输入https://192.168.69.140:8224会将我带到安全飞溅警告页面。单击proceed，它给了我一个404.

我不知所措，因为当请求到达 CNAME 的 IP 时，我不知道如何处理它myredirectserver.com。如何告诉 Nginx 查看原始请求的域website.com？

更新（第二次尝试）：

我停止了 Docker 容器，并将DNSCNAME中的www级别更改为指向一个已经存在的高可用 IP。我会打电话destinationserver.net的。所以基本上：

`mywebsite.com`
|
|---> CNAME 'destinationserver.net'

`destinationserver.net`
|
|----> A XX.XXX.XXX.XXX --> Firewall --> Proxy

|----> A XX.XXX.XXX.XXX --> Firewall --> Proxy

在destinationserver.net服务器上，我在 Nginx 配置中有以下内容website.com：

# ## www.mywebsite.com virtual host
        server {
            listen 8222 ssl;

            server_name mywebsite.com www.mywebsite.com;
            ssl_certificate /etc/nginx/ssl/mywebsite.com.crt;
            ssl_certificate_key /etc/nginx/ssl/mywebsite.com.key;
            return 301 http://www.mywebsite2.com$request_uri;
        }
        server {
            listen 8221;
            server_name mywebsite.com www.mywebsite.com;
            return 301 https://www.mywebsite2$request_uri;
        } 

正如我在问题第一行的“更新”中所述，这是“有效的”，但在单独的空间中处理这些重定向会很好，因此是 Docker 容器的想法。