标签: dns

解决基于openwrt的路由内网地址无法解析的问题

具体问题和资料看前面两篇博客啦。主要引起原因为DNSMASQ的“Prevent DNS-rebind attacks”的安全配置,拒绝解析内网地址包。

解决方法
方法一,直接关闭该安全配置
打开路由后台->网络->DHCP/DNS->一般设置->重绑定保护(丢弃RFC1918上行响应数据)
把这个的勾去掉,就关闭了该安全设置

方法二,按照上面的设置不关闭安全设置,直接在下面“域名白名单”中输入需要响应的域名就可以了。

注意:刚才测试了一下,把域名的A记录设置成内网地址,就会产生这样的问题。

关于上一篇DNS无法解析的一些资料

经过南浦月童鞋的帮助,找到了一些资料,基本确定问题就在这里,还在琢磨原理中,特此记录下资料。

 

Openwrt下DNSMASQ处理本地扁平域名解析的一些要点
http://blog.sina.com.cn/s/blog_6fd1ff790101hs5u.html

 

这里所谓扁平域名(plain name)指的是不包括一级和二级域名的名字,通常在直接访问同属于一个局域网内的机器时使用。
刚刷完Openwrt的路由器,如果启用了DHCP,则DNSMASQ会同时启用DNS转发,缺省的配置对于本地域名解析(局域网内部域名,只能由局域网内的DNS解析)会有些问题,做nslookup的时候返回“No answer”。此时需要修改Openwrt里面的配置,有两种办法:
1、修改/etc/config/dhcp这个文件:
找到 option rebind_protection ‘1’ 这一行,将’1’改成’0’,这是开启本地域名解析。
找到 option domain ‘lan’ 这一行,将’lan’改成你想要的二级和一级域名后缀,比如“sina.cn”。
2、利用luci提供的web界面
在Network -> DHCP and DNS -> General Settings里面找到“Rebind protection”,去掉勾选。同一页,找到“Local domain”,将里面的“lan”改成你想要的二级和一级域名后缀,比如“sina.cn”。点“Save & Apply”。
这样DNSMASQ在转发DNS请求的时候,会在扁平域名后面自动加上二级和一级域名。

 

解决DNSMASQ内网地址无法解析No address (A) records available
http://wangye.org/blog/archives/976/

 

部署DNSMASQ有一段时间了,最近发现一个奇怪现象,所有内网网站均无法解析,通过nslookup命令,得到如下结果:

Server: 192.168.24.6
Address: 223.5.5.5

*** No address (A) records available for oa.example.com
其中oa.example.com是内网域名,当然这里我只是举个例子:-) 域名管理员已经将该域名解析到一个私有内网地址上,外部DNS服务器均能正常解析这个域名,唯独部署了DNSMASQ的域名服务器无法解析。

开始时并没有介意,而是通过硬绑定的方式在DNSMASQ的配置文件中将内网地址映射到oa.example.com,配置方式如下:

address=/oa.example.com/192.168.25.4

这里oa.example.com是我们要映射的域名,192.168.25.4是我们要给该域名绑定的IP地址,值得注意的是当你做出这样的配置后,所有查询oa.example.com均不在走上游DNS服务器或者权威服务器,而是由DNSMASQ直接返回配置的应答,当然这个方法也可以用作屏蔽网站,只要把要屏蔽的网站映射到127.0.0.1即可。

某天域名管理员看到了这样的配置说到:如果我哪天更改了oa.example.com的服务器IP地址怎么办,毕竟你这个是硬性编码的,并不能和权威DNS服务器保持同步。域名管理员的话也有道理,虽然域名解析改动不频繁,但是每次改动也不可能及时通知并做出反应。

于是我开始寻找一个正确的解决这个问题的办法,功夫不负有心人我找到了这篇文章《dnsmasq, Split DNS and the Dreaded “No address (A) records available” Error》。

原来DNSMASQ有个的“Prevent DNS-rebind attacks”的安全配置,这个配置参数和描述如下:

–stop-dns-rebind
Reject (and log) addresses from upstream nameservers which are in the private IP ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network.
这项安全设置是拒绝解析包含私有IP地址的域名,这些IP地址包括如下私有地址范围:

A:10.0.0.0~10.255.255.255 即10.0.0.0/8
B:172.16.0.0~172.31.255.255 即172.16.0.0/12
C:192.168.0.0~192.168.255.255 即192.168.0.0/16
而其初衷是要防止类似上游DNS服务器故意将某些域名解析成特定私有内网IP而劫持用户这样的安全攻击。

了解了这个选项配置的作用,接下来我介绍两个解决的办法:

1. 直接在配置文件中取消stop-dns-rebind配置项从而禁用该功能。这个方法确实可以一劳永逸的解决解析内网IP地址的问题,但是我们也失去了这项安全保护的特性,所以在这里我不推荐这个办法。

2. 使用rebind-domain-ok进行特定配置,顾名思义该配置项可以有选择的忽略域名的rebind行为,其具体官方描述如下:

–rebind-domain-ok=[]|[[//[/]
Do not detect and block dns-rebind on queries to these domains. The argument may be either a single domain, or multiple domains surrounded by ‘/’, like the –server syntax, eg. –rebind-domain-ok=/domain1/domain2/domain3/
举个例子,对于oa.example.com这样包含内网IP的域名配置文件这样写:

rebind-domain-ok=/oa.example.com/
经过这样的配置后,DNSMASQ将默认允许oa.example.com的rebind行为,也就是说内网IP地址将能够正常返回而不被过滤了。

当然如果某个域名下的包含内网地址的子域名特别多,可以使用通配的方法:

rebind-domain-ok=/.example.com/
这样任何属于example.com的子域名将均不接受rebind攻击检测了,所有的关于example.com子域名的私有内网IP都能正常解析。注意.example.com前面的点。

 

 

DNS解析过程详解
http://blog.chinaunix.net/uid-28216282-id-3757849.html

 

先说一下DNS的几个基本概念:

一. 根域

就是所谓的“.”,其实我们的网址www.baidu.com在配置当中应该是www.baidu.com.(最后有一点),一般我们在浏览器里输入时会省略后面的点,而这也已经成为了习惯。
根域服务器我们知道有13台,但是这是错误的观点。
根域服务器只是具有13个IP地址,但机器数量却不是13台,因为这些IP地址借助了任播的技术,所以我们可以在全球设立这些IP的镜像站点,你访问到的这个IP并不是唯一的那台主机。
具体的镜像分布可以参考维基百科。这些主机的内容都是一样的

二. 域的划分
根域下来就是顶级域或者叫一级域,
有两种划分方式,一种互联网刚兴起时的按照行业性质划分的com.,net.等,一种是按国家划分的如cn.,jp.,等。
具体多少你可以自己去查,我们这里不关心。
每个域都会有域名服务器,也叫权威域名服务器。
Baidu.com就是一个顶级域名,而www.baidu.com却不是顶级域名,他是在baidu.com 这个域里的一叫做www的主机。
一级域之后还有二级域,三级域,只要我买了一个顶级域,并且我搭建了自己BIND服务器(或者其他软件搭建的)注册到互联网中,那么我就可以随意在前面多加几个域了(当然长度是有限制的)。
比如a.www.baidu.com,在这个网址中,www.baidu.com变成了一个二级域而不是一台主机,主机名是a。
三. 域名服务器
能提供域名解析的服务器,上面的记录类型可以是A(address)记录,NS记录(name server),MX(mail),CNAME等。
(详解参见博客:域名解析中A记录、CNAME、MX记录、NS记录的区别和联系)
A记录是什么意思呢,就是记录一个IP地址和一个主机名字,比如我这个域名服务器所在的域test.baidu.com,我们知道这是一个二级的域名,然后我在里面有一条A记录,记录了主机为a的IP,查到了就返回给你了。
如果我现在要想baidu.com这个域名服务器查询a.test.baidu.com,那么这个顶级域名服务器就会发现你请求的这个网址在test.baidu.com这个域中,我这里记录了这个二级域的域名服务器test.baidu.com的NS的IP。我返回给你这个地址你再去查主机为a的主机把。
这些域内的域名服务器都称为权威服务器,直接提供DNS查询服务。(这些服务器可不会做递归哦)
四.解析过程
那么我们的DNS是怎么解析一个域名的呢?

1.现在我有一台计算机,通过ISP接入了互联网,那么ISP就会给我分配一个DNS服务器,这个DNS服务器不是权威服务器,而是相当于一个代理的dns解析服务器,他会帮你迭代权威服务器返回的应答,然后把最终查到IP返回给你。
2.现在的我计算机要向这台ISPDNS发起请求查询www.baidu.com这个域名了,(经网友提醒:这里其实准确来说不是ISPDNS,而应该是用户自己电脑网络设置里的DNS,并不一定是ISPDNS。比如也有可能你手工设置了8.8.8.8)
3.ISPDNS拿到请求后,先检查一下自己的缓存中有没有这个地址,有的话就直接返回。这个时候拿到的ip地址,会被标记为非权威服务器的应答。
4.如果缓存中没有的话,ISPDNS会从配置文件里面读取13个根域名服务器的地址(这些地址是不变的,直接在BIND的配置文件中),
5.然后像其中一台发起请求。
6.根服务器拿到这个请求后,知道他是com.这个顶级域名下的,所以就会返回com域中的NS记录,一般来说是13台主机名和IP。
7.然后ISPDNS向其中一台再次发起请求,com域的服务器发现你这请求是baidu.com这个域的,我一查发现了这个域的NS,那我就返回给你,你再去查。
(目前百度有4台baidu.com的顶级域名服务器)。
8.ISPDNS不厌其烦的再次向baidu.com这个域的权威服务器发起请求,baidu.com收到之后,查了下有www的这台主机,就把这个IP返回给你了,
9.然后ISPDNS拿到了之后,将其返回给了客户端,并且把这个保存在高速缓存中。

下面我们来用 nslookup 这个工具详细来说一下解析步骤:

从上图我们可以看到:
第一行Server是:DNS服务器的主机名–210.32.32.1
第二行Address是: 它的IP地址–210.32.32.1#53
下面的Name是:解析的URL– www.jsjzx.com
Address是:解析出来的IP–112.121.162.168

但是也有像百度这样的DNS比较复杂的解析:

你会发现百度有一个cname = www.a.shifen.com 的别名。
这是怎么一个过程呢?
我们用dig工具来跟踪一下把(linux系统自带有)
——————————————————————————————————————————————————————————————————————————
Dig工具会在本地计算机做迭代,然后记录查询的过程。

第一步是向我这台机器的ISPDNS获取到根域服务区的13个IP和主机名[b-j].root-servers.net.。

第二步是向其中的一台根域服务器(Servername就是末行小括号里面的)发送www.baidu.com的查询请求,他返回了com.顶级域的服务器IP(未显示)和名称,

第三步,便向com.域的一台服务器192.33.4.12请求,www.baidu.com,他返回了baidu.com域的服务器IP(未显示)和名称,百度有四台顶级域的服务器
【此处可以用dig @192.33.4.12 www.baidu.com查看返回的百度顶级域名服务器IP地址】。

第四步呢,向百度的顶级域服务器(202.108.22.220)请求www.baidu.com,他发现这个www有个别名,而不是一台主机,别名是www.a.shifen.com。

———————————————————————————————————————————————————————————————————————————
按照一般的逻辑,当dns请求到别名的时候,查询会终止,而是重新发起查询别名的请求,所以此处应该返回的是www.a.shifen.com而已。
但是为什么返回a.shifen.com的这个域的NS呢?
我们可以尝试下面的这个命令:dig +trace shifen.com 看看有什么结果。。。。。。。。

你会发现第三步时shifen.com这个顶级域的域名服务器和baidu.com这个域的域名服务器是同一台主机(即:dns.baidu.com)!

当我拿到www.baidu.com的别名www.a.shifen.com的时候,我本来需要重新到com域查找shifen.com域的NS,但是因为这两个域在同一台NS上,所以直接向本机发起了,
shifen.com域发现请求的www.a.shifen.com是属于a.shifen.com这个域的,
于是就把a.shifen.com的这个NS和IP返回,让我到a.shifen.com这个域的域名服务器上查询www.a.shifen.com。
于是我便从ns X .a.shifen.com中一台拿到了一条A记录,最终的最终也便是www.baidu.com的IP地址了.【此处也可以用dig +trace www.a.shifen.com】跟踪一下
用一个图来说明一下(图中第三步的全世界只有13台是错误的)

以下内容为在虚拟机中搭建local dns服务器得到的实验数据,纠正上述结论
在上面的分析中,我们用dig工具进行了追踪,但是dig没有继续追踪当我们从baidu.com拿到cname和ns2.a.shifen.com的IP之后的事情。
我们就所以然的下结论认为local dns会向ns2.a.shifen.com请求www.a.shifenc.om。
其实这个想法是错误,在自己的本地搭建一个local dns,抓取整个解析过程中是所有包,看看就明白拉。
实际的结果是虽然dns.baidu.com返回了a.shifen.com域的服务器地址和IP,
但是local dns并不是直接向上述返回的IP请求www.a.shifen.com,而是再一次去请求com域,得到shifen.com域的服务器(也就是baidu.com的那四台),
然后又请求www.a.shifen.com,返回a.shifen.com的域的服务器,最后才是去请求www.a.shifen.com,
虽然上面已经返回了IP,但是实验的结果就是再走一遍shifen.com域的查询。

上图就是localdns在解析www.baidu.com的抓包全过程。蓝色那条就是在收到cname和响应的a.shifen.com的域名服务器IP地址之后,继续向com域请求shifen.com。

这个图充分说明了返回cname的同时也返回了ns2.a.shifen.com的IP。
因此总结一下便是
①本机向local dns请求www.baidu.com
②local dns向根域请求www.baidu.com,根域返回com.域的服务器IP
③向com.域请求www.baidu.com,com.域返回baidu.com域的服务器IP
④向baidu.com请求www.baidu.com,返回cname www.a.shifen.com和a.shifen.com域的服务器IP
⑤向root域请求www.a.shifen.com
⑥向com.域请求www.a.shife.com
⑦向shifen.com请求
⑧向a.shifen.com域请求
⑨拿到www.a.shifen.com的IP
⑩localdns返回本机www.baidu.com cname www.a.shifen.com 以及 www.a.shifen.com的IP

一个想不通的DNS解析问题

最近遇到有关DNS解析的一些问题。经过设置openwrt的dns,问题已经解决,但是原理还没有弄懂,特此记录。

首先介绍一下网络状况。
1、内网专线隧道连接公司总部,外网走电信出口
2、由于公司自己内网架设了DNS,而且经测试,必须是指定该DNS在本地才能够上网,其他公用dns都不行,怀疑是否在防火墙处设置了一些过滤,其中原理不太清楚。有没有同学懂得?
遇到的状况是,公司内部接小路由器,设置wan口ip地址和DNS地址都为公司要求的,但是客户计算机dhcp自动获取地址后,上不了公司内网网站,只能访问互联网,经测试发现内网链路是通的,但是DNS无法解析到相应的地址。

查看客户计算机发现获取到的DNS服务器地址为192.168.1.1。经过手动设置DNS为公司指定的,可以正常上网。

经过测试发现,openwrt的路由器,大部分获取的DNS为192.168.1.1。tp-link则直接获取到了公司DNS,所以能直接上网。不得不感叹tp-link的默认设置还是能兼容绝大多数网络状况的,易用性很高。

但是问题也来了,为什么获取到192.168.1.1为dns的客户端还能够正常访问外网呢?192.168.1.1不是轮询找wan口设置的dns获取解析吗?为什么外网能解析,内网地址就不能解析了。一直不理解。有没有懂的同学帮忙分析分析。

以下是nslookup测试结果

C:\Users\admin>nslookup www.baidu.com
服务器: PandoraBox_6F5A.lan
Address: 192.168.1.1

非权威应答:
名称: www.a.shifen.com
Addresses: 14.215.177.37
14.215.177.38
Aliases: www.baidu.com
C:\Users\admin>nslookup www.qq.com
服务器: PandoraBox_6F5A.lan
Address: 192.168.1.1

非权威应答:
名称: www.qq.com
Addresses: 240e:e1:8100:28::2:16
14.17.42.40
14.17.32.211
59.37.96.63

 

找到了一个小资料,也许就是设置了这个?但是外网怎么又能上,还是理解不了。

http://support.huawei.com/ecommunity/bbs/10253036.html

DNS劫持功能
dns透明代理功能需要指定客户端设置的dns地址,但很多情况下并不知道客户端设置了什么,希望实现无论客户端如何设置DNS,只能dns请求包经过防火墙,都能转发到管理员指定的DNS服务器

问题描述:
1.存在一些恶意软件,会修改客户端的DNS地址,导向钓鱼网站;
2.要求用户使用内部的DNS服务器,但用户使用了外网DNS,导致部分内部网站无法访问

功能建议:
增加DNS转发功能,劫持通过防火墙的dns请求,转发至正确的dns服务器

PandoraBox、dreambox等基于OpenWRT路由DHCP分配给客户端指定的DNS地址方法

后台位置
接口->LAN->DHCP服务器->高级设置->DHCP选项:

设置DHCP的附加选项,例如设定”6,192.168.2.1,192.168.2.2″表示通告不同的DNS服务器给客户端。

比如我们设定公用DNS,可以这样填写6,114.114.114.114,8.8.8.8。这样就设定了114和谷歌的公用DNS。

在设置电脑自动DHCP获取的时候,就可以直接获取到DNS的地址。

用linux建立一个公网dns

首先介绍一下,dns服务器有三种类型。
一、转发dns
二、权威dns
三、非权威dns

建立步骤:

1、注册一个域名,建议在大的商家注册,不要在代理商注册,因为如果在代理商注册,域名转移将会是一个很痛苦的过程。

2、有一台服务器,具有固定IP。

3、在域名注册商注册dns服务器。此处不是说注册域名,而是在域名注册商处获得你的dns授权,即成为权威dns。godaddy的步骤如下:

(1)登陆 Account Manager。
(2)在 My Products 项目中, 点 Domain Manager。
(3)进入domain detail,拉到最下面,左边有一个 Host Summary 栏。
(4)点标题旁边的 add 连接。
(5)在 Host name 输入你的子域,例如你要创建ns1.moper.me,那就输入ns1。 注意: 不要设置”www”做为Dns的主机名。
(6)在 Host IP 里,输入IP地址,总共13个框,输入1个或多个。

一般.COM 和.NET是4~8小时生效,其他的域名为 24 到 48 小时生效。不过,一般5分钟左右就能查到这个DNS记录了。

最后你可以在http://www.internic.net/whois.html查询一下是否已经注册成功。

4、安装bind,本次搭建环境为centos6.2。
输入

yum -y install bind*

安装装所有关于bind的包。

5、设定bind
主要分为三部分

第一,设定/etc/named.conf

运行

cp /etc/named.conf /etc/named.conf.raw

复制一份默认的named.conf配置。

运行

vi /etc/named.conf

设定named.conf档案,档案内容如下:

options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { any; };
        recursion yes;
        allow-transfer  { none; };
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};
zone "moper.me" IN {
        type master;
        file "named.moper.me";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

只设定了moper.me的正解析。

(2)设定named.ca
此档案在centos6.2里的bind已经自带了。当然您也可以使用最新的http://www.root-servers.org/

(3)设定正解析named.moper.me

vi /var/named/named.moper.me
$TTL    600
@ IN SOA  ns1.moper.me. admin.moper.me. (2013082502 3H 15M 1W 1D)
@ IN NS ns1.moper.me.
ns1.moper.me.  IN A XXX.XXX.XXX.XXX
@ IN MX 10 mxdomain.qq.com.
www.moper.me. IN A XXX.XXX.XXX.XXX

第一个XXX的IP是要作为dns1的IP,第二个xxx的IP是加一个A记录,即主机头www加域名解析到XXX这个IP。

配置完成,启动bind使配置生效。

/etc/init.d/named start
chkconfig named on

参考资料
http://linux.vbird.org/linux_server/0350dns.php
http://bbs.unixidc.com/read.php?tid=853
http://hzyevaxl.blog.163.com/blog/static/9353763200942710221763/

CNAME值的DNS挟持问题

如果BIND的zone里有a.com和b.com两个域,BIND是a.com的权威服务器,但不是b.com的。用户设置www.a.com这个记录CNAME到www.b.com。在客户端查询www.a.com时,BIND会返回www.a.com和www.b.com的权威应答,显然www.b.com是DNS挟持。那么客户端如何应对?

这个问题我在BIND邮件列表里询问如下:

If BIND is authoritative for zone a, and is not authoritative for zone b, but zone b is configured in BIND’s zone file, and x.zonea.com is CNAME’d to y.zoneb.com.

When DNS client queries to this BIND for x.zonea.com, it gets the authoritative answers for both x.zonea.com and y.zoneb.com, certainly y.zoneb.com is a fake one.

How DNS client handle this case?

来自ISC的Mark回答如下:

It depends on the client and whether the zones are signed or not
and whether the client is validating responses or not.

Stub clients will almost always trust the complete answer.
For iterative clients it depends on their level of paranoia.

named is paranoid. It discards the rest of the response after processing
the CNAME.

如果客户端解析器是BIND,它在处理CNAME时,简单的丢弃掉CNAME值的剩余部分,重新解析CNAME的目的值,从而避免上述问题。

转自http://www.nsbeta.info/archives/294

谁负责NS记录的权威解析

今天有个读者来信问我,是本域的权威名字服务器,还是上一级名字服务器来权威应答域的NS记录?
这个问题正好借用腾讯DNS的不正确配置来回答。
早前一阵,我发现QQ的DNS配置有点问题,我们执行如下两个dig:

$ dig www.qq.com ns @ns1.qq.com

; <<>> DiG 9.4.2-P2.1 <<>> www.qq.com ns @ns1.qq.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50734 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.qq.com. IN NS ;; ANSWER SECTION: www.qq.com. 86400 IN NS ns-tel1.qq.com. www.qq.com. 86400 IN NS ns-tel2.qq.com. ;; AUTHORITY SECTION: qq.com. 86400 IN NS ns4.qq.com. qq.com. 86400 IN NS ns1.qq.com. qq.com. 86400 IN NS ns2.qq.com. qq.com. 86400 IN NS ns3.qq.com. ;; Query time: 7 msec ;; SERVER: 219.133.62.252#53(219.133.62.252) ;; WHEN: Sat Jul 9 08:58:38 2011 ;; MSG SIZE rcvd: 144 $ dig www.qq.com ns @ns-tel1.qq.com ; <<>> DiG 9.4.2-P2.1 <<>> www.qq.com ns @ns-tel1.qq.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44393 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.qq.com. IN NS ;; AUTHORITY SECTION: qq.com. 86400 IN SOA ns1.qq.com. webmaster.qq.com. 1293074536 300 600 86400 86400 ;; Query time: 7 msec ;; SERVER: 121.14.73.115#53(121.14.73.115) ;; WHEN: Sat Jul 9 08:59:07 2011 ;; MSG SIZE rcvd: 78 首先我们应知道www.qq.com是一个域,而不是一个普通域名。这里有问题的地方在于: (1)ns1.qq.com是qq.com的权威服务器,为什么它响应子域www.qq.com的NS记录的权威应答? (2)ns-tel1.qq.com是www.qq.com域的权威服务器,为什么它对NS查询没有返回任何结果? 当时我也不是很确认这个问题,于是在邮件列表上询问如下: First, why ns1.qq.com (which is the authoritative nameserver for the zone of qq.com, not www.qq.com) returns the authoritative answer for www.qq.com’s NS query? and even includes a AA flag in the response. Second, why ns-tel1.qq.com (which is the authoritative nameserver for the zone of www.qq.com) returns nothing for this zone’s NS query? 来自BIND开发组织isc.org的Mark对这2个问题作了回答。第一个问题: Because the nameserver is not RFC compliant. There are lots of broken nameservers out there. Early versions of BIND had this bug but we removed it over a decade ago. But it isn’t returning a referral when it should (the NS records are in the wrong section) and as it isn’t configured to server www.qq.com the “aa” is wrong. 很明显,qq.com的DNS并不兼容RFC,在查询www.qq.com的NS记录时,ns1.qq.com应该返回一个引用,但是它返回了www.qq.com域的权威NS记录,这是错误的。 第二个问题: Because it is misconfigured. Instead of serving www.qq.com it is configured to server qq.com which can be seen in all the negative answers it returns. Unfortunately lots of load balancers are similarly misconfigured. www.qq.com的NS服务器也配置错误,它未响应本域的NS查询是不应该的,而且其SOA记录提供了qq.com的NS服务器信息。这个NS服务器应该是F5的3DNS,它并非标准实现也就可以理解。 所以,总结如下: (1)域的NS记录的权威解析,一定是本域的权威服务器自身。它的上一级NS也许返回了权威解析(例如把glue记录放在ANSWER部分,并且设置aa flag),但这是不应该的(老的BIND8有这个问题)。客户端解析器,应该使用并缓存权威服务器返回的NS记录。 (2)权威服务器可以且应该返回域的NS记录。它如果不返回,会增加公共DNS和上一级NS的查询压力,是不好的DNS实现。 转自http://www.nsbeta.info/archives/115

Linux命令行修改IP、网关、DNS的方法

方式一:
ifconfig eth0 192.168.1.18 netmask 255.255.255.0
说明:该种方式可以使改变即时生效,重启后会恢复为原来的IP

方式二:
vi /etc/sysconfig/network-scripts/ifcfg-eth0
说明:该方式要重启后生效,且是永久的
如果要立即更改且永久生效,就只能以上两种方式同时使用了。
以上是通过linux命令行修改IP的方法。
网卡eth0 IP修改为 102.168.0.1
ifconfig eth0 102.168.0.1 netmask 255.255.255.0

网关修改为 102.168.0.254
route add default gw 102.168.0.254

Linux命令行修改dns
echo “nameserver 202.202.202.20 “>> /etc/resolv.conf
重启网络服务
例子:由原来的DHCP改固定IP
DEVICE=eth0
HWADDR=00:0C:29:F7:EF:BF
ONBOOT=yes
TYPE=Ethernet
NETMASK=255.255.255.0
IPADDR=192.168.0.68
GATEWAY=192.168.0.1
加上红色即可

重启网卡:
/etc/init.d/network restart
ifconfig eth0 新ip
然后编辑/etc/sysconfig/network-scripts/ifcfg-eth0,修改ip

[aeolus@db1 network-scripts]$ vi ifcfg-eth0

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=219.136.241.211
NETMASK=255.255.255.128
GATEWAY=219.136.241.254

[aeolus@db1 etc]$ vi resolv.conf

nameserver 202.96.128.68
nameserver 219.136.241.206

-----------------------
Linux下修改网卡IP和网关

建议通过终端字符方式下来修改
一修改IP地址
vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
IPADDR=192.168.1.33
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
USERCTL=no
PEERDNS=no
TYPE=Ethernet
~

vi /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.2.34
NETMASK=255.255.255.0
USERCTL=no
PEERDNS=no
TYPE=Ethernet
NETWORK=192.168.2.0
BROADCAST=192.168.2.255
二修改网关
vi /etc/sysconfig/network

NETWORKING=yes
HOSTNAME=Aaron
GATEWAY=192.168.1.1

三重新启动网络配置
/etc/init.d/network restart

———————————————————————————–

修改配置文件

/etc/sysconfig/network-scripts/ 下有配置文件

比如文件:ifcfg-eth0 代表是以太网实际网卡0的配置文件

比如文件:ifcfg-eth0:1 代表是以太网实际网卡0的配置文件

域名服务器配置文件:/etc/ resolv.conf

修改ip地址
即时生效:
# ifconfig eth0 192.168.0.20 netmask 255.255.255.0
启动生效:
修改/etc/sysconfig/network-scripts/ifcfg-eth0

修改default gateway
即时生效:
# route add default gw 192.168.0.254
启动生效:
修改/etc/sysconfig/network-scripts/ifcfg-eth0

修改dns
修改/etc/resolv.conf
修改后可即时生效,启动同样有效

修改host name
即时生效:
# hostname fc2
启动生效:
修改/etc/sysconfig/network
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0 接口名称
BOOTPROTO=none 静态配置,若该值为“dhcp”则为动态获得,另外 static也是表示静态ip地址
BROADCAST=192.168.10.255 广播地址,通过IP地址和子网掩码自动计算得到
HWADDR=00:13:D3:27:9F:80
IPADDR=192.168.10.238
IPV6INIT=yes
IPV6_AUTOCONF=yes
NETMASK=255.255.255.0
NETWORK=192.168.10.0 指定网络,通过IP地址和子网掩码自动计算得到
ONBOOT=yes 开机时自动加载
GATEWAY=192.168.10.1
TYPE=Ethernet
PEERDNS=yes
USERCTL=no

ifdown eth0 关闭网络
ifconfig eth0 down 关闭网络

ifup eth0 开启网络
ifconfig eth0 up 开启网络

设置dns
/etc/resolv.conf

nameserver 61.144.56.101
nameserver 202.96.128.166

[yeger@yeger ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 202.96.128.86
nameserver 202.96.128.166

其他方面
service network start //启动网络服务
service network stop //停止网络服务
service network restart //重启网络服务
service network status //查看网络服务状态

ifconfig eth0 192.168.10.222 netmask 255.255.255.0 //临时修改接口IP地址(无需重启接口)

[yeger@yeger ~]$ sudo ifconfig wlan0 192.168.21.199 netmask 255.255.255.0
[yeger@yeger ~]$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:02:72:77:BB:D1
inet addr:192.168.21.199 Bcast:192.168.21.255 Mask:255.255.255.0
inet6 addr: fe80::202:72ff:fe77:bbd1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3246 errors:0 dropped:0 overruns:0 frame:0
TX packets:1947 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4514869 (4.3 MiB) TX bytes:177732 (173.5 KiB)
wlan0 表示第一块无线以太网卡
Link encap 表示该网卡位于OSI物理层(Physical Layer)的名称
HWaddr 表示网卡的MAC地址(Hardware Address)
inet addr 表示该网卡在TCP/IP网络中的IP地址
Bcast 表示广播地址(Broad Address)
Mask 表示子网掩码(Subnet Mask)
MTU 表示最大传送单元,不同局域网 MTU值不一定相同,对以太网来说,MTU的默认设置是1500个字节
Metric 表示度量值,通常用于计算路由成本
RX 表示接收的数据包
TX 表示发送的数据包
collisions 表示数据包冲突的次数
txqueuelen 表示传送列队(Transfer Queue)长度
interrupt 表示该网卡的IRQ中断号
Base address 表示I/O地址
配置虚拟网卡IP地址:网卡需要拥有多个IP地址
命令格式: ifconfig 网卡名:虚拟网卡ID IP地址 netmask 子网掩码
[yeger@yeger ~]$ sudo ifconfig wlan0:1 192.168.21.188 netmask 255.255.255.0
更改网卡MAC地址
ifconfig 网卡名 hw ether MAC地址
[yeger@yeger ~]$ ifconfig wlan0 hw ether 00:11:22:33:44:55

SIOCSIFHWADDR: 不允许的操作
[yeger@yeger ~]$ sudo ifconfig wlan0 hw ether 00:11:22:33:44:55
SIOCSIFHWADDR: 设备或资源忙
[yeger@yeger ~]$ ifconfig wlan0 down
SIOCSIFFLAGS: 权限不够
[yeger@yeger ~]$ sudo ifconfig wlan0 down
[yeger@yeger ~]$ sudo ifconfig wlan0 hw ether 00:11:22:33:44:55
更改成功

[yeger@yeger ~]$ netstat -ant 查看端口信息 a 所有 n数字显示 t tcp协议 u udp协议
Active Internet connections (servers and established 已建立连接)
Proto Recv-Q Send-Q Local Address Foreign Address State
协议 本地地址 远程地址 连接状态
类型
tcp 0 0 0.0.0.0:57798 0.0.0.0:* LISTEN listen表示监听状态
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 :::111 :::* LISTEN
tcp 0 0 :::22 :::* LISTEN
tcp 0 0 ::1:631 :::* LISTEN

[yeger@yeger ~]$ netstat -r 查看路由表
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.21.0 * 255.255.255.0 U 0 0 0 wlan0
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
default 192.168.21.1 0.0.0.0 UG 0 0 0 wlan0

[yeger@yeger ~]$ netstat -i 查看网络接口状态
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 0 0 0 0 0 0 0 0 BMU
lo 16436 0 230 0 0 0 230 0 0 0 LRU
virbr0 1500 0 0 0 0 0 29 0 0 0 BMRU
wlan0 1500 0 10546 0 0 0 7060 0 0 0 BMRU
wmaster0 0 0 0 0 0 0 0 0 0 0 RU
[yeger@yeger ~]$
MTU字段:表示最大传输单元,即网络接口传输数据包的最大值。
Met字段:表示度量值,越小优先级越高。
RX-OK/TX-OK:分别表示接收、发送的数据包数量。
RX-ERR/TX-ERR:表示接收、发送的错误数据包数量。
RX-DRP/TX-DRP:表示丢弃的数量。
RX-OVR/TX-OVR:表示丢失数据包数量。
[yeger@yeger ~]$ nslookup www.baidu.com 测试域名解析
Server: 202.96.128.86
Address: 202.96.128.86#53

Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 119.75.218.45
Name: www.a.shifen.com
Address: 119.75.218.45