DNS 发生在 TCP/IP 之前。前面已经提过，到 TCP/IP 协议栈的时候已经是有 IP 地址了。为什么不把 DNS 定义在 TCP/IP 里呢？反正网络请求都是 TCP/IP 负责，如果发现是域名就顺便解析一下呗。
这就是架构设计的美妙。联想一下我们实际生活的场景，你要寄一个礼物给远方的朋友，收件员来了，他会关心收件人的地址你是怎么查到的吗？他有提供根据收件人姓名提供地址的服务吗？他顺便做了也很好啊。没做是因为这不是他们的核心业务。同样，TCP/IP 只负责通讯，不负责 IP 地址的查询。
真相就是操作系统进行的 DNS 查询。所以在操作系统的网络设置中，可以进行 DNS 服务器的配置。操作系统也同时管理了 DNS 的缓存。《iOS网络请求优化之DNS映射》中提到：
像 iOS 系统一般是 24 小时之后会过期，还有进入飞行模式再切回来，开关机，重置网络设置等也会导致 DNS cache 的清除。所以一般情况下用户在第二天打开你的 app 都会经历一次完整的 DNS 解析请求。
DNS 如何工作
一个简单的版本，在世界的中心有一台服务器，服务器里有一个数据库，数据库里有一张表，这张表里存着域名和 IP 地址的记录。你想要查什么服务器都给你。
如果产品经理描述应该就是这样的，接着会说这是一个小需求，什么时候可以上线。
DNS 不仅只是查询 IP
除了域名解析的 A 记录。还包括了 MX（Mail eXchange）邮件服务器地址，还有别名 CNAME 记录。
实际上还有很多其他功能，比如根据 IP 地址反查域名（PTR），查询域名 DNS 服务器 IP 地址（NS）。
假设我们要解析这个域名的 IP ，会去系统配置的 DNS 服务器查，如果 DNS 服务器没有这个域名的缓存，则会去根域名的服务器查出负责 com 域名的服务器，接着再从 com 找到 apple 的域名。
如果我们就持有 apple 域名，apple 下的子域名我们可以自己控制。有两种控制方式，一种是直接把子域名一起注册到 apple 域名里，记录在 com 域名服务器下。一种是自建 name server，就是前面提到的 NS 记录。此时向 com 域名查询 apple，会返回你自己配置的 name server 服务器地址，解析就由你自己控制了。
