漫谈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修改生效的方式也是造福一类的一件事,

不断探索中。。。

原文地址:https://www.cnblogs.com/luxianghao/p/6189633.html