蚊章汇 - DNS
type: channel
link: https://linuxcn.bwsl.wang/tag/DNS/
items: 从零开始，运用 Ruby 语言创建一个 DNS 查询
items: 为什么 DNS 仍然难以学习？
items: DNS 故障集锦
items: 如何设置自己的保护隐私的 DNS 服务器
items: 硬核观察 #886 谷歌公共 DNS 服务正在推行大小写混杂查询
items: 硬核观察 #837 20 个企业控制了一半的域名解析
items: 为什么有时候域名的末尾有个点？
items: 硬核观察 #816 Fedora 38 考虑提供面向手机的版本
items: 为什么你要运行自己的 DNS 服务器？
items: 如何使用 dig

从零开始，运用 Ruby 语言创建一个 DNS 查询
type: item
date: 2023-10-24T23:50:37+08:00
description: 大家好！前段时间我写了一篇关于“如何用 Go 语言建立一个简易的 DNS 解析器”的帖子。那篇帖子里我没写有关“如何生成以及解析 DNS 查询请求”的内容，因为我觉得这很无聊，不过一些伙计指出他们不知道如何解析和生成 DNS 查询请求，并且对此很感兴趣。我开始好奇了——解析 DNS 能 花多大功夫？事实证明，编写一段 120 行精巧的 Ruby 语言代码组成的程序就可以做到，这并不是很困难。所以，在这里有一个如何生成 DNS 查询请求，以及如何解析 DNS 响应报文的速成教学！我们会用 Ruby 语言完成这项任务，主要是因为不久以后我将在一场 Ruby 语言大会上发表观点，而这篇博客帖的部分内容是为了那场演讲做准备的。?（我尽量让不懂 Ruby 的人也能读懂，我只使用了非常基础的 Ruby 语言代码。）最后，我们就能制作一个非常简易的 Ruby 版本的 dig 工具，能够查找域名，就像这样：$ ruby dig.rb example.com example.com 20314 A 93.184.216.34 整个程序大概 120 行左右，所以 并不 算多。（如果你想略过讲解，单纯想去读代码的话，最终程序在这里：dig.rb。）我们不会去实现之前帖中所说的“一个 DNS 解析器是如何运作的？”，因为我们已经做过了。那么我们开始吧！如果你想从头开始弄明白 DNS 查询是如何格式化的，我将尝试解释如何自己弄明白其中的一些东西。大多数情况下的答案是“用 Wireshark 去解包”和“阅读 RFC 1035，即 DNS 的规范”。生成 DNS 查询请求步骤一：打开一个 UDP 套接字我们需要实际发送我们的 DNS 查询，因此我们就需要打开一个 UDP 套接字。我们会将我们的 DNS 查询发送至 8.8.8.8，即谷歌的服务器。下面是用于建立与 8.8.8.8 的 UDP 连接，端口为 53（DNS 端口）的代码。require 'socket' sock = UDPSocket.new sock.bind('0.0.0.0', 12345) sock.connect('8.8.8.8', 53) 关于 UDP 的说明关于 UDP，我不想说太多，但是我要说的是，计算机网络的基础单位是“ 数据包 packet ”（即一串字节），而在这个程序中，我们要做的是计算机网络中最简单的事情：发送 1 个数据包，并接收 1 个数据包作为响应。所以 UDP 是一个传递数据包的最简单的方法。它是发送 DNS 查询最常用的方法，不过你还可以用 TCP 或者 DNS-over-HTTPS。步骤二：从 Wireshark 复制一个 DNS 查询下一步：假设我们都不知道 DNS 是如何运作的，但我们还是想尽快发送一个能运行的 DNS 查询。获取 DNS 查询并确保 UDP 连接正常工作的最简单方法就是复制一个已经正常工作的 DNS 查询！所以这就是我们接下来要做的，使用 Wireshark （一个绝赞的数据包分析工具）。我的操作大致如下：打开 Wireshark，点击 “ 捕获 capture ” 按钮。在搜索栏输入 udp.port == 53 作为筛选条件，然后按下回车。在我的终端运行 ping example.com（用来生成一个 DNS 查询）。点击 DNS 查询（显示 “Standard query A example.com”）。 （“A”：查询类型；“example.com”：域名；“Standard query”：查询类型描述）右键点击位于左下角面板上的 “ 域名系统（查询） Domain Name System (query) ”。点击 “ 复制 Copy ” ——> “ 作为十六进制流 as a hex stream ”。现在 b96201000001000000000000076578616d706c6503636f6d0000010001 就放到了我的剪贴板上，之后会用在我的 Ruby 程序里。好欸！步骤三：解析 16 进制数据流并发送 DNS 查询现在我们能够发送我们的 DNS 查询到 8.8.8.8 了！就像这样，我们只需要再加 5 行代码：hex_string = "b96201000001000000000000076578616d706c6503636f6d0000010001" bytes = [hex_string].pack('H*') sock.send(bytes, 0) # get the reply reply, _ = sock.recvfrom(1024) puts reply.unpack('H*') [hex_string].pack('H*') 意思就是将我们的 16 位字符串转译成一个字节串。此时我们不…

为什么 DNS 仍然难以学习？
type: item
date: 2023-08-13T20:17:00+08:00
description: 我经常写关于我发现难以学习的技术的文章。不久前，我的朋友 Sumana 向我提出了一个有趣的问题 - 为什么这些东西学起来那么难？为什么它们看起来如此神秘？以 DNS 为例。我们从 80 年代 开始使用 DNS（已经超过 35 年了！）。它在互联网上的每个网站中都使用。而且它相当稳定 - 在很多方面，它的工作方式与 30 年前完全相同。但是我花了好几年的时间才弄清楚如何自信地调试 DNS 问题，我也见过很多其他程序员在调试 DNS 问题上苦苦挣扎。那么到底发生了什么呢？以下是关于为什么学习排除 DNS 问题很困难的几点思考。（我不会在这篇文章中详细解释 DNS，更多关于 DNS 如何工作的信息，请参阅 《用一个周末实现一个 DNS》 或 我的 DNS 方面的博文）并不是因为 DNS 非常难当我最终学会如何排除 DNS 问题时，我的反应是“什么，就这样吗？？？这并不难！”我感觉有点被骗了！我可以在 几个小时 内向你解释关于 DNS 令我感到困惑的一切事情。那么 - 如果 DNS 并不是那么复杂，为什么我花了这么多年的时间才弄清楚如何排除相当基本的 DNS 问题（比如“即使我已经正确设置了，我的域名仍无法解析”或者“dig 命令和我的浏览器的 DNS 结果不一致，为什么？”）？而且，在发现 DNS 学习困难方面，我并不孤单！我与许多经验丰富的程序员朋友讨论过多年来的 DNS 问题，其中很多人要么：不敢轻易对其网站进行简单的 DNS 更改或对 DNS 工作原理的基本事实感到困惑（比如记录是 拉取的而非推送的）或对 DNS 基础知识了解得很好，但却和我一样存在一些知识盲点（负缓存和 dig 命令及浏览器如何以不同方式进行 DNS 查询的细节）因此，如果我们都面临着 DNS 的相同困扰，到底发生了什么？为什么对许多人来说学习 DNS 如此困难？以下是我的一些看法。很多系统是隐藏的当你在计算机上发起 DNS 请求时，基本的过程如下：你的计算机向一个名为“解析器”的服务器发起请求。解析器检查其缓存，并向一些称为“权威名称服务器”的其它服务器发起请求。以下是你看不到的一些内容：解析器的缓存。里面有什么内容？在你的计算机上进行 DNS 请求的库代码是哪个（是否是 libc 的 getaddrinfo 函数？如果是，它是来自 glibc、musl 还是苹果？是你的浏览器的 DNS 代码吗？还是其他自定义的 DNS 实现？）所有这些选项的行为略有不同，并且有不同的配置、缓存方法、可用功能等等。例如，musl DNS 直到 2023 年初 才支持 TCP。解析器与权威名称服务器之间的对话。如果你能够神奇地获得一个准确记录你的请求期间向下游查询的每个权威名称服务器以及它们的响应的追踪，我认为很多 DNS 问题将变得非常简单。（比如，如果你能运行 dig +debug google.com 并获得一些额外的调试信息会怎么样？）如何和隐藏系统打交道以下是几个处理隐藏系统的方法：向人们传授隐藏系统的知识会产生重大影响。很长一段时间里，我不知道我的计算机有多个不同的 DNS 库，它们在不同情况下使用，我对此感到困惑了好几年。这是我的重要排错方法。通过 Mess With DNS，我们尝试了一种“鱼缸”的方法，展示了通常隐藏的系统（与解析器和权威名称服务器的对话）的一些部分。我觉得将 DNS 扩展以包括一个“调试信息”部分会非常酷。（注：似乎这已经有了！它被称为“扩展 DNS 错误”，即 EDE，各种工具正在逐渐添加对它的支持。）扩展 DNS 错误看起来不错扩展 DNS 错误是 DNS 服务器提供额外调试信息的一种新方式。以下是一个示例：$ dig @8.8.8.8 xjwudh.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39830 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a) ;; QUESTION SECTION: ;xjwudh.com. IN A ;; AUTHORITY SECTION: com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1690634120 1800 900 604800 86400 ;; Query time: 92…

DNS 故障集锦
type: item
date: 2023-07-21T20:23:00+08:00
description: 当我第一次知道 DNS 时，我想它应该不会很复杂。不就是一些存储在服务器上的 DNS 记录罢了。有什么大不了的？但是教科书上只是介绍了 DNS 的原理，并没有告诉你实际使用中 DNS 可能会以多少种方式破坏你的系统。这可不仅仅是缓存问题！所以我 在 Twitter 上发起了一个提问，征集人们遇到的 DNS 问题，尤其是那些一开始看起来与 DNS 没什么关系的问题。（“总是 DNS 问题”这个梗）我不打算在这篇文章中讨论如何解决或避免这些问题，但我会放一些讨论这些问题的链接，在那里可以找到解决问题的方法。问题：网络请求缓慢如果你的网络比预期的要慢，这是因为某些原因导致 DNS 解析器变慢了。这可能是解析器负载过大或者存在内存泄漏等原因导致的。我的路由器的 DNS 转发器曾遇到过这个问题，导致我的所有 DNS 请求很慢。我通过重启路由器解决了这个问题。问题：DNS 超时一些网友提到由于 DNS 查询超时，他们的网络请求需要耗时 2 秒多甚至 30 秒。这跟“网络请求缓慢”问题类似，但情况要更糟糕，因为 DNS 请求就会消耗掉几秒钟时间。Sophie Haskins 有一篇关于 Kubernete DNS 超时的博客文章 一次 Kube DNS 踩坑经历。问题：ndots 设置一些网友提到在 /etc/resolv.conf 中设置 ndots:5 时会出现问题。下面是从 这篇《Kubernetes 容器荚中 /etc/resolv.conf 里设置 ndots:5 为什么会拖慢你的程序性能》中引用的 /etc/resolv.conf文件。 nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5 如果你用上面的配置文件，想要查询得域名是 google.com，那么你的程序会调用 getaddrinfo 函数，而它会依次查询以下域名：google.com.namespace.svc.cluster.local.google.com.svc.cluster.local.google.com.cluster.local.google.com.eu-west-1.compute.internal.google.com.简单来说，它会检查 google.com 是不是 search 这一行中的某个子域名。所以每发起一次 DNS 查询，你都得先等待前 4 次查询失败后才能获取到最终查询结果。问题：难以判断系统使用的 DNS 解析器这本身并不是一个问题，但当你遇到 DNS 问题时，一般都会跟 DNS 解析器有关。我没有一种判断 DNS 解析器的万能方法。下面是我知道的方法：在 Linux 系统上，最常见的是通过 /etc/resolv.conf 来选择 DNS 解析器。但是也有例外，比如浏览器可能会忽略 /etc/resolv.conf，而是使用 基于 HTTPS 的 DNS DNS-over-HTTPS 服务。如果你使用的是 UDP DNS，你可以通过 sudo tcpdump port 53 来查看 DNS 请求被发送到了哪里。但如果你使用的是基于 HTTPS 的 DNS 或 基于 TLS 的 DNS DNS over TLS ，这个方法就不行了。我依稀记得这在 MacOS 系统上会更加令人迷惑，我也不清楚原因。问题：DNS 服务器返回 NXDOMAIN 而不是 NOERROR这是我曾经遇到过的一个 Nginx 不能解析域名的问题。我设置 Nginx 使用一个特定的 DNS 服务器来解析 DNS 查询当访问这个域名时，Nginx 做了两次查询，第一次是对 A 的，第二次是对 AAAA 的对于 A 的查询，DNS 服务器返回 NXDOMAINNginx 认为这个域名不存在，然后放弃查询对于 AAAA 的查询 DNS 服务器返回了成功但 Nginx 忽略了对 AAAA 返回的查询结果，因为它前面已经放弃查询了问题出在 DNS 服务器本应该返回 NOERROR 的——那个域名确实存在，只是没有关于 A 的记录罢了。我报告了这个问题，然后他们修复了这个问题。我自己也写出过这个问题，所以我理解为什么会发生这种情况——很容易想当然地认为“没有要查询的记录，就应该返回 NXDOMAIN 错误码”。问题：自动生效的 DNS 缓存如果你在生成一个域名的 DNS 记录之前就访问这个域名，那么这个记录的缺失会被缓存起来。当你第一次遇到这个问题时一定会非常吃惊——我也是去年才知道有这个问题。缓存的 TTL 就是域名的 起始权限记录 Start of Autho…

如何设置自己的保护隐私的 DNS 服务器
type: item
date: 2023-03-29T23:04:53+08:00
description: 通过开源项目 AdGuard Home 运行你自己的 DNS 服务器来控制你的互联网隐私。域名服务器（DNS）将域名（如 example.com）与 IP 地址（如 93.184.216.34）相关联。这就是当你输入 URL 或搜索引擎返回 URL 供你访问时，你的网络浏览器如何知道在世界的哪个地方寻找数据。DNS 为互联网用户提供了极大的便利，但也并非没有缺点。例如，付费广告会出现在网页上，因为你的浏览器会自然的使用 DNS 来解析这些广告在互联网上“存在”的位置。同样，跟踪你在线活动的软件通常由通过 DNS 解析的服务启用。你不想完全关闭 DNS，因为它非常有用。但是你可以运行自己的 DNS 服务，以便更好地控制它的使用方式。我相信运行自己的 DNS 服务器至关重要，这样你就可以阻止广告并保持你的浏览隐私，远离试图分析你的在线交互的提供商。我过去用过 Pi-hole，今天仍然推荐它。然而，最近，我一直在我的网络上运行开源项目 AdGuard Home。我发现它有一些值得探索的独特功能。AdGuard Home在我使用过的开源 DNS 软件中，AdGuard Home 是最容易设置和维护的。你可以在一个项目中获得许多 DNS 解析解决方案，例如 DNS over TLS、DNS over HTTPS 和 DNS over QUIC。你可以使用一个脚本将 AdGuard 设置为容器或本地服务：$ curl -s -S -L \ https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh 查看这个脚本以便了解它的作用。了解了它的工作过程后，再运行它：$ sh ./install.sh 我最喜欢 AdGuard Home 的一些功能：一个简单的管理界面使用 AdGuard 阻止列表来阻止广告和恶意软件单独配置网络上每个设备的选项强制在特定设备上进行安全搜索为管理界面设置 HTTPS，这样与它的远程交互是完全加密的我发现 AdGuard Home 为我节省了时间。它的黑名单比 Pi-hole 上的黑名单更强大。你可以快速轻松地将其配置为 DNS over HTTPS。没有更多的恶意软件恶意软件是你计算机上不需要的内容。它并不总是对你有直接危险，但它可能会为第三方带来危险活动。这不是互联网最初的目的。我认为你应该托管自己的 DNS 服务，以保护你的互联网历史记录的私密性，并避免被微软、谷歌和亚马逊等已知跟踪器掌握。在你的网络上试用 AdGuard Home 吧。via: https://opensource.com/article/23/3/open-source-dns-server作者：Amar Gandhi 选题：lkxed 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出

硬核观察 #886 谷歌公共 DNS 服务正在推行大小写混杂查询
type: item
date: 2023-01-20T01:28:51+08:00
description: 谷歌公共 DNS 服务正在推行大小写混杂查询在 DNS over TLS 之前，DNS 查询由于技术原因会被投毒，从而导致客户端访问到投毒者设置的假冒地址。为了避免这种安全风险，最好的方式是使用 DNS over TLS 这样的加密查询通道。但是仍然有大量的 DNS 服务器没有或不能使用加密查询。谷歌从 2009 年就在小范围实验一种名为 0x20 的做法，它可以将查询的域名随机改变字母大小写，这可以有效的提高 DNS 投毒的难度。现在谷歌已经扩大了该方案，已经覆盖了 90% 没有使用加密查询的 DNS 服务器。消息来源：The Register老王点评：以后在你的权威 DNS 服务器上看到类似 liNUx.cN 这样的查询不要惊奇。290 款微星主板的安全启动默认被绕过安全启动是 UEFI 主板固件中的一项安全功能，确保在启动过程中只有受信任的（签名）软件可以执行。研究发现，微星公司在 2021 年 9 月至 2022 年 1 月期间发布的固件更新，改变了微星主板上的一个默认安全启动设置，该设置允许任何操作系统镜像运行，无论其是否有错误或丢失的签名。受影响的主板超过了 290 款，包括最新的用于英特尔和 AMD CPU 的微星主板。消息来源：Bleeping Computer老王点评：我觉得讨厌安全启动功能的人会喜欢这个默认设置。USB4 2.0 规格正式发布，USB-C 可达 120GbpsUSB-C 是令人困惑的，一个 USB-C 端口或电缆可以支持一系列的速度、电源能力和其他功能，它支持的数据传输速率，可以从 USB 2.0 的 0.48Gbps 一直到 USB4 和雷电 3/4 的 40Gbps。USB 实施者论坛（USB-IF）今天发布了 USB4 2.0 规范，它增加了对 80Gbps 双向带宽的可选支持，以及以高达 120Gbps 速度发送或接收数据的可选能力。但预计在至少 12 到 18 个月内不会看到支持新规格的产品出现。消息来源：USB-IF老王点评：都是一种样子的接口，但是有的电缆就特别优秀。?回音自去年 9 月 宣布 以来，谷歌今天正式 关闭 了其 Stadia 云游戏平台。除了对用户购买的软硬件退款之外，他们还使其游戏手柄能够使用蓝牙，以便在其他游戏平台上使用。

硬核观察 #837 20 个企业控制了一半的域名解析
type: item
date: 2022-12-01T22:41:29+08:00
description: 20 个企业控制了一半的域名解析据分析，来自 20 个域名的 255 台 DNS 服务器控制了 52% 的域名解析，100 个域名的 DNS 服务器控制了 75% 的域名解析，6000 个域名的 DNS 服务器控制了 99% 的域名解析。控制域名解析的前 20 个域名来自互联网巨头，其中 15 个是美国科技巨头，如 GoDaddy、谷歌、Cloudflare 和亚马逊。其中 34% 的域名解析的 IP 地址属于 Cloudflare 的自治系统 AS13335。消息来源：Netmeister老王点评：互联网其实不是去中心化的，而是分布式的。Mastodon 的安全性并不可靠自从 Twitter 被收购后，Mastodon 引来了大量注意，用户数量激增，两周内总用户达到 870 万。有安全专家发现多个存在安全漏洞的 Mastodon 实例。Mastodon 项目缺乏专门的安全团队，甚至软件也没有自动更新或检查更新的功能。消息来源：Ars Technica老王点评：随着用户增多，安全问题就成了大问题，好在 Mastodon 本身并不收集太多用户数据。Let's Encrypt 签发了逾三十亿证书目前全球有数以百万计的网站依赖 Let's Encrypt 作为安全保障。其 2022 年年度报告中称，截至 2022 年 11 月 1 日，它为超过 3.09 亿个域名提供了证书，仅 2022 年增加了逾 3300 万个域名。Let's Encrypt 在 2017 年 6 月签发了第一亿个证书。三年后的 2020 年 2 月签发了第 10 亿个证书。消息来源：Let's Encrypt老王点评：Let's Encrypt 功莫大焉，要是一直由 CA 公司把持 SSL 证书的签发，HTTPS 的普及可能会慢得多。

为什么有时候域名的末尾有个点？
type: item
date: 2022-11-15T08:11:00+08:00
description: 大家好！今年早些时候，我在写《DNS 是如何工作的》 时，有人问我——为什么人们有时在域名的末尾加一个点？例如，如果你通过运行 dig example.com 查询 example.com 的 IP，你会看到一下内容：$ dig example.com example.com. 5678 IN A 93.184.216.34 执行完 dig 命令后，example.com 有一个 . ——变成了 example.com.！发生了什么？有些 DNS 工具也要求传给它的域名后加一个 .：如果你在使用 miekg/dns 时传给它 example.com，它会报错：// trying to send this message will return an error m := new(dns.Msg) m.SetQuestion("example.com", dns.TypeA) 最初我以为我知道这个问题的答案（“呃，末尾的点意味着域名是完全限定的？”）。这是对的 —— 一个 完全限定域名 fully qualified domain name （FQDN）是一个末尾有 . 的域名！但是为什么末尾的点是有用且重要的呢？在 DNS 的请求/响应中，域名的末尾并没有 “.”我曾经（错误地）认为 “为什么末尾有一个点？”的答案可能是 “在 DNS 请求/响应中，域名末尾有一个 .，所以我们把它放进去，以匹配你的计算机实际发送/接收的内容”。但事实并不是这样！当计算机发送 DNS 请求/响应时，域名的末尾并没有点。实际上，域名中没有点。域名会被编码成一系列的长度/字符串对。例如，域名 example.com 被编码为这 13 个字节。7example3com0 编码后的内容一个点也没有。一个 ASCII 域名（如 example.com）被转成了各种 DNS 软件的 DNS 请求/响应中使用的格式。今天我们来讨论域名被转成 DNS 响应的一个地方：区域文件。区域文件中域名末尾的 “.”一些人管理域名的 DNS 记录的方法是创建一个被称为 “区域文件” 的文本文件，然后配置一些 DNS 服务器软件（如 nsd 或 bind）来为该区域文件中指定的 DNS 记录提供服务。下面是一个对应 example.com 的示例区域文件：orange 300 IN A 1.2.3.4 fruit 300 IN CNAME orange grape 3000 IN CNAME example.com. 在这个文件中，任何不以 . 结尾的域名（比如 orange）后都会自动加上 .example.com。所以 orange 成了 orange.example.com 的简称。DNS 服务器从它的配置中得知这是一个 example.com 的区域文件，所以它知道在所有不以点结尾的名字后面自动添加 example.com。我想这里的想法只是为了少打几个字符——如果要打出全称，区域文件会是这样： orange.example.com. 300 IN A 1.2.3.4 fruit.example.com. 300 IN CNAME orange.example.com. grape.example.com. 3000 IN CNAME example.com. 确实多了很多字符。你也可以不通过区域文件来使用 DNS尽管官方的 DNS RFC（RFC 1035）中定义了区域文件格式，但你也可以不通过区域文件来使用 DNS。例如，AWS Route 53 就不用区域文件来存储 DNS 记录！你可以通过 Web 界面或 API 来创建记录，我猜他们是用某种数据库而不是一堆文本文件来存储记录。不过，Route 53（像许多其他 DNS 工具一样）确实支持导入和导出区域文件，这个功能或许在你更换 DNS 提供商时很有用。dig 命令输出中末尾的 “.”现在我们来讨论下 dig 命令的输出：$ dig example.com ; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> +all example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10712 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;example.com. IN A ;; ANSW…

硬核观察 #816 Fedora 38 考虑提供面向手机的版本
type: item
date: 2022-11-10T18:53:00+08:00
description: Fedora 38 考虑提供面向手机的版本虽然 Fedora 37 还没有发布，但是开发人员已经在计划下一个版本。一个新的提案建议提供一个面向移动设备的 Phosh 镜像，用于运行专注于智能手机和平板电脑的 Wayland shell，同时提供一个良好的基于 GNOME 的体验。另外预计也会引入一个带有 KDE Plasma Mobile 的镜像。Fedora 38 预计明年春天发布。消息来源：Phoronix老王点评：期待看到 Fedora 运行在手机上。罗马法院要求 Cloudflare 的 DNS 封锁 BT 网站罗马法院已经确认，Cloudflare 必须通过其公共的 1.1.1.1 DNS 解析器阻止三个 BT 网站。Cloudflare 并不反对阻止针对其客户网站的请求，但认为干扰其 DNS 解析器是有问题的，因为这些措施不容易在地理上加以限制，将影响封锁该政府管辖范围以外的终端用户。消息来源：Slashdot老王点评：DNS 作为互联网流量入口的方向标，屡屡被用来做各种滥用。已经习惯了，不是吗？15000 个网站被黑帽 SEO 利用安全专家发现，有 15000 个网站（其中大部分是 WordPress 网站），这些网站被重定向到虚假的问答讨论区。恶意威胁者的目标是产生足够的索引页面，以增加虚假问答网站的权重，从而在搜索引擎中获得更好的排名。消息来源：Bleeping Computer老王点评：WordPress 这样的 CMS 系统越流行，其被一网打尽的可能越多，尤其是都采用了某些存在缺陷的插件或主题时。

为什么你要运行自己的 DNS 服务器？
type: item
date: 2022-01-10T19:30:00+08:00
description: 使得 DNS 难以理解的事情之一是它是 分布式的。有成千上万（也许是几十万？我不知道！）的 权威性域名服务器 authoritative nameserver ，以及至少 1000 万个解析器。而且它们正在运行许多不同的软件！不同服务器运行着不同的软件意味着 DNS 的工作方式有很多不一致的地方，这可能导致各种令人沮丧的问题。但是，与其谈论这些问题，我更感兴趣的是弄清楚 —— 为什么 DNS 是分布式的是一件好事？为什么 DNS 是分布式的是件好事？一个原因是 可扩展性 —— DNS 的分布式设计使其更容易扩展，对故障的恢复能力更强。我发现，尽管 DNS 已经有近 40 年的历史，但它的扩展性仍然很好，这真是令人惊讶。这一点非常重要，但这并不是这篇文章的主题。相反，我想说的是，它是分布式的意味着你可以 控制 你的 DNS 的工作方式。你可以向巨大而复杂的 DNS 服务器中添加更多的服务器！添加你控制的服务器！昨天我 在 Twitter 上问 为什么你要运行自己的 DNS 服务器，我得到了很多很好的答案，我想在这里总结一下。你可以运行 2 种类型的 DNS 服务器你可以运行 2 种主要类型的 DNS 服务器：如果你拥有一个域名，你可以为该域名运行一个 权威名称服务器如果你有一台电脑（或一个有很多电脑的公司），你可以运行一个 解析器 来为这些电脑解析 DNS。DNS 不是静态数据库我经常看到 DNS 的 “电话簿” 比喻，域名就像人名，IP 地址就像电话号码。这是一个不错的思维模型。但是，“电话簿” 思维模型可能会使你认为，如果你对 google.com 进行 DNS 查询，你将永远得到相同的结果。而这是不正确的。你在 DNS 查询中得到的记录可能取决于：你在世界的哪个地方（也许你会得到一个离你更近的服务器的 IP 地址）你是否在企业网络里（你可以在其中解析内部域名）该域名是否被你的 DNS 解析器认为是 “坏” 的（它可能被封锁！）之前的 DNS 查询（也许 DNS 解析器正在做基于 DNS 的负载平衡，每次给你一个不同的 IP 地址）你是否在使用机场 Wi-Fi 专属门户（机场 Wi-Fi 会在你登录前以不同的方式解析 DNS 记录，它会给你发送一个特殊的 IP 来重定向你）随便什么你可能想控制你自己的服务器的很多原因都与 DNS 不是一个静态数据库这一事实有关 —— 对于如何处理 DNS 查询，你可能会有不同的选择（无论是为你的域名还是为你的组织）。运行权威性名称服务器的理由这些原因并没有任何特定的顺序。对于其中一些原因，你不一定必须要运行你自己的权威名称服务器，你只需选择提供了该功能的权威名称服务器服务就行了。要明确的是：有很多理由 不 运行自己的权威名称服务器 —— 我就没有运行，我也不想说服你应该这样做。它需要时间来维护，你的服务可能不那么可靠，等等。原因：安全这条推文说的很好：[存在] 攻击者通过你的 DNS 供应商的客户支持人员获得 DNS 变更权限的风险，客服本来只应该提供帮助。他们可以被你的 DNS 阻止（也许就是因为缺少这个）。内部可能更容易审计和验证内容。原因：你喜欢运行 bind/nsd有几个人提到的一个原因是：“我习惯于编写区域文件和运行 bind 或 nsd ，对我来说这样做更容易。”如果你喜欢 bind/nsd 的方式，但又不想运维自己的服务器，有几个人提到，你也可以通过运行一个 “隐藏的主服务器” 来获得 bind 的优势，该服务器存储记录，但从一个 “辅助” 服务器提供所有的实际 DNS 查询。这里有一些我发现的关于配置辅助 DNS 的网页，以 NS1、cloudflare 和 Dyn 作为示例。我真的不知道什么是最佳的权威 DNS 服务器。我想我只在工作中使用过 nsd。原因：你可以使用新的记录类型并非所有的 DNS 服务都支持某些较新的 DNS 记录类型，但如果你运行你自己的 DNS，你就可以支持任何你想要的记录类型。原因：用户界面你可能不喜欢你正在使用的 DNS 服务的用户界面（或 API，或干脆没有 API）。这与 “你喜欢运行 BIND ”的原因差不多，也许你喜欢编写区域文件的方式。原因：你可以自己修复问题当问题出现时，能够自己解决，有一些明显的优点和缺点（优点：你可以解决问题，缺点：你必须解决问题）。原因：做一些奇怪的、自定义的事情你可以写一个 DNS 服务器，做任何你想做的事情，它不一定要只返回一组静态记录。有几个例子：Replit 有一篇博文介绍了 为什么他们编写自己的权威性 DNS 服务器来处理路由nip.io 将 10.0.0.1.nip.io 映射为 10.0.0.1我为 乱用 dns 而写了一个自定义 DNS 服务器原因：省钱权威名称服务器似乎一般按每百万次 DNS 查询…

如何使用 dig
type: item
date: 2021-12-06T03:26:00+08:00
description: 你好！最近我和几个朋友聊天，他们提到希望知道如何使用 dig 来进行 DNS 查询，所以这是一篇关于它的速读博文。当我第一次使用 dig 时，我发现它有点吓人 —— 有这么多的选项！我打算把大部分的选项省略。在这篇文章中，我打算不谈 dig 的大部分选项，只谈我实际使用的选项。我最近还了解到，你可以设置一个 .digrc 配置文件，让它的输出更容易阅读，这让它的使用变得更加轻松。几年前我还画了一个关于 dig 的 zine 页，但我想写这篇文章来包括更多的信息。两种类型的 dig 参数：查询和格式化有两种主要的参数可以传递给 dig：告诉 dig 要进行什么 DNS 查询的参数。告诉 dig 如何 格式化响应的参数。首先，让我们看一下查询选项。主要的查询选项你通常想控制 DNS 查询的 3 件事是：名称（如 jvns.ca）。默认情况下，查询的是空名称（.）。DNS 查询类型（如 A 或 CNAME）。默认是 A。发送查询的 服务器（如 8.8.8.8）。默认是 /etc/resolv.conf 中的内容。其格式是：dig @server name type 这里有几个例子：dig @8.8.8.8 jvns.ca 向谷歌的公共 DNS 服务器（8.8.8.8）查询 jvns.ca。dig ns jvns.ca 对 jvns.ca 进行类型为 NS 的查询。-x：进行反向 DNS 查询我偶尔使用的另一个查询选项是 -x，用于进行反向 DNS 查询。下面是输出结果的样子。$ dig -x 172.217.13.174 174.13.217.172.in-addr.arpa. 72888 IN PTR yul03s04-in-f14.1e100.net。 -x 不是魔术。dig -x 172.217.13.174 只是对 174.13.217.172.in-addr.arpa. 做了一个 PTR 查询。下面是如何在不使用 `-x’ 的情况下进行完全相同的反向 DNS 查询。$ dig ptr 174.13.217.172.in-addr.arpa. 174.13.217.172.in-addr.arpa. 72888 IN PTR yul03s04-in-f14.1e100.net。 我总是使用 -x，因为它可以减少输入。格式化响应的选项现在，让我们讨论一下你可以用来格式化响应的参数。我发现 dig 默认格式化 DNS 响应的方式对初学者来说是很难接受的。下面是输出结果的样子：; <<>> DiG 9.16.20 <<>> -r jvns.ca ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28629 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d87fc3022c0604d60100000061ab74857110b908b274494d (good) ;; QUESTION SECTION: ;jvns.ca. IN A ;; ANSWER SECTION: jvns.ca. 276 IN A 172.64.80.1 ;; Query time: 9 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Dec 04 09:00:37 EST 2021 ;; MSG SIZE rcvd: 80 如果你不习惯看这个，你可能需要花点时间来筛选，找到你要找的 IP 地址。而且大多数时候，你只对这个响应中的一行感兴趣（jvns.ca. 180 IN A 172.64.80.1）。下面是我最喜欢的两种方法，可以使 dig 的输出更容易管理：方式 1 : +noall +answer这告诉 dig 只打印 DNS 响应中的“答案”部分的内容。下面是一个查询 google.com 的 NS 记录的例子：$ dig +noall +answer ns google.com google.com. 158564 IN NS ns4.google.com. google.com. 158564 IN NS ns1.google.com. google.com. 158564 IN NS ns2.google.com. google.com. 158564 IN NS ns3.google.com. 这里的格式是：NAME T…