标签 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 answe ...

一个想不通的DNS解析问题

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

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)点标题旁边的 ...

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 t ...

谁负责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 ...