漫谈DNS

   文章作者：luxianghao

   文章来源：http://www.cnblogs.com/luxianghao/p/6189633.html  转载请注明，谢谢合作。

   免责声明：文章内容仅代表个人观点，如有不当，欢迎指正。

   ---

为什么会有DNS？

在internet的世界里最早是只有IP的，这就要求人们人们去浏览一些站点的时候必须记住对应的IP地址，

但人们对数字的记忆能力显然不怎么样，这样就催生出了DNS的服务，借助于这个服务，人们可以给一些

IP地址起个名字，如给111.13.101.208起个外号叫baidu.com, 这样人们访问baidu.com跟访问

111.13.101.208是一个效果；但是DNS服务也不是完全没有坏处，首先人们需要维护这样一个服务，增加

了维护成本，然后现在有的服务架构中对DNS是强依赖的，如果DNS不可用，对应的服务也将不可用。

 

DNS的正解和反解

正解：由主机名查到IP

反解：由IP查询主机名

不管正解和反解，每个领域的所有记录就是一个域，如example.net就是一个域

 

DNS Linux环境下的配置

存放位置: /etc/resolv.conf 

内容：

search example.net

nameserver 10.118.6.6
nameserver 10.118.7.6

其中example.net是默认的域，比如nslookup web1 = nslookup web1.example.net

10.118.6.6是DNS server的IP地址

 

常用的DNS查询的命令

ping:

是个一个简单的丢包诊断工具，主机查询是顺带的作用, ping会使用一切的方式去解析主机名或者ip，

缓存 /etc/hosts 等，这可能取决于你的配置和操作系统，在去向dns server查询之前，ping会首先

使用如/etc/hosts 缓存等其他方式

 

host, nslookup, dig是专门用来做DNS查询的，简单列几个使用示例

host web1

nslookup web1

nslookup web1 10.118.6.6        # 指定DNS server来查询

dig web1

dig web1 @10.118.6.6             # 指定DNS server来查询，可绕过缓存

dig +short web1                      #仅获取IP地址

dig +trace web1.example.net    #获取递归过程的查询结果

dig -x 192.168.10.32               #反解得到域名

 

由于DNS是层层托管的方式，查询的时候也是递归的查询，比如查询web1.example.net需要先访问域为

.net的DNS server，由此查询到example.net的DNS server,最终查询到web1.example.net对应的记录

 

比起nslookup，我更喜欢dig，因为dig出来的信息比nslookup出来的信息更加翔实，如用dig出来的信息包含

TTL：DNS缓存时间

query time：查询时间，这对于DNS server查询慢的时候的故障排查很重要

SERVER：查询访问的DNS server

 

对于具体的报错信息，举例如下

nslookup返回的结果：server can't find www.example.net: REFUSED

dig返回的结果： WARNING: recursion requested but not available

从两种返回结果我们都可以看出，DNS server已经正常启动并能够响应，不过请求被拒绝了，

但是从dig的请求中我们还可以看出，请求被拒绝的原因是递归的请求不可用

[root@test.bj ~]# dig baidu.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63255
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;baidu.com. IN A

;; ANSWER SECTION:
baidu.com. 35 IN A 111.13.101.208
baidu.com. 35 IN A 123.125.114.144
baidu.com. 35 IN A 180.149.132.47
baidu.com. 35 IN A 220.181.57.217

;; Query time: 34 msec
;; SERVER: 10.118.6.6#53(10.108.6.6)
;; WHEN: Sat Dec 17 13:36:43 2016
;; MSG SIZE rcvd: 91

 

[root@test.bj ~]# nslookup baidu.com

Server: 10.118.6.6
Address: 10.118.6.6#53

Non-authoritative answer:
Name: baidu.com
Address: 111.13.101.208
Name: baidu.com
Address: 123.125.114.144
Name: baidu.com
Address: 180.149.132.47
Name: baidu.com
Address: 220.181.57.217

关于递归查询

很多组织为了安全起见，都严格限制了能够像他们发起递归查询的主机

相关配置的所在地址：

/etc/bind/named.conf

具体的配置示例：

options {

    recursion no;

    ...

}

options {

    allown-recursion {10.1.1.0/24}; #10.1.1.0整个子网可以

    ...

}

acl "internel" {127.0.0.1; 10.1.1.0/24;};

options {

    allown-recursion {"internel"}; #以上acl中的IP可以

    ...

}

 

关于DNS缓存

作用：

1) 可以更快速的响应查询请求

2）可以减轻DNS server负载，所以有些DNS server会直接忽略掉特别小的TTL，然后重写一个合理的值

但是DNS缓存也会造成自己的更改迟迟不能生效等问题

除了DNS server有缓存，如下的情况也能造成DNS缓存，当有DNS server调整的时候要格外关注，以避免不必要的损失

JAVA：由于 Java缓存的原因，可能会导致JAVA进程不会使用系统中新的 DNS服务配置，导致期间出现解析失败的情况。

Java对dns 的缓存默认是forever, refer to http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html

解决方法：重启Java进程

操作系统：

在Linux中，nscd daemon会处理这类缓存

解决方法：/etc/init.d/nscd restart

DNS server:
解决方法：/etc/init.d/named restart

其他的解决方法：绑定/etc/hosts 

提示：在实际的生产环境中，并不建议绑定/etc/hosts，另外这种绑定仅支持A记录，并不支持CNAME 

 

如果你并不着急，可以慢慢等缓存失效

但如果你等待的时间已经超出缓存时间，修改仍不生效，那可能是

1）修改后的配置有语法错误，DNS server会自动忽略错误的配置，继续使用上次ok的配置，可以查syslog或message查相关的报错信息

2）主DNS server的更改没能同步到slave的DNS server，原因可能是，中间网络的问题；salve没配置相关的主server， 拒绝了更新通知；

slave server的版本号大于主的待更新的版本号

 

另外在实际的生产环境中DNS 的生效时间直接决定了工作效率，故障时间等，所以能够寻求快速的使DNS修改生效的方式也是造福一类的一件事，

不断探索中。。。