解决基于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的地址。

exsi单机加载panabit+ixcache+panalog(流控+缓存+日志)

由于工作原因,需要上流控缓存日志系统,找到了panabit,索性一台机器虚拟化哈。

闲置服务器 惠普G6 500G raid0 8G内存
购买网卡 Winyao WYI350T4 PCI-E X4服务器四口千兆网卡intel I350T4 460元

关于配置,服务器用了raid0,因为其实挂了就重新配置呗,带有实验的性质,所以无所谓了。生产环境还是推荐raid5或者raid1。网卡其实只用了3个口(服务器自带4个+网卡4个),另外几个只是备用的了。如果多条线路上的话,差不多正好够用。

网络状况
1、有电信、集团专线、教育网三个出口
2、流控为透明模式
3、缓存为牵引模式

存储状况
1、500G 服务器自带的硬盘,做了raid0阵列
2、由于缓存不够,用了openfiler做了iscsi的阵列。随便找了台垃圾机器装了两块1T的硬盘。

图1

1

具体esxi设置网络情况

1、管理端口组
设置了内网管理端口,等于三个虚拟化的系统,合并在一个物理端口上,连入内网,作为管理。
其中win2003为调试测试用。management network为esxi内网管理地址。
同时缓存是管理口,也为下载口。

图2

2

2、流量上行口接外网
流控透明模式的上行出口,接公网的口。
在公网上挂了win2003测试机,设置了esxi的公网访问口。

图3

3

3、流量下行口接内网
此物理接口接内网.

图4

4

4、电信、教育、集团专线三个出口
由于用的透明模式,没有改造原有网络,所以这里仅仅是预留,随时可以做nat转换,切换成出口。

图5

5

5、流控与缓存通信段
详细情况可以查询一下缓存的牵引模式。其实就是流控和缓存对接的口。

图6

6

6、为接入的openfiler做的单独的存储。
存储的IP为192.168.120.120
esxi相应的为192.168.120.119
实际上就是服务器和存储直接连一根网线,插在vmnic7的物理口上。

图7

7

panabit流控设置

数据接口设置
em1与em2为流量上行和下行接口
其余备用,电信、教育网、集团专线还没有设置成接外网,可以用的时候在调整。

图8

8

流控与缓存的接口设置,模拟wan,详见官方牵引模式文档。

图9

9

策略路由设置

图10

10

缓存牵引设置

图11

11

ixcache缓存设置

图12

12

简单搞了一下,熟悉了esxi的网络配置,这点还是实践出真知。
重要注意的一点,一定要在esxi里面设置虚拟交换机的网卡监听模式为混杂模式。不然的话目的地址不是该IP的包是会被丢弃,也就是说,网络怎么弄都是不通的。

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

IP地址已经分配给另一个适配器的解决办法汇总

IP地址已经分配给另一个适配器的解决办法汇总

“您为这个网络适配器输入的IP地址xxx.xxx.xxx.xx已经分配给另一个适配器….”

问题现象:
在网卡的TCP/IP属性中无法添加固定IP地址。
启动WinXP,通过“网上邻居”查看网络连接情况,发现“本地连接”已经正常启用,右键点击“本地连接”选择“属性”,在TCP/IP中添加ISP分配的固定IP及相关数据,当点击“确定”时却出现提示
“您为这个网络适配器输入的IP地址X.X.X.X 已经分配给另一个适配器‘Realtek RTL8139 Family PCI Fast Ethernet NIC’。‘Realtek RTL8139 Family PCI Fast Ethernet NIC’从网络文件夹中隐藏,因为它本身并没有在计算机中存在,或是个不工作的旧适配器。如果相同的地址分配给两个适配器,并且它们都处于活动状态,只有一个会使用这个地址。这会造成不正确的系统配置。你想从高级对话框的IP地址列表输入不同的IP地址给这个适配器吗”,
无论点击“是”或“否”都不能设置成ISP分配给它的固定IP,从而无法通过新网卡连接到Internet。从系统提示来看,“Realtek RTL8139 Family PCI Fast Ethernet NIC”应该是原来机器安装的网卡,固定IP已经和这块网卡捆绑在了一起,而这块网卡已经被替换成了新网卡,却没有释放与之捆绑的IP地址,造成新旧网卡的IP地址冲突。
解决方法一:
1.开始→执行→cmd
2.set devmgr_show_nonpresent_devices=1
3.输入: start devmgmt.msc
4.点选「查看」→「显示隐藏设备」
5.展开“网络适配器”.卸掉半透明的隐藏设备

已不存在的硬件图标将以半透明的方式显示,然后卸载该硬件就可以删除掉其配置信息了。通过此方法,可以解决移除网卡后然后不能设置相同IP地址的问题 (“您为这个网络适配器输入的IP地址 X.X.X.X 已经分配给另一个适配器。它从网络连接文件夹中隐藏,因为它本身并没有在计算机中存在,或是个不工作的旧适配器……”)。

解决方法二:
删除那个错误的注册表MAC设置 
Windows 2000/XP/2003中的修改:同样打开注册表编辑器regedit.exe,HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\
把Class下面所有配置错误的设置都删除,当然不知道就看硬件里面自己的网卡型号,里面有并口和其它端口,不要删错了,让你的串口和并口也用不了了哟!

1,定位到注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI
2,寻找出错信息中提到的网卡名称(注意必须确保完全相同)
3,备份网卡所属的注册表,删除其在PCI下的相关键值
4,重启计算机,测试更改IP是否成功
如果您的实际网卡和出错信息中提到的网卡名一样,您可能会误删除正常的网卡,这时需要恢复注册表来逆转操作。如果您在注册表中删除那个键值的时候,提示“无法删除”或者“删除项时出错”,那么请参考下面的步骤排查这一问题:
1,运行devmgmt.msc命令
2,点击查看->显示隐藏的设备
3,在网络适配器下找到故障设备,尝试停用设备然后再删除注册表键值
您也可以尝试手动卸载这一设备。
如果仍然无法成功,请在安全模式内测试一下。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
下面每一个文件夹就是一个网卡,找到重复IP的那两个网卡,查处哪一个是真正要用的。
我的方法是改一下现有存在的网卡的子网掩码,再看注册,已经改变的那个就是你真正要用的。
把另一个不存在的网卡地址随便给一个别的,不冲突就行。 现在你就可以随便给这个真正存在网卡配IP 了。

解决:您为这个网络适配器输入的IP地址 已经分配给另一个适配器
有时候更新了网卡驱动,或是删掉本地连接重新获取了驱动生成了“本地连接”会出现不能将原来的ip地址再设置为本地连接的ip地址的问题。
具体表现及解决方法如下:
您为这个网络适配器输入的IP地址xxx.xxx.xxx.xx已经分配给另一个适配器‘xxx NIC’,‘xxx NIC‘从网络和拨号连接文件夹中隐藏,因为它本身并没有在计算机中存在,或是个不工作的旧适配器。如果相同的地址分配给两个适器,并且它们都处于活动状态,只有一个会使用这个地址。这会造成不正确的系统配置。
您想从高级对话框的IP地址列表输入不同的IP地址给这个适配器吗?

方法1:
1.开始→执行→cmd
2.set devmgr_show_nonpresent_devices=1
3.输入: start devmgmt.msc
4.点选「查看」→「显示隐藏设备
5.展開“网络适配器”.卸掉麻烦源头吧!

方法2:
故障原因:Windows 2000/xp会认为不同PCI插槽中的网卡就是不同的网卡,而不管它们实际上是不是同一个;并且,即使网卡虽被拆掉了,但它的相关配置文件却已被Windows 系统记录到注册表中了。所以,在”故障现象”中所遇到的,就相当于是系统认为你现在计算机中安装了两张网卡,而原来一张已绑定了192.168.0.1这个IP地址,再给另一张网卡绑定此IP时自然会有出错提示!

解决方法:打开注册表,查找键值:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class],按提示的原来网卡的
信息从class中找到相应的硬件配置信息项删除即可。注意:每一项里面都有相应硬件的描述信息,删除之前请确认不要删错。
注意:如果自己不清楚网卡注册表信息,打开网卡驱动文件夹,在打开驱动文件夹XP安装目录,里面有记事本,信息都在里面,比如8139/810X网卡信息就是{4d36e972-e325-11ce-bfc1-08002be10318},然后在子目录里找到8139网卡的信息,删除即可.

方法3:
故障原因:Windows 2000/xp会认为不同PCI插槽中的网卡就是不同的网卡,而不管它们实际上是不是同一个;
并且,即使网卡虽被拆掉了,但它的相关配置文件却已被Windows 系统记录到注册表中了。
所以,在”故障现象”中所遇到的,就相当于是系统认为你现在计算机中安装了两张网卡,而原来一张已绑定了192.168.50.188这个IP地址,再给另一张网卡绑定此IP时自然会有出错提示!
解决方法:打开注册表,查找键值:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class],按提示的原来网卡的信息从class中找到相应的硬件配置信息项删除即可。注意:每一项里面都有相应硬件的描述信息,删除之前请确认不要删错。如果自己不清楚网卡注册表信息,可以打开网卡的属性对话框,根据网卡描述性文字(如是已经删除掉的网卡,可根据修改IP时,提示的对话框中的网卡名)部分文本,在class项下搜索,即可定位到所在网卡配置文件。如果先后使用的网卡厂家、型号均一样,唯一不一样的是各自项的”NetCfgInstanceId”值。
如此情况可通过修改当前网卡的速率或但双工模式,之后在注册表项下刷新,对应的注册表项变化则为当前网卡。比如,先后的网卡都是Realtek的8139D网卡,通过搜索Realtek,有两个注册项。修改当前使用网卡的工作模式为100M全双工,观察到两个类似的网卡注册表项,有一个项下的DUPLEXMODE的值由之前的1改变为5,初步确认此项为当前使用网卡;再次确认,将网卡工作模式恢复至auto自动协商,键值变更为1。此项为当前网卡,相同的另外一项就是以前的陈旧网卡信息,先导出备份,接着,删除。再次修改IP设置,没有了之前的警告窗口了。

方法4:
1.单击开始,指向所有程序、指向附件,然后单击命令提示符。
2.在命令提示符处键入以下命令,然后按 Enter 键: set devmgr_show_nonpresent_devices=1
3.在命令提示符处键入以下命令,然后按 Enter 键(其中,%SystemRoot% 是安装 Windows XP 的文件夹): cd\%SystemRoot%\system32
4.在命令提示符处键入以下命令,然后按 Enter 键: start devmgmt.msc
5.解决设备治理器中设备和驱动程序的问题。 注重:在设备治理器中单击查看菜单上的“显示隐藏的设备”才能看到未连接到计算机的设备。
6.在问题解决之后,关闭设备治理器。
7.在命令提示符处键入 exit。
请注重,关闭命令提示符窗口时,Windows 将清除在第 2 步中设置的 devmgr_show_nonpresent_devices=1 变量,并会阻止在单击“显示隐藏的设备”时显示幻像设备。
网友回复:在设备治理器里钩选“显示隐藏的设备”后看到“网络适配器”中有个灰度显示的旧网卡设备,把它卸载后重启系统,现在本地连接等都恢复正常了

如果上面的方法都不行,可以试一下如下的方法。
——————————–
1.打开注册表(开始/运行,输入regedit);
2.搜索注册表中所有关于“Microsoft TV”的值,并删除;
3.重新启动;
4.手动添加IP地址(原先无法修改IP地址的本地连接现在可以了);
5.添加DNS服务器地址。
6.网络连接成功。

工作组与域

工作组 WorkGroup
  
在一个网络内,可能有成百上千台电脑,如果这些电脑不进行分组,都列在“网上邻居”内,可想而知会有多么乱。为了解决这一问题,Windows9x以上的操作系统引用了“工作组”这个概念,将不同的电脑一般按功能分别列入不同的组中,如财务部的电脑都列入“财务部”工作组中,人事部的电脑都列入“人事部”工作组中。你要访问某个部门的资源,就在“网上邻居”里找到那个部门的工作组名,双击就可以看到那个部门的电脑了。
  
系统默认的工作组名称为WorkGroup,如果你重新创建的工作组,那么就对WorkGroup名称进行修改。计算机名和工作组的长度不能超过15个英文字符,可以输入汉字,但是不能超过7个。“计算机说明”是附加信息,不填也可以,但是最好填上一些这台电脑主人的信息,如“技术部主管”等。单击[确定]按钮后,Windows98提示需要重新启动,按要求重新启动之后,再进入“网上邻居”,就可以看到你所在工作组的成员了。
  
一般来说,同一个工作组内部成员相互交换信息的频率最高,所以你一进入“网上邻居”,首先看到的是你所在工作组的成员。如果要访问其他工作组的成员,需要双击“整个网络”,就会看到网络上所有的工作组,双击工作组名称,就会看到里面的成员。
  
你也可以退出某个工作组,只要将工作组名称改动即可。不过这样在网上别人照样可以访问你的共享资源,只不过换了一个工作组而已。你可以随便加入同一网络上的任何工作组,也可以离开一个工作组。“工作组”就像一个自由加入和退出的俱乐部一样,它本身的作用仅仅是提供一个“房间”,以方便网上计算机共享资源的浏览。
  
域 Domain
  
与工作组的“松散会员制”有所不同,“域”是一个相对严格的组织。“域”指的是服务器控制网络上的计算机能否加入的计算机组合。
  
实行严格的管理对网络安全是非常必要的。在对等网模式下,任何一台电脑只要接入网络,就可以访问共享资源,如共享ISDN上网等。尽管对等网络上的共享文件可以加访问密码,但是非常容易被破解。在由Windows9x构成的对等网中,数据是非常不安全的。
  
在“域”模式下,至少有一台服务器负责每一台联入网络的电脑和用户的验证工作,相当于一个单位的门卫一样,称为“域控制器(DomainController,简写为DC)”。“域控制器”中包含了由这个域的账户、密码、属于这个域的计算机等信息构成的数据库。当电脑联入网络时,域控制器首先要鉴别这台电脑是否是属于这个域的,用户使用的登录账号是否存在、密码是否正确。如果以上信息不正确,域控制器就拒绝这个用户从这台电脑登录。不能登录,用户就不能访问服务器上有权限保护的资源,只能以对等网用户的方式访问Windows共享出来的资源,这样就一定程度上保护了网络上的资源。
 
想把一台电脑加入域,仅仅使它和服务器在“网上邻居”能够相互看到是远远不够的,必须要由网络管理员进行把这台电脑加入域的相关操作。操作过程由服务器端设置和客户端设置构成。
  
1、服务器端设置
  
以系统管理员身份在已经设置好ActiveDirectory(活动目录)的Windows 2000Server上登录,点击“开始/程序/管理工具/ActiveDirectory用户和计算机”,在程序界面中右击“computers”(计算机),在弹出的菜单中单击“新建/计算机”,填入想要加入域的计算机名即可。要加入域的计算机名最好为英文,否则系统会提示中文计算机名可能会引起一些问题。
  
2、客户端设置
  
第一步:登录到系统桌面,鼠标右键点“我的电脑->属性->网络标识”。
第二步:点“属性”按钮,在弹出的窗口中隶属于处从“工作组”选择到“域”。
第三步:在“域”文本处输入你希望加入的域的名称。确定后系统要求你输入域管理员帐号和密码,输入正确后当前计算机就成功加入到域中。

小提示:有的计算机通过上面介绍的方法会显示域DNS错误,遇到这种情况我们只需要在“网络标识”标签点“网络ID”按钮即可,通过配置新的网络ID完成加入域的操作。另外千万要记住加入域时需要输入的是域管理员帐号和密码,普通管理员是不能完成该操作的。

总结:采用域的方式管理资源配置起来相对麻烦,需要专门人员进行管理维护。不过这种资源管理模式在安全性方面得到了大大的提高。这一点是工作组模式远远不及的。一些大型公司网络中多采用这种形式,在共享资源的同时,最大限度的防止隐私的泄露。

TTL值的含义以及域名TTL值的区别

什么是TTL?
TTL是IP协议包中的一个值,指定数据报被路由器丢弃之前允许通过的网段数量。
在很多情况下数据包在一定时间内不能被传递到目的地。解决方法就是在一段时间后丢弃这个包,然后给发送者一个报文,由发送者决定是否要重发。TTL 是由发送主机设置的,以防止数据包不断在 IP 互联网络上永不终止地循环。转发 IP 数据包时,要求路由器至少将 TTL 减小1。当记数到0时,路由器决定丢弃该包,并发送一个ICMP报文给最初的发送者。

TTL值帮助我们大致的识别主机的操作系统类型。
UNIX 及类 UNIX 操作系统 ICMP 回显应答的 TTL 字段值为 255
Compaq Tru64 5.0 ICMP 回显应答的 TTL 字段值为 64
微软 Windows NT/2K操作系统 ICMP 回显应答的 TTL 字段值为 128
微软 Windows 95 操作系统 ICMP 回显应答的 TTL 字段值为 32

特殊情况:
LINUX Kernel 2.2.x & 2.4.x ICMP 回显应答的 TTL 字段值为 64
FreeBSD 4.1, 4.0, 3.4;
Sun Solaris 2.5.1, 2.6, 2.7, 2.8;
OpenBSD 2.6, 2.7,
NetBSD
HP UX 10.20
ICMP 回显应答的 TTL 字段值为 255
Windows 95/98/98SE
Windows ME
ICMP 回显应答的 TTL 字段值为 32
Windows NT4 WRKS
Windows NT4 Server
Windows 2000
Windows XP
ICMP 回显应答的 TTL 字段值为 128

什么是域名的TTL值?
TTL(Time- To-Live),简单的说它表示一条域名解析记录在dns服务器上缓存时间.当各地的dns服务器接受到解析请求时,就会向域名指定的DNS服务器发出解析请求从而获得解析记录;在获得这个记录之后,记录会在DNS服务器中保存一段时间,这段时间内如果再接到这个域名的解析请求,DNS服务器将不再向DNS服务器发出请求,而是直接返回刚才获得的记录;而这个记录在DNS服务器上保留的时间,就是TTL值。

合理设置域名TTL值:
一.增大TTL值,以节约域名解析时间。
通常情况下域名解析记录是很少更改的。我们可以通过增大域名记录的TTL值让记录在各地DNS服务器中缓存的时间加长,这样在更长的时间段内,我们访问这个网站时,本地ISP的DNS服务器就不需要向域名的NS服务器发出解析请求,而直接从本地缓存中返回域名解析记录。
TTL值是以秒为单位的,通常的默认值都是3600,也就是默认缓存1小时。我们可以根据实际需要把TTL值扩大,例如要缓存一天就设置成86400。

二.减小TTL值,减少更换空间时的不可访问时间。
更换域名空间时会对DNS记录进行修改,因为DNS记录缓存的问题,新的域名记录在有的地方可能生效了,但在有的地方可能等上一两天甚至更久才生效,只就导致有部分用户在一段时间内无法不可访问网站了。

那么TTL值到底应该设置成多大呢?
首先向大家介绍一下TTL值设置大一点和设置小一点的区别:较大的TTL值可以减少域名解析时间,加快网站访问速度。较小的TTL值,可以减少在更换空间修改域名解析后,网站不可访问的时间。
所以对于TTL值设置的建议为:网站刚建立的时候设置为半小时或一小时,方便调试及更换空间。等到稳定以后,TTL设置为一天(baidu,google等域名TTL都设置为一天)。

在实际使用中,关于TTL值的经验分享
首先,本人并没有发现TTL=1小时与TTL=1天,网站访问速度有明显区别。
其次,每次修改域名解析A记录后,虽然TTL设置的为1小时或者1天,但一般3-5分钟后域名解析修改就生效了。这种情况的原因可能是,本人所在的本地ISP的DNS服务器并没有完全遵守标准规范。

为了尽可能的减小这个各地的解析时间差,合理的做法是:
1.先查看域名当前的TTL值。
2.修改TTL值为可设定的最小值,建议为60秒。
3.等待一天,保证各地的DNS服务器缓存都过期并更新了记录。
4.设置修改DNS解析到新的记录,这个时候各地的DNS就能以最快的速度更新到新的记录。
5.确认各地的DNS已经更新完成后,再TTL值设置成常用的值(如: TTL=86400)。TTL=60还是太小了点。
这一切都能起作用的前提,是那些DNS服务器完全遵守这些标准和规范,否则NS服务器上怎么设置TTL都是白搭,但目前来看还没发现这么不讲规矩的DNS服务器。