主页 / user-577131

vinz's questions

Martin Hope
vinz
Asked: 2022-03-22 02:33:36 +0800 CST
  • 0

如果我跑

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？

domain-name-system cname-record
Martin Hope
vinz
Asked: 2022-01-09 03:41:27 +0800 CST
  • 0

如果我们采用以下示例dig allcosts.net @g.gtld-servers.net：

;; QUESTION SECTION:
;allcosts.net.          IN  A

;; AUTHORITY SECTION:
allcosts.net.       172800  IN  NS  ns-22.awsdns-02.com.
allcosts.net.       172800  IN  NS  ns-912.awsdns-50.net.
allcosts.net.       172800  IN  NS  ns-1834.awsdns-37.co.uk.
allcosts.net.       172800  IN  NS  ns-1233.awsdns-26.org.

;; ADDITIONAL SECTION:
ns-912.awsdns-50.net.   172800  IN  A   205.251.195.144

TLD 服务器提供了一个不是粘合记录的附加部分（其 IPns-912.awsdns-50.net肯定可以通过单独的 DNS 查询找到），但信任它的风险是什么？

因为即使这个响应实际上是一个欺骗响应（意味着攻击者实际控制ns-912.awsdns-50.net），无论我们是否信任 ADDITIONAL 部分，在这两种情况下，我们都将获得ns-912.awsdns-50.net属于攻击者的 IP。

在安全性方面，当它们与 AUTHORITY 部分匹配时，不信任 ADDITIONAL 部分有什么意义？

domain-name-system
Martin Hope
vinz
Asked: 2022-01-07 05:03:10 +0800 CST
  • 0

如果我执行以下命令dig allcosts.net @g.gtld-servers.net，我将得到：

;; QUESTION SECTION:
;allcosts.net.          IN  A

;; AUTHORITY SECTION:
allcosts.net.       172800  IN  NS  ns-22.awsdns-02.com.
allcosts.net.       172800  IN  NS  ns-912.awsdns-50.net.
allcosts.net.       172800  IN  NS  ns-1834.awsdns-37.co.uk.
allcosts.net.       172800  IN  NS  ns-1233.awsdns-26.org.

;; ADDITIONAL SECTION:
ns-912.awsdns-50.net.   172800  IN  A   205.251.195.144

根据亚马逊（此处链接）“.net 客户实际上获得了两个 in-bailiwick 胶水记录的好处”，这意味着 ADDITIONAL 被视为 in-bailiwick。

我试图理解为什么“ns-912.awsdns-50.net”。在这里辖区。

RFC 8499显示了类似情况的示例：

   Delegation |Parent|Name Server Name  | Type
   -----------+------+------------------+-----------------------------
   example.org| org  |ns.ietf.org       |in-bailiwick / sibling domain

委托是为allcosts.net，父是net和名称服务器ns-912.awsdns-50.net.。按照 RFC 中的示例，这意味着它是同级域。

这是兄弟域的定义：

Sibling domain: a name server's name that is either subordinate
         to or (rarely) the same as the zone origin and not subordinate
         to or the same as the owner name of the NS resource records.
         Glue records for sibling domains are allowed, but not
         necessary.

如果我理解的话，它们都具有相同的区域起源 ( net) 而不是从属/相同的所有者 ( allcosts.netvs ns-912.awsdns-50.net)，使它们成为兄弟。我在这里做了正确的假设吗？

domain-name-system
Martin Hope
vinz
Asked: 2022-01-06 08:22:42 +0800 CST
  • 1

这是我不明白的辖区规则示例：

adobe.net从net.TLD 服务器解析给出：

;; AUTHORITY SECTION:
adobe.net.  172800  IN  NS  ns1.omtrdc.net.
adobe.net.  172800  IN  NS  ns2.omtrdc.net.

;; ADDITIONAL SECTION:
ns1.omtrdc.net. 172800  IN  A   66.235.157.6
ns2.omtrdc.net. 172800  IN  A   66.235.157.7

并解决ns1.omtrdc.net.给出：

;; AUTHORITY SECTION:
omtrdc.net. 172800  IN  NS  ns201.adobe.net.
omtrdc.net. 172800  IN  NS  ns202.adobe.net.

;; ADDITIONAL SECTION:
ns201.adobe.net.    172800  IN  A   204.74.108.252
ns202.adobe.net.    172800  IN  A   204.74.109.252

如果在这两种情况下都不信任附加部分，则会导致循环。

据我了解，有两条规则：

  • 如果 ADDITIONAL 与 AUTHORITY 部分的 NS 记录不匹配，则不应信任它们，以避免名称服务器发送明显的妥协记录。
  • AUTHORITY 部分 NS 应该是请求域的子集。ns1.omtrdc.net.不是 的子集adobe.net.，因此无法信任附加部分中的 IP。

但是，我已经看到了一些值得信任的实现，因为它们是（回复的 TLD 服务器）ns1.omtrdc.net.的子集。.net

如果我理解得很好（在阅读了一些论文和实现之后），由于 TLD 服务器管理net.区域，我们可以相信 . 下的任何内容net.，即它的 IPns1.omtrdc.net.是adobe.net.

这有意义还是我忘记了一些重要的部分？

domain-name-system
Martin Hope
vinz
Asked: 2021-02-20 00:17:05 +0800 CST
  • 1

根据我的小经验，我们通常会在 ADDITIONAL 部分找到 A 或 AAAA 记录。我正在读一篇文章，上面写着：

实际上，这部分几乎只包含在授权部分中定义的名称服务器的 A 或 AAAA（IP 地址）记录。

“几乎”让我有点困惑。我们可以在附加部分中找到哪些其他记录？

domain-name-system
Martin Hope
vinz
Asked: 2021-01-04 01:15:59 +0800 CST
  • 0

如果我console.aws.amazon.com用解决dig，我得到：

; <<>> DiG 9.10.6 <<>> console.aws.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35338
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;console.aws.amazon.com.        IN  A

;; ANSWER SECTION:
console.aws.amazon.com. 4   IN  CNAME   lbr-optimized.console-l.amazonaws.com.
lbr-optimized.console-l.amazonaws.com. 4 IN CNAME us-east-1.console.aws.amazon.com.
us-east-1.console.aws.amazon.com. 4 IN  CNAME   gr.console-geo.us-east-1.amazonaws.com.
gr.console-geo.us-east-1.amazonaws.com. 4 IN CNAME console.us-east-1.amazonaws.com.
console.us-east-1.amazonaws.com. 59 IN  A   54.239.30.25

但是，在解决us-east-1.console.aws.amazon.com它时会得到一个NXDOMAIN：

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33652
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; ANSWER SECTION:
us-east-1.console.aws.amazon.com. 60 IN CNAME   gr.console-geo.us-east-1.amazonaws.com.

;; AUTHORITY SECTION:
us-east-1.amazonaws.com. 60 IN  SOA ns-912.amazon.com. root.amazon.com. 1609664924 3600 900 7776000 60

;; Received 147 bytes from 52.9.146.37#53(ns-912.amazon.com) in 270 ms

看起来，即使我们有一个NXDOMAINas 响应代码，它也会继续解析 CNAME。但是，根据 RFC（我在 #8020 中看到），如果有NXDOMAINas 响应代码，则意味着链末端的域不存在，因此我们假设继续，因为我们不打算获得任何 A RR...

我在这里有点困惑，为什么我们NXDOMAIN在链条中间。NXDOMAIN如果我们CNAME在 ANSWER 部分中有 a 并继续解析 CNAME 链，是否可以安全地忽略？

是否有解决此类问题的 RFC？

domain-name-system
Martin Hope
vinz
Asked: 2020-12-10 10:55:12 +0800 CST
  • 1

我阅读了很多关于它的文章，但我不明白如果出现以下情况，缓存中毒是如何发生的：

  • 如果响应的事务 ID 不匹配，则查询被取消并标记为失败（即攻击者无法暴力破解事务 ID，因为他们只会接受第一个响应）
  • 递归解析器一次只发送 1 个针对同一域/类型/类的请求，这意味着攻击者无法触发针对同一域的多个请求来暴力破解事务 ID

在看起来很基本的配置中，如果攻击者需要猜测事务 ID，缓存中毒怎么可能？攻击者会强迫递归解析器一次又一次地解析同一个域以进行更多尝试吗？在那种情况下，这可能需要几个小时......

domain-name-system
Martin Hope
vinz
Asked: 2020-11-23 11:58:14 +0800 CST
  • 0

RFC 8767的第 7 节说：

因为现代解析器使用预取和请求合并等技术来提高效率，所以不必在存在陈旧数据的情况下每个客户端请求都需要触发新的查找流，而是最近已经做出了善意的努力来刷新过时的数据在交付给任何客户端之前。

我没有得到这个建议的限制。假设我的缓存中有“abc.com”，其 TTL 为 1 小时并已过期 30 分钟，而“xyz.com”的 TTL 为 1 小时并已过期 20 分钟。如果我将陈旧数据保留 12 小时，我应该先提供陈旧数据（因为它不久前已过期）还是应该先尝试刷新？

在文档中，它说如果客户端计时器过期（约 1.8 秒），则可以提供陈旧数据，但现在建议在某些情况下返回第一个陈旧数据。但我不明白这些情况是什么。

而是最近做出了善意的努力来刷新过时的数据

这是否意味着如果解析器在 TTL 过期之前至少尝试刷新数据一次，我可以立即服务器陈旧数据？现在可以成功刷新任何请求吗？

domain-name-system
Martin Hope
vinz
Asked: 2020-11-18 02:11:37 +0800 CST
  • 2

当我dig whoami.akamai.net AAAA在我的电脑上做时，我得到了

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32160
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;whoami.akamai.net.     IN  AAAA

但是如果我从@1.1.1.1 或@8.8.8.8 甚至OpenDNS 尝试，我可以获得AAAA RR。

是什么阻止我的本地挖掘没有得到结果？

根据 RFC4074 ( https://www.rfc-editor.org/rfc/rfc4074#section-3 )：

假设权威服务器有一个 A RR 但没有主机名的 AAAA RR。然后，服务器应返回对名称为 AAAA RR 的查询的响应，其中响应代码 (RCODE) 为 0（表示没有错误）并且答案部分为空（参见 RFC 的第 4.3.2 和 6.2.4 节1034)。这样的响应表明对于查询的名称，至少有一个与 AAAA 不同类型的 RR，然后存根解析器可以查找 A RR。

我认为这是正在发生的事情，但看起来该域有一个现有的 AAAA 记录（因为主要的 dns 解析器有它）。我不明白这里发生了什么。

domain-name-system
Martin Hope
vinz
Asked: 2020-09-07 22:17:20 +0800 CST
  • 0

我已经看到很多关于缓冲区大小的建议（例如https://github.com/dns-violations/dnsflagday/issues/125），但我不明白选择一个或另一个会有什么影响。

他们是怎么想出这么大的尺寸的？它们是来自基准测试还是来自真实案例的监控？

在 RFC6891（https://www.rfc-editor.org/rfc/rfc6891#section-6.2.5）中，它说“请求者应该选择使用以大尺寸开头的回退机制，例如 4096。如果失败，应该尝试在 1280-1410 字节范围内的回退”。从大尺寸开始并重试有什么意义？它只会减慢分辨率。4096 缓冲区大小是否与 1280 一样快？在那种情况下，我猜他们的陈述会有意义吗？

domain-name-system
Martin Hope
vinz
Asked: 2020-06-20 01:10:40 +0800 CST
  • 0

我阅读了https://www.rfc-editor.org/rfc/rfc2606和https://www.rfc-editor.org/rfc/rfc6761，但我仍然没有得到一些细节。为什么https://www.rfc-editor.org/rfc/rfc2606没有明确说明我们应该为保留域返回哪个响应代码？https://www.rfc-editor.org/rfc/rfc6761的目的是添加更多详细信息吗？

在https://www.rfc-editor.org/rfc/rfc6761中，他们说：

相反，默认情况下，缓存 DNS 服务器应该为所有此类查询生成立即否定响应

负数是 NXDOMAIN 还是 REFUSED？还是由开发商决定？在同一个 RFC 的开头，是这样写的：

要使这个特殊的“保证不存在”名称有任何用途，必须将其定义为返回 NXDOMAIN

在这里适用吗？我不清楚他们为什么使用“负面反应”一词。另外，这个 RFC 在现实世界中实现了吗？看起来 dig 仍在查询这些保留域的根服务器。

domain-name-system dns-server
Martin Hope
vinz
Asked: 2020-06-09 23:50:18 +0800 CST
  • 0

获得 的钥匙时domaindiscount24.net，我得到了：

domaindiscount24.net.   3600    IN  DNSKEY  257 3 7 AwEAAeKb+f8Taftu3DLQEVeHJTarZBQwZ9M1B9LpzldumDNwdLf3poYjcE04z30wQSw8NG+XXBaEzJ/vVXQFUsICDlG88HcOQD5/S5WE9sWmHEGKwj1lwzLvfxcBUiOqYEUaI+4xa4EGTuPxKq+No5zutiewaioXqPNRAr0oLCUgl3wUP83+f1RWBHmYkvSyvCprnI++sTl3mjvqMoDxgnZmFexYEuD3RUZDbeSpnbGF9xWuUF7Eiyv8/plQKLaGHFVfc2UKFgvHgZEwGjbu4M15Hr+khZsyAv321LLcNfJMmMQWvWzd7Ls8lgKU721W7BOGMbKT1a+R5JEBsMJEoOd6EhU=
domaindiscount24.net.   3600    IN  DNSKEY  256 3 7 AwEAAb5e1OpMWHZWshn3YVZNuE1mjFfIHXMzBHTh/b2bFrp+IuJ/ruylT+lRkljmSTnLhUcf1ISTU9E+PIjGxm20/mbnZl42YNCcklc30kGFxLrrhCw+qckaepwCWwoDlKsWre8yBFAw0y1co093IP6qSZuDkBU7wrz7x6ltVjfk95/b
domaindiscount24.net.   3600    IN  DNSKEY  257 3 7 AwEAAbqzUHscKrAbgQArh8FkVBz6ToXfWn4hy89zqizcpEX5y16XdNf5OtG8HOU5V3LG0nS6SlSbLFamzWQMliuIt0cRWIiK1XjMYrWWKWODWw1mUqVvlnhtoGDxXroW1HWjrSAX15KWJozOLvaBHRFEiVbldlfFAoEwtuYocjIU8uzyxQxjyNgfwppe2/ZB7ceFNOvF3nJrTrfjWLtRE/srfAIdCefdcnKx4y8PUo1YL0TfJDYhzmFy5ewJxn1Oa0eXl8HONGFiWMo71q+ZqdZ+157UfQPz9uinrzs/MN/u+aREIH0Gxibx6wEczRw5GGiYyw5ETuK5GZlIU03y2KivAnk=
domaindiscount24.net.   3600    IN  DNSKEY  256 3 7 AwEAAaVi/p34WjJ5qNa8hnjVm4c1/6iyX9+XrYIGvY8skrVcJuJDBB3OUPgrpCNgjpguTtDKGECmBv2qMkxa2D5HKM/rn6S9o4TAsWKsR/IJDA0DF2VF6RR5ZnNHj/a13de0E3OD1X9iDlCc9sIz+R8OIJyRGpAdVFlFtNURbP7FTUBr
domaindiscount24.net.   3600    IN  RRSIG   DNSKEY 7 2 3600 20200612203538 20200529125353 11133 domaindiscount24.net. qnDCvLJ1N3/0ClXYDarJKjyf/k2fFGhzOj1ubMZqNalPqkRyiwS/IdktKRQOPanSCClLpQ335/t/9ACPwuhWBd8KZEEcA6xWwnKj0xF2FaPfvjyoo2Co/nj4cSdJHIVgYzwHQb6rcNeHpX1Leamt7tCC+ynCnj4PGoOppiOdr6NKNVn0Av1T+ZzjoC/tKCq8iI/nt74sYuC11gML6shtbMOB5PqJwWA6haJ8Vd/fIDE30bj1T2LFdF/A2NwO8htuZxwf/QICtPuHe7J92aqBM5s3gbl8Vkml7yiLdKglVMBWa3me+hybuQF7Ox+UWEUr3g3NGLzeXbELvbyHG2yzlA==
domaindiscount24.net.   3600    IN  RRSIG   DNSKEY 7 2 3600 20200612203538 20200529125353 33205 domaindiscount24.net. VgDc41jBAYpW7k/6cfRSsTPJAyj4xvVUQxJTBaQnm1HvpWwpFusQp47HXS686F4WQbvra3ADwvBf6VolITc/qjjcGsOPl6jDAxuJzBdbmY1Ys9J2zpziiOgljBKTRn6Unl20h2+uN4Klm7PULT7yptRQozOAnjb8u1WsUlvbfNdT9unsxODpgXOM9b2LnQHTN1C5mxR+IoaAhM5GwebQyFq0FF2J/XAwrvPmAiV6aYr9vttkCQP2V3xlJeCqT9D8Hdfe0K1Ci2phEgdruSRbjuadoGcm4mY7svLzqJlY+zrf2391vMIDlyd1Hs37ztbbbgL4BvBKmBlYQ53bLG1HFA==

但是，没有 DS 注册domaindiscount24.net：

;; QUESTION SECTION:
;domaindiscount24.net.      IN  DS

;; AUTHORITY SECTION:
net.            900 IN  SOA a.gtld-servers.net. nstld.verisign-grs.com. 1591688573 1800 900 604800 86400

怎么可能有 KSK 但没有 DS 记录？我们应该如何验证 KSK？

domain-name-system dnssec