Results tagged “dns”

在FreeBSD上使用OpenVPN的时候不能自动更改DNS，手动更新resolv.conf之后呢，等到DHCP renew地址的时候就再次被改回去了。

解决之道是在/etc/dhclient.conf里写下如下即可保持自行设置的DNS在第一个位置上。

prepend domain-name-servers 8.8.8.8;

BTW: 自行设定DNS之后就要把内部域名的解析换成/etc/hosts。当然也可以在本地搭一个BIND，把内部域名给forward到内部DNS去（此王道也！）。

发生在解析服务器和其它DNS服务器的传输时间，有三个原因。

• 无缓存。无缓存就要查其它的NS。
• 无法服务。要查的NS如果过载，就可能发生请求被丢弃或重发。
• 恶意的流量。DoS，重点是攻击，人为造成第二种情况甚至更严重。

无缓存的情况有一些数据，NS服务器拿到一个无缓存的请求，会导致至少1次的外部NS查询，一般情况会是2次以上。

根据Googlebot的情况来看，平均解析时间是130ms，然而还有4-6%的请求会直接超时，这通常是UDP丢包或服务器无法到达。把丢包，死NS，NS配置错误等因素都计算进来的话，实际的解析时间是300-400ms。

无缓存的情况较难避免，原因有三：

• internet太大而且还在成长。新用户和新网站都在增长，并不是所有的网站都是那么的流行，所以大部分的请求都是无缓存的情况。
• TTL太短，这个好象是个趋势，短TTL带来的就是更多的NS请求。
• 缓存是相对隔离的，NS大多放在LB设备下，缓存是随机的。所以就增加了无缓存的情况。

Google采用了一些方法，如下：

• 提供足够的服务器。
• 避免恶意攻击。
• LB使用共享的缓存。
• 预抓取名字解析。
• 提供全球服务。

DNS的动态更新是在RFC 2136里引入的，BIND8以后就支持了这一特性。用起来还是挺不错的。

Notify机制是在RFC 1996中提出来的，也是在BIND8以后支持的，微软的DNS服务器也是支持这一特性的。

Notify的工作原理是这样的：发现一个master zone的序列号发生改变之后，向该zone的所有slave发送一个变更通知。而确定slave的方法就是查NS记录，然后去掉SOA记录中的master。

上面这个机制在一个有load balancer的环境里就有问题了，NS记录里只记录的是load balancer的一个虚拟IP，master的notify就不可能完整的送达所有的slave。BIND有一个also-notify的参数，以解决这类问题。

@ IN NS ns
@ IN MX mail
@ IN CNAME www
www IN A 10.1.1.1
mail IN A 10.1.1.2