named查询使用的是UDP协议和端口53。响应通过UDP返回，除非他们大于512K，这种情况使用TCP。服务器之间的“区传送”则都使用TCP。
委托：所有的名字服务器都知道根服务器。而根服务器又都知道gTLD，顺着这条链进一步往下，edu知道fudan.edu，com知道china.com...依次类推。实例：假设我希望从机器marco.comp.fudan.edu查询机器cs.military.china.com，这里假设查询之前，除了根服务器的名称和IP地址之外没有高速缓存任何这里需要用到的信息。顺序是这样的（主机marco询问它的本地名字服务器ns.comp.fudan.edu，而ns.comp.fudan.edu是一个递归的名字服务器，因此，它将代替主机marco来查询。由于它不知道这个地址，且不知道有关military.china.com或china.com甚至不知道.com的任何信息。不过它知道根域的一些服务器，根域知道有关.com的数据，因此发送引用给ns.comp.fudan.edu，本地名字服务器随后就将查询发送到.com，返回一个china.com的推荐，同样重复发送查询到china.com，返回military.china.com服务器的推荐，这样military.china.com对于这个查询信息是权威的，并返回cs的地址。这样就完成了整个过程，哦，不对，还有一点，ns.comp.fudan.edu会在这个过程进行中告诉缓存主机cs的地址，同时缓存了.com,china.com,military.china.com的服务器列表。
高速缓存和效率：高速缓存机制在过去仅能用于肯定的回答，假如找不到主机名则布包存这种实际情况。而RFC1034和RFC2308则先后定义并升级了用于否定告诉缓存的方案。在BIND8.2中是一个可选功能，而在9中已经成为一个必选的功能了。它将保存一下否定类型的回答（其中前两种否定数据的类型缓存时间为1－3小时，其他类型缓存5分钟）：
没有与要查询的名称匹配的主机或域
该主机不存在要查询的数据类型
询问的服务器无响应
因为网络问题，服务器不可达
扩展的DNS协议：90年代末期，EDNS0（扩展DNS，版本0）解决了今天的因特网中DNS协议的一些缺点。它答应发言人宣告其组装缓冲区大笑，可支持选项和通信协议版本。假如接受方的名字服务器以一条错误消息作为响应，那么发送方就退回去使用原来的DNS协议。BIND9在服务器和解析器中都实现了EDNS0。^_^。
