标签 : DNS 共 10 篇文章
作为互联网基础设施的基石之一，DNS 也是最脆弱的环节之一。在项目从上线、运营维护的整个生命周期中，DNS 记录的变更和管理是不可避免的。传统上，DNS 记录的管理往往依赖于域名注册商或 DNS 服务商提供的 控制平面，操作不直观、不可复现、容易出错、难以追溯、没有自动化。基础设施即代码（Infrastructure as Code, IaC）无疑为脆弱的 DNS 记录管理给出了一个方向。 2001 年 4 月 IETF 通过的 RFC3089 中所描述的 Fake IP，是四层代理分流场景下 性能相对最佳、体验相对最好、实现相对最简单的「最佳实践」。相比之下，Real IP 模式下为了尽可能接近 Fake IP 的性能、体验，需要大量额外配置、付出更多的代价。 好久没写网络相关的科普文了，这次借着搬家的机会，我重新设计了一下的网络架构、给自己的公寓组网，写一篇上万字的组网碎碎念记录一下。 我使用 Surge Mac 作为网络核心有一段时间了。虽然 Surge 官方提供了一份「中国区用户推荐最小配置」，但是为了发挥 Surge 全部潜力的话、彻底值回 Surge 的售价、实现我的复杂需求，我添加了许多自定义的配置。 众所周知，DNS 的作用与电话簿类似，将人类可读的域名映射到机器可读 IP 地址、使人更方便地访问互联网。DNS 是非常重要的互联网基础设施，对于改善上网冲浪的体验中的重要程度不容小觑。 哪个男孩不想拥有一个速度非常快的博客（跑）。之前我写过一些文章介绍如何统计网页的加载性能，在「前端性能监测和回传 Google Analytics」一文中就介绍了 Navigation Timing API 和 Google Analytics ... 虽然 Fake IP 这个概念早在 2001 年就被提出来了，但是到 Clash 提供 fake-ip 增强模式以后，依然有很多人对 Fake IP 这个概念以及其作用知之甚少。本文就简单谈谈在代理环境中，TCP 连接建立之前发生的事。由于移动设备操作系统中网络栈相对复杂，本文的例子也并不一定适用于移动端环境。文章中也许会存在很多错误，也希望各路大佬的勘误和斧正。 DNS 是互联网的基石之一，之前我在博客的 DNS 标签下写了不少关于权威 DNS 的文章，这次写一篇关于递归 DNS（也就是公共 DNS）的文章，从公共 DNS 的必要性、利弊来讲一讲选择公共 DNS 需要关注的事情，以及列举一些当前主流的公共 DNS。 记录阿里云 BGP Anycast (140.205.1.0/24) 路由路径。阿里云的 Anycast 调的真的非常糟糕。（更新日期 2019 年 8 月 1 日） TL;DR如果权威 DNS 的 NS 是自身，就需要向 Glue Record 查询解析记录，向 Glue Record 请求得到的自身的解析记录可以和 Glue Record 不同，然后下一步的解析请求会发往这个记录。 
![如何选择适合的公共 DNS？ [2020]](https://img.skk.moe/blog/t2018/which-public-dns-to-use.png)
