DNS查询平时几乎感知不到。浏览器输入网址页面加载完成，很少有人会关注背后的流程。等到排查网络故障，或是自行搭建DNS服务，才会发现查询分为多种类型，每种查询的访问链路、通信协议、适用场景都不一样。
最常用的是正向查询，也就是通过域名解析出对应IP地址。访问example.com的时候，系统先要获取服务器IP。查询请求由操作系统解析器发起，发送到手动配置的DNS服务器，例如114.114.114.114或者8.8.8.8。DNS服务器缓存内存在记录就直接返回结果；缓存没有，服务器会继续发起查询。这种委托服务器完整查询的方式叫做递归查询，客户端只发送一次请求，剩下所有查询工作交给DNS服务器处理。电脑上配置的公共DNS服务器，绝大多数都在执行递归查询。
但DNS服务器之间互相查询，采用的不是递归模式。根域名服务器不会帮你查到example.com最终IP，只会返回提示：该域名归属.com服务器，需要向.com服务器查询。之后.com服务器继续告知，去访问example.com权威服务器。一层一层返回查询线索，不会一次性返回最终结果，该方式称作迭代查询。递归和迭代的区别简单概括，递归是委托对方查完返回答案，迭代只告诉你下一个查询目标。
正向查询是域名转IP，反向查询刚好相反，依靠IP查找对应的域名。这项功能应用场景不少。邮件服务器收到来信，会提取发件IP执行反向查询，比对IP对应的域名是否和发件方宣称域名一致。信息不匹配大概率是伪造发件人，邮件会直接拒收。反向查询使用独立命名空间，IP地址倒序拼接in-addr.arpa后缀。例如查询192.0.2.1，实际请求的是1.2.0.192.in-addr.arpa的PTR记录。这个格式看着别扭，属于DNS系统固有设计，无法修改。
按照传输协议划分，传统DNS默认使用UDP 53端口。UDP协议无需握手，响应速度快，适配这类一问一答的轻量查询。UDP存在限制，响应报文大小超过512字节就会截断，客户端自动切换TCP 53重试。区域传输这类大批量数据同步，直接使用TCP协议。后续出于隐私保护需求，陆续出现加密查询方案。DoT即DNS over TLS，使用853端口，DNS查询报文封装在TLS加密通道。DoH全称DNS over HTTPS，占用443端口，流量和普通网页请求外观一致，运营商很难识别。Firefox和Chrome浏览器原生支持DoH，安卓系统私人DNS功能底层就是DoT。DoQ基于QUIC协议，延迟更低，目前还处在普及阶段，支持该协议的解析器数量不多。
排查DNS故障，命令行工具使用频率最高。dig返回信息最完整，可以查看查询流程、响应耗时、权威服务器返回完整记录。nslookup跨平台兼容，Windows和Linux都内置，输出简洁。host输出内容更加精简，适合快速验证单条记录。三款工具默认读取系统配置DNS，也可以手动指定查询服务器，例如dig @8.8.8.8 example.com，直接向谷歌DNS发起查询。在线DNS查询网站适合查看全球各地解析状态，dnschecker.org和whatsmydns.net能够同时查询数十个国家节点，用来判断解析是否生效、是否存在地域污染，直观方便。
编程开发层面，操作系统提供getaddrinfo()接口，封装DNS查询逻辑，返回可以直接建立网络连接的地址结构体。Python调用socket.getaddrinfo，Go使用net.LookupHost，原理相近。云厂商和公共DNS还提供HTTP API，Cloudflare的1.1.1.1、谷歌DNS都开放JSON接口，适合代码批量查询或者监控采集。
缓存查询严格来说不属于独立查询类型，但实际DNS请求里绝大部分都是缓存命中。操作系统、浏览器、本地DNS服务器都各自维护缓存。TTL参数控制记录缓存留存时长。TTL设置偏大，解析响应更快，但修改记录之后全网生效周期变长；TTL设置偏小，记录变更生效快，但会增加DNS查询压力。很多DNS故障根源不是查询本身出错，而是缓存未刷新或者TTL参数设置不合理。
还有一类查询叫做区域传送，包含AXFR全量同步与IXFR增量同步。普通用户基本接触不到，用来在主DNS服务器和从DNS服务器之间同步区域文件。AXFR一次性传输全部记录，IXFR只同步发生变更的内容。开放AXFR属于经典安全漏洞，任何人都可以拉取整套DNS区域文件，获取所有子域名、IP、邮件服务器信息。配置DNS服务器的时候，AXFR必须限制访问源IP。
日常使用不需要记住全部这些概念。浏览器上网使用递归查询，很多时候还启用DoH加密。排查问题优先用dig或者nslookup，想看全球解析结果就打开在线查询网站。反向查询基本交给邮件服务器自动处理。每种查询方式都有对应的适用场景，不存在万能方案。