logo标签列表

我为什么不能为“google.ca”设置一个A记录，将其指向我想要的任意IP地址呢？

networkingdnscname
当我将我的GoDaddy域名指向运行我的Web服务器的GCP VM的IP地址时，我所要做的只有这些： 1. 将GoDaddy的域名服务器更改为GCP的域名服务器 2. 在GCP的DNS中为我的域名创建A/CNAME/SOA记录来指向我的IP地址 实际上，什么阻止我对世界上的任何域名做同样的操作呢？

Screenshot

我为google.ca创建了一个CNAME、A和SOA条目，指向我的虚拟机外部公共IP地址，没有遇到任何阻碍。现在我并不期望所有的Google流量都开始指向我想要的地方（那将是一次有趣的DDOS攻击），但这里发生了什么？我错过了什么？ 我的意图并不不道德。我只是想要学习它是如何工作的。
2我不使用GoDaddy，但在我的DNS主机上，当它显示类似于domain.something.的时候，最后的点表示它仍然是我正在编辑记录的某个域名的子域名。你确定你实际上没有为google.ca.mydomain.com创建记录吗？ - Logarr
18@Logarr 你确定吗？通常情况是相反的：没有最后的点，域名是相对的；有最后的点，域名是绝对的。 - Marcel Krüger
2恭喜！你找到了一种打破互联网的方式。 - Pablo
最好在图像中隐藏您的公共IP。 - dev-masih
哦，我发现了一个看起来很吓人的大红色按钮。我们来试试它能做什么吧！（别担心，只是试一下是正确的做法。而且相当有趣！） - Volker Siegel
1别忘了接受其中一个答案！如果你需要进一步的解释，请不要犹豫地提问。 - Daniel B
7个回答
没有什么能阻止你。然而，也没有人会去关注。这是因为真正的域名没有指向你的名称服务器（GCP DNS）。只有通过直接向你的名称服务器查询才能获取这些记录。 DNS查询从根开始： 
$ dig google.ca +trace

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> google.ca +trace
;; global options: +cmd
.                       68215   IN      NS      h.root-servers.net.
.                       68215   IN      NS      k.root-servers.net.
.                       68215   IN      NS      i.root-servers.net.
.                       68215   IN      NS      g.root-servers.net.
.                       68215   IN      NS      a.root-servers.net.
.                       68215   IN      NS      b.root-servers.net.
.                       68215   IN      NS      d.root-servers.net.
.                       68215   IN      NS      f.root-servers.net.
.                       68215   IN      NS      l.root-servers.net.
.                       68215   IN      NS      e.root-servers.net.
.                       68215   IN      NS      j.root-servers.net.
.                       68215   IN      NS      m.root-servers.net.
.                       68215   IN      NS      c.root-servers.net.
;; Received 553 bytes from 192.168.2.5#53(192.168.2.5) in 31 ms

ca.                     172800  IN      NS      c.ca-servers.ca.
ca.                     172800  IN      NS      x.ca-servers.ca.
ca.                     172800  IN      NS      any.ca-servers.ca.
ca.                     172800  IN      NS      j.ca-servers.ca.
;; Received 626 bytes from 202.12.27.33#53(m.root-servers.net) in 24 ms

google.ca.              86400   IN      NS      ns1.google.com.
google.ca.              86400   IN      NS      ns2.google.com.
google.ca.              86400   IN      NS      ns3.google.com.
google.ca.              86400   IN      NS      ns4.google.com.
;; Received 603 bytes from 199.253.250.68#53(x.ca-servers.ca) in 42 ms

google.ca.              300     IN      A       172.217.16.163
;; Received 54 bytes from 216.239.32.10#53(ns1.google.com) in 22 ms
通常情况下，您不会自己执行迭代查询。递归DNS服务器会为您执行，速度更快。
7如果他控制了给定网络的名称服务器（例如企业内部网络的名称服务器），那么他就可以搞些恶作剧，因为它将是特定用户计算机首先查询的服务器。 - nick012000
1如果没有其他名称服务器提供答案，那么只会询问您自己的名称服务器……由于它们是按层次进行组织的，您可以假设大多数知名地址在您的名称服务器被询问之前已经解析了。有恶意意图的人会对较高级别的名称服务器进行DDoS攻击，以强制层次结构使用他们操纵的名称服务器来解析它 - 是的@nick012000..在他的组织中，他可以耍花招 - 但只针对那些仅使用他（公司）名称服务器的人。大多数人使用额外的名称服务器;-) - eagle275
9值得注意的是，HSTS 是对此进行的一种缓解措施。即使某人设置了具有众所周知站点记录的私有 DNS，并设置了这些站点的虚假版本，用户在尝试访问这些站点时，他们的浏览器将会被重定向到该站点的 HTTPS 版本，这可能会失败或显示无效证书警告。 - saucecontrol
@saucecontrol，如果你控制某个域名的DNS，那么你应该能够为它获取一个Let's Encrypt证书。 - ilkkachu
8@ilkkachu HSTS的缓解措施是为了应对一个将私有DNS服务器解析到恶意IP的情况，而不是访问权威名称服务器。Let's Encrypt会从多个位置解析该网站，并在颁发证书之前从多个IP进行查询。HKP将进一步防范恶意证书。 - Tyzoid
@nick012000，那他不会长久地负责那个公司的域名服务器，对吧？ - Dave
@eagle275，这并不完全正确。在拥有自己内部域名服务器的网络中，大多数情况下会首先查询这些服务器，而且很容易配置它们不对特定的域名进行递归查询。但是请注意，还请参阅我对nick012000的回复。 - Dave
聊天在这里，好吗? - Daniel B
7@nick012000除了恶作剧之外，这是一个完全有效的应用公司政策的方法。例如，你可以让Facebook或YouTube的浏览器请求转到公司政策备忘录（或者像我们为一个客户所做的那样，转到本地的职位网站）。 - fraxinus
@Tyzoid 不好意思，但是HKP是什么意思？ - iBug
@nick012000 这有点像防火墙的作用（大致上来说）。一旦你控制了域名服务器，你就能控制对外界的访问。这只是控制内部网络的一部分。我猜谁控制了内部网络就可以利用这种控制进行“花招”。 - Acccumulation
@saucecontrol 如果他们在本地网络上建立了一个恶意的证书颁发机构呢？ - PyRulez
3@PyRulez 要么你的电脑默认忽略了未知的证书颁发机构，要么你的电脑是属于那家预先安装了“恶意”证书颁发机构的公司的财产。在后一种情况下，可能是因为电脑更听从所属公司的意愿而不是你的意愿... - Hagen von Eitzen
@nick012000（假设是指“不会能够”）是的。如果他控制了一个DHCP服务器，将人们指向本地DNS服务器，本地DNS服务器可以提供这样的错误信息。（客户端可以通过手动选择一个已知的公共DNS服务器来覆盖此设置。） - TOOGAM
@HagenvonEitzen 好的，通常情况下，CAs都是预装的。这很合理。谢谢！ - PyRulez
（为了简洁起见，我删除了DNSSEC相关的内容。）下次只需在dig命令行中添加+nodnssec，它就不会显示与DNSSEC相关的信息（这与是否进行DNSSEC验证是无关的，这是通过+cd标志来控制的）。请注意，您可以省略标志，所以我经常使用+nodns来迷惑人们...（“等等，没有DNS的dig？”） - Patrick Mevzek
如果他控制了特定网络的名称服务器（例如企业内部网络的名称服务器），那么他就可以做一些花招，因为这将是某个用户计算机首先咨询的服务器。是的，但随着DNS over TLS和更多的浏览器使用DNS over HTTPS的出现，像Firefox这样的浏览器完全忽略本地DNS设置，只会向CloudFlare发出DNS解析请求，这种情况将越来越少。 - Patrick Mevzek
值得注意的是，HSTS是对此进行缓解的一种方法。除非您固定密钥，否则并非如此。如果您控制解析过程，获取DV证书就很容易，因此HTTPS是安全的。另一方面，DNS TLSA记录是对此进行缓解的一种方法（这就是DANE，在其中您基本上将证书的部分编码到DNS中），但只有在使用DNSSEC的情况下才有效，即使您控制解析过程，也无法使响应成为DNSSEC有效。 - Patrick Mevzek
@iBug HKP实际上是HPKP或HTTP公钥固定。这允许网站告诉浏览器：请仅接受具有公钥为X或Y的证书的HTTPS连接（简而言之）。这基本上确保您无法连接到假冒网站，但使用另一个证书。然而，在实践中，这不再是一个真正的解决方案：浏览器正在逐渐淘汰它，转而使用证书日志，并且您仍然面临首次访问的问题（如何传播正确的密钥以供使用？）。DNS TLSA记录是一个更好的解决方案。 - Patrick Mevzek
假设现在是1980年，电话簿仍然存在。你有什么阻止你去电话簿中找到Kmart的电话号码，并将其替换为你店铺的电话号码呢？绝对没有。你可以自由地这样做，如果你使用那本电话簿，每次你试图打电话给Kmart时，你都会得到你自己店铺的电话。你可以随心所欲地重新标记电话号码。 问题是，其他人也有他们自己的电话簿，他们并不会看你的。除非你能闯入电话公司并在那里更改Kmart的电话号码，以便他们发送出去的电话簿上有你的商店号码，否则你无法剥夺Kmart的任何业务。 同样地，如果你决定厌倦了输入那个需要很长时间才能完成的超长域名，并且不想依赖自动补全，你可以自由地设置一个服务器，让short.com解析为那个超长域名的IP地址，并让你的计算机使用该服务器来解析域名。但是，除非你能让其他人的计算机也使用那个服务器，否则你无法影响他们在地址栏中输入short.com后发生的事情。
9基本上，这就像把“美国总统”这个头衔放在你的名片上。世界上大多数人都不会见到一个。那些看到的人中，大多数人会翻个白眼然后忽略它。 - ceejayoz
3@ceejayoz 前两句话正确，第三句话是错误的。在这种情况下，您的计算机会说“嗨，总统先生！”。问题是，如果您的计算机甚至查看了该名片，它就无法知道它不是真的。您希望您的计算机根本不检查名片，而是检查您真正信任的唯一好的名片目录。如果您的计算机被某种方式制造成认为询问（被黑客/欺骗的）DNS服务器B比正常的DNS服务器A更好，那么您的计算机将不会翻白眼，并相信您是总统。 - quetzalcoatl
1@quetzalcoatl 这个类比并不完美，但第三句话的意思是要说明在你的伪造服务器上获取google.ca的有效证书将会有多么困难。 - ceejayoz
@ceejayoz 证书与DNS有什么关系？如果没有HTTP+S，情况就会变得很糟糕。计算机连接到假冒的google.ca这一事实证明了DNS欺骗成功。这就是我所说的“那些计算机不会翻白眼”的意思。 - quetzalcoatl
1@quetzalcoatl 你可以将google.ca的记录指向任何地方，但无论指向哪里都不会有有效的证书。由于现在浏览器会对诸如密码字段提交到HTTP的事情表示不满，这对DNS劫持来说又是一个致命打击。 - ceejayoz
很棒的回答。但是我更有可能注册一个非常长的域名，需要花费很长时间才能输入完整的incrediblylongdomainnamethattakesaridiculouslylongtimetotype.com（因为，谁需要计算输入所需的时间呢？） - TOOGAM
这是一个很好的回答 - Asteroids With Wings
电话簿还有人用吗？我四个月前订购了最新版的白页和黄页。现在新年到了，我需要再次订购一份。可惜现在他们不再自动寄送了，至少白页是这样。 - InterLinked
所以我的问题是，有什么阻止我在世界上的任何领域做同样的事情呢？事实上，我已经这样做了。 困难的部分是获取那些数据，包括安装在.ca域名服务器上的您的域名服务器的NS记录。他们可能不会让你这样做，第三方将通过从根服务器向下查询域名服务器来解析域名，因此首先是全球根服务器，然后是.ca域名服务器，最后是.google.ca域名服务器。 当然，如果您在组织的域名服务器中安装这些记录，那么组织内的任何人都可以看到您设置的数据。（嗯，假设他们使用组织的域名服务器，而不是直接使用8.8.8.8之类的东西。）但是，当有人尝试在那里打开HTTPS连接时，他们会收到错误，因为没有任何机构外部的CA会为该域名签署您的密钥。（当然，您可以通过在组织内部建立自己的CA来规避这个问题，但那是另外一个故事。）
4实际上，在组织的机器内部，HTTPS仍然可以被拦截。如果您的组织正在设置组织名称服务器，它们可能也在分发内部证书颁发机构（例如，使用群组策略）。这在证书固定中仍然会失败，前提是固定本身没有被拦截和丢弃。请注意，公钥固定已经被弃用，尽管我相信谷歌Chrome硬编码了一些谷歌域的根证书。 - Brian
3@Brian 即使进行了固定，浏览器通常会接受任何非默认的证书颁发机构，无论是否固定了不同的CA。这是为了支持组织级HTTPS拦截而特意设计的，这通常被认为是一个合理的使用情况。 - cpast
DNS TLSA记录允许域名所有者根据服务的需求选择应该接受哪些证书/CA。不幸的是，在SMTP领域中，这一功能的使用要比在HTTP领域中更为广泛传播。 - Patrick Mevzek
我认为，更好的表达方式是说，虽然你可以这样做，但它不会影响你为其创建的域名。 设备尝试连接到一个IP地址时，它会从多个位置进行查找： 1. 它搜索本地主机文件条目，以了解如何解析该域名。 2. 如果没有找到条目，那么它会检查域名服务，以查找注册商设置的名称服务器。 3. 这些名称服务器然后指定一个权威的DNS区域文件进行引用。 4. 区域文件提供了权威的A记录。 因为你创建的区域文件不在公共的参考链上，所以它不会影响公共流量。 然而，在适当（或错误）的情况下，它可能会影响本地流量，比如在某些原因下先检查本地DNS而不是权威DNS的机器上（类似于在本地主机文件中为主机名指定IP地址），例如邮件路由。例如，如果服务器设置为本地邮件路由，但权威MX记录指向远程机器，则从本地机器发送的邮件可能会根据本地信息而不是权威信息进行内部路由。 所以，最好情况下这只是浪费时间。最糟糕的情况下，它将会搞乱你自己的东西。
尝试通过https://howdns.works进行了解。 它以非常有趣和易懂的方式涵盖了迭代和递归DNS以及其工作原理。 Daniel提供的答案基本上包含了所有必要的内容。
这种东西很有用！我曾经设置防火墙为AOL，这样客户的用户就可以通过同一TCP端口的防火墙代理访问AOL。

htst会给你造成问题。浏览器已经知道要将流量指向何处。它的系统内部运作方式对我来说还有点不清楚，但由于这与DNS记录解析有关，我们只需要专注于那一点，因为你的记录没有设置在权威DNS上，而google.ca是由负责.ca域的人路由到使用他们指定的名称服务器。

这种方法永远行不通，因为ARPA运行的顶级DNS服务器不接受来自你的名称服务器对其无法验证来自所指出的经由.ca域处理程序路由的域的更改。因此，这将导致重复（这不好；如果他们认为这是故意行为，可能导致您的域名被吊销），如果提供商的默认名称服务器处理重定向或指向指定的IP地址。

这涉及到很多层次，你必须在与其网络相同的层次上（即托管了DNS记录的层次）进行操作，正如某人所提到的，你可能需要执行DDoS攻击来迫使其失效，或者对受害者进行一些低调的黑客攻击，以使用你的伪造DNS。

要覆盖它的记录，如果系统被入侵的话，可能可以通过防火墙规则来实现，这只是猜测，但也可能有其他不需要系统访问的方法。 我对此的理解是，这里有比我更有经验的人，而且这是一个非常复杂的可视化过程。 可能有几种方法可以绕过这个问题，对于没有通过htst认证/验证的中低端域名来说，但这并不是应该在公开网络上讨论的事情，因为执行这个操作被认为是最严重的网络犯罪基础。 你可以使用这个来拦截，利用与你的网站相同的DNS对易受攻击的域名进行中间人攻击，只需使用同样过时/不安全的提供商，这样的提供商有很多。 互联网是有问题的，这也是为什么我们必须花费无数小时来配置甚至最简单的服务的原因。
3HTST - 你是不是指的是HSTS（HTTP严格传输安全）？如果是的话，HSTS只会告诉浏览器在浏览器已经访问过HTTPS站点或者域名已经预加载的情况下将请求从HTTP升级到HTTPS。DNS在这方面没有任何作用。它所做的只是强制将对http://<domain>的请求自动升级为https://<domain>。 - phuzi
htst是什么？ - Peter Mortensen