Cloud Native应用交付
  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
☁️We are in new App Mesh era: imesh.club ☁️
  1. 首页
  2. Linux
  3. 正文

redhat上装bind9.3.4

2009年04月02日 4754点热度 0人点赞 0条评论

装好后,
因为是带指定目录启动的named:
pr 2 23:06:16 RedHat named[3316]: starting BIND 9.2.4 -u named -t /var/named/chroot
Apr 2 23:06:16 RedHat named[3316]: using 1 CPU
Apr 2 23:06:16 RedHat named: named 启动 succeeded
所以BIND认为实际zone文件所在目录是:
/var/named/chroot/var/named
named.conf中指定的工作目录/var/named下的那些zone文件都是个连接
---------------------------------------------------------------------
必须在options中开启递归,针对某个具体域的forward才能生效,否则不会生效。

[root@RedHat named]# cat /etc/named.conf
//
// named.conf for Red Hat caching-nameserver
//

//logging {
//channel query_log {
//file "query.log" versions 3 size 20m;
//severity info;
//print-time yes;
//print-category yes;
//};
//category queries {
//query_log;
//};
//};

options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
recursion yes;

/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};

//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

zone "." IN {
type hint;
file "named.ca";
};

zone "localdomain" IN {
type master;
file "localdomain.zone";
allow-update { none; };
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.ip6.local";
allow-update { none; };
};

zone "255.in-addr.arpa" IN {
type master;
file "named.broadcast";
allow-update { none; };
};

zone "0.in-addr.arpa" IN {
type master;
file "named.zero";
allow-update { none; };
};

zone "mybind.com." {
type master;
file "named.mybind";
allow-update {
localhost;
};
};

zone "sina.com." {
type forward;
forward only;
forwarders {
202.106.83.125;
//icbc's name server
};
};

zone "icbc.com.cn." {
type forward;
forward only;
forwarders {
202.106.83.125;
};
};

zone "163.com." {
type forward;
forward first;
forwarders {
202.106.83.125;
};
};

上面的配置,将sina.com,163.com,icbc.com.cn都转发到icbc的某台DNS服务器上。注意forward类型。并且ICBC的DNS是不接受解析别的域名的,因此结果如下
163.com的可以被解析(先转发,然后ICBC的DNS拒绝,转发失败后改用递归查询)
------------
Non-authoritative answer:
Name: www.cache.gslb.netease.com
Addresses: 61.135.253.11, 61.135.253.12, 61.135.253.13, 61.135.253.14
61.135.253.15, 61.135.253.16, 61.135.253.17, 61.135.253.18, 61.135.25
.9
61.135.253.10
Aliases: www.163.com

sina.com的不能被解析,因为是forward only 只容许转发,而ICBC又拒绝解析。

------------
*** [192.168.1.108] can't find sina.com: Server failed

icbc.com.cn可以被解析(转发到icbc.com.cn后,icbc的DNS服务器接受解析)
Non-authoritative answer:
Name: www.icbc.com.cn
Address: 202.99.30.209
---------------------------------------------------------------------------

但是全局打开递归对一个企业来说可能并不需要,因为如果作为纯内部使用,打开递归会导致用户可以借该DNS来解析任意域名,因此如果只想针对某些指定域进行递归查询的话可以编辑root.hint文件,将根服务器地址改为指定域所在的DNS,这样可以防止向公众根服务器递归而导致可解析所有域名。 但是这个方法有个缺陷,如果有多个指定域的话,如果都编辑在root.hint里,将导致排在后面的指定域进行递归时候要先用排在前面的其他指定域的DNS,导致经常超时。事实上还有一个问题,就是如果合作伙伴的域再次递归的话,则也将导致内网用户可解析所有域名。
编辑root.hint文件为
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 202.106.83.125

. 3600000 IN NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 202.106.0.20

第一个IP是指定合作伙伴的,第二个是公网一个ISP的DNS。如果解析非指定合作伙伴的域名时,抓包发现总是第一次递归给202.106.83.125,由于合作伙伴不提供再次递归,所以DNS服务器再去找202.106.0.20:
23:47:33.460272 IP 192.168.0.185.1440 > 192.168.0.150.domain: 49+ A? www.qq.com. (28)
23:47:33.464865 IP 192.168.0.150.32774 > 202.106.83.125.domain: 33868% [1au] A? www.qq.com. (39)
23:47:33.466601 IP 192.168.0.150.32774 > 202.106.83.125.domain: 57694% [1au] NS? . (28)
23:47:33.483152 IP 202.106.83.125.domain > 192.168.0.150.32774: 33868 ServFail 0/0/1 (39)
23:47:33.483905 IP 202.106.83.125.domain > 192.168.0.150.32774: 57694 ServFail 0/0/1 (28)
23:47:33.486618 IP 192.168.0.150.32774 > 202.106.83.125.domain: 61615 A? www.qq.com. (28)
23:47:33.487605 IP 192.168.0.150.32774 > 202.106.83.125.domain: 34356 NS? . (17)
23:47:33.503710 IP 202.106.83.125.domain > 192.168.0.150.32774: 61615 ServFail 0/0/0 (28)
23:47:33.506388 IP 202.106.83.125.domain > 192.168.0.150.32774: 34356 ServFail 0/0/0 (17)
23:47:33.507565 IP 192.168.0.150.32774 > 202.106.0.20.domain: 49946% [1au] A? www.qq.com. (39)
23:47:33.508686 IP 192.168.0.150.32774 > 202.106.0.20.domain: 24973% [1au] NS? . (28)
23:47:33.525263 IP 202.106.0.20.domain > 192.168.0.150.32774: 24973 13/0/1 NS D.ROOT-SERVERS.NET.,[|domain]
23:47:33.530761 IP 202.106.0.20.domain > 192.168.0.150.32774: 49946 1/0/1 A 61.135.167.36 (55)
23:47:33.536598 IP 192.168.0.150.domain > 192.168.0.185.1440: 49 1/13/0 A 61.135.167.36 (255)

同时还发现,在解析过一些域名后(解析这些域名过程中我的DNS服务器从外部的ISP那个DNS上获得了一些根域名服务器的IP)我的DNS服务器把一些根域名服务器缓存了,导致后面解析其他IP可以很快的解析出来,而不像上面那样先递归找合作伙伴的DNS再递归找ISP的DNS,而是直接用了某个根服务器,这不是期望的效果,这或许可以通过关闭DNS服务器缓存功能避免~~~~w
==========================
解决办法:把root.hint里换成假的IP 欺骗BIND,这样各个单独转发域的就可以各自生效了。又不会导致用户可以随意解析IP。
01:07:03.523974 IP 192.168.0.185.2324 > 192.168.0.150.domain: 3+ A? www.icbc.com.cn. (33)
01:07:03.530951 IP 192.168.0.150.32769 > 202.106.83.125.domain: 40500+% [1au] A? www.icbc.com.cn. (44)
01:07:03.541015 IP 202.106.83.125.domain > 192.168.0.150.32769: 40500*- 1/0/1 A 211.95.81.1 (60)
01:07:03.542802 IP 192.168.0.150.domain > 192.168.0.185

.2324: 3 1/0/0 A 211.95.8
1.1 (49)
01:07:59.086585 IP 192.168.0.185.2325 > 192.168.0.150.domain: 4+ A? www.265.com. (29)
01:07:59.099236 IP 192.168.0.150.32769 > 1.1.1.1.domain: 20250% [1au] A? www.265.com. (40)
01:07:59.101134 IP 192.168.0.150.32769 > 1.1.1.1.domain: 37865% [1au] NS? . (28)
01:08:01.103887 IP 192.168.0.150.32769 > 1.1.1.1.domain: 56245% [1au] A? www.265.com. (40)
01:08:01.105854 IP 192.168.0.150.32769 > 1.1.1.1.domain: 37435% [1au] NS? . (28)
01:08:01.107183 IP 192.168.0.150.32769 > 1.1.1.1.domain: 31579% [1au] A6? A.ROOT-SERVERS.NET. (47)
01:08:02.314876 IP 192.168.0.185.2326 > 192.168.0.150.domain: 5+ A? www.265.com. (29)
01:08:03.105171 IP 192.168.0.150.32769 > 1.1.1.1.domain: 20815% [1au] A? www.265.com. (40)
01:08:03.108436 IP 192.168.0.150.32769 > 1.1.1.1.domain: 36636% [1au] NS? . (28)
01:08:03.113258 IP 192.168.0.150.32769 > 1.1.1.1.domain: 58303% [1au] A6? A.ROOT-SERVERS.NET. (47)
01:08:05.114387 IP 192.168.0.150.32769 > 1.1.1.1.domain: 43912% [1au] A6? A.ROOT-SERVERS.NET. (47)
01:08:11.106954 IP 192.168.0.150.32769 > 1.1.1.1.domain: 21956 A? www.265.com. (29)
01:08:11.112948 IP 192.168.0.150.32769 > 1.1.1.1.domain: 5385 NS? . (17)
01:08:13.116058 IP 192.168.0.150.32769 > 1.1.1.1.domain: 31710 A6? A.ROOT-SERVERS.NET. (36)
01:08:21.547324 IP 192.168.0.185.2327 > 192.168.0.150.domain: 6+ A? www.265.com. (29)
01:08:24.770687 IP 192.168.0.185.2328 > 192.168.0.150.domain: 7+ A? www.265.com. (29)
01:08:27.110072 IP 192.168.0.150.32769 > 1.1.1.1.domain: 24280 A? www.265.com. (29)
01:08:27.115294 IP 192.168.0.150.32769 > 1.1.1.1.domain: 22523 NS? . (17)
01:08:29.097781 IP 192.168.0.150.domain > 192.168.0.185.2325: 4 ServFail 0/0/0 (29)
01:08:29.097997 IP 192.168.0.150.domain > 192.168.0.185.2326: 5 ServFail 0/0/0 (29)
01:08:29.098859 IP 192.168.0.150.domain > 192.168.0.185.2327: 6 ServFail 0/0/0 (29)
01:08:29.099620 IP 192.168.0.150.domain > 192.168.0.185.2328: 7 ServFail 0/0/0 (29)
01:08:29.117218 IP 192.168.0.150.32769 > 1.1.1.1.domain: 50711 A6? A.ROOT-SERVERS.NET. (36)
01:08:31.107363 IP 192.168.0.150.32769 > 1.1.1.1.domain: 22530% [1au] AAAA? A.ROOT-SERVERS.NET. (47)
这里还需注意一个细节:
如果指定域的某个记录解析是cname到另一个域的,解析时就还要能解析cname指示的地址,因此这种情形下还需对cname指示的域也做转发,例如网易的www.163.com是cname到netease.com域的,所以named.conf中还得加上netease.com可以转发的配置
01:25:05.677586 IP 192.168.0.185.2413 > 192.168.0.150.domain: 21+ A? www.163.com. (29)
01:25:05.688703 IP 192.168.0.150.32771 > 202.106.0.20.domain: 63878+% [1au] A? www.163.com. (40)
01:25:05.689875 IP 192.168.0.150.32771 > 1.1.1.1.domain: 64707% [1au] NS? . (28)
01:25:05.711864 IP 202.106.0.20.domain > 192.168.0.150.32771: 63878 11/0/1 CNAME[|domain]
01:25:05.717924 IP 192.168.0.150.32771 > 202.106.0.20.domain: 56538+% [1au] A? www.cache.gslb.netease.com. (55)
01:25:05.736635 IP 202.106.0.20.domain > 192.168.0.150.32771: 56538 10/0/1[|domain]
01:25:05.743277 IP 192.168.0.150.domain > 192.168.0.185.2413: 21 11/0/0 CNAME[|domain]

> www.163.com
Server: [192.168.0.150]
Address: 192.168.0.150

Non-authoritative answer:
Name: www.cache.gslb.netease.com
Addresses: 61.135.253.16, 61.135.253.17, 61.135.253.18, 61.135.253.9
61.135.253.10, 61.135.253.11, 61.135.253.12, 61.135.253.13, 61.135.253
.14
61.135.253.15
Aliases: www.163.com

对应named.conf配置
zone "163.com." {
type forward;
forward first;
forwarders {
202.106.0.20;
//public isp's dns
};
};

zone "netease.com." {
type forward;
forward first;
forwarders {
202.106.0.20;
==========================
将root.hint文件改成假IP,还是无法避免垃圾域名递归导致的流量解析(尽管该域名实际无法解析),所以可以考虑把root.hint文件置空,测试:
空root.hint可以把服务起来,此时DNS不会把递归包乱发出去了,直接报服务器失败。同时此时forward zone的类型必须是forward only,如果是forward first将导致无法转发。 下面是测试结果

Named配置

zone "icbc.com.cn." {
type forward;
forward only;

//if root.hint content is empty,forward type must be only. if is first,then resolve will fail...
forwarders {
202.106.83.125; ICBC域转发给ICBC一台实际公网DNS,类型only
};
};

zone "mycisco.cn." {
type forward;
forward first;

//if root.hint content is empty,forward type must be only. if is first,then resolve will fail...
forwarders {
202.106.0.20; 转发给网通的一个DNS,类型是first
};
};

测试结果抓包
root@RedHat ~]# tcpdump -ni eth0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

试图解析www.qq.com,这个域在DNS没有定义,应该递归
15:54:50.642968 IP 192.168.1.105.1425 > 192.168.1.107.domain: 51+ A? www.qq.com. (28)
15:54:50.646022 IP 192.168.1.107.domain > 192.168.1.105.1425: 51 ServFail 0/0/0 (28)
15:54:50.658966 IP 192.168.1.105.1426 > 192.168.1.107.domain: 52+ A? www.qq.com. (28)
15:54:50.662228 IP 192.168.1.107.domain > 192.168.1.105.1426: 52 ServFail 0/0/0 (28)

解析www.icbc.com.cn 成功,类型是only
15:55:03.718194 IP 192.168.1.105.1427 > 192.168.1.107.domain: 53+ A? www.icbc.com.cn. (33)
15:55:03.722168 IP 192.168.1.107.32774 > 202.106.83.125.domain: 43103+% [1au] A? www.icbc.com.cn. (44)
15:55:05.724416 IP 192.168.1.107.32774 > 202.106.83.125.domain: 50789+% [1au] A? www.icbc.com.cn. (44)
15:55:06.528538 IP 192.168.1.105.1428 > 192.168.1.107.domain: 54+ A? www.icbc.com.cn. (33)
15:55:07.725933 IP 192.168.1.107.32774 > 202.106.83.125.domain: 26586+% [1au] A? www.icbc.com.cn. (44)
15:55:08.920507 IP 202.106.83.125.domain > 192.168.1.107.32774: 50789*- 1/0/1 A 211.95.81.1 (60)
15:55:08.934064 IP 202.106.83.125.domain > 192.168.1.107.32774: 26586*- 1/0/1 A 211.95.81.1 (60)
15:55:08.938414 IP 192.168.1.107.domain > 192.168.1.105.1427: 53 1/0/0 A 211.95.81.1 (49)
15:55:08.941467 IP 192.168.1.107.domain > 192.168.1.105.1428: 54 1/0/0 A 211.95.81.1 (49)

解析www.mycisco.cn 失败,forward 类型是first
15:56:23.007116 IP 192.168.1.105.1430 > 192.168.1.107.domain: 55+ A? www.mycisco.cn. (32)
15:56:23.012878 IP 192.168.1.107.domain > 192.168.1.105.1430: 55 ServFail 0/0/0 (32)
15:56:23.023036 IP 192.168.1.105.1431 > 192.168.1.107.domain: 56+ A? www.mycisco.cn. (32)
15:56:23.026002 IP 192.168.1.107.domain > 192.168.1.105.1431: 56 ServFail 0/0/0 (32)

17 packets captured
17 packets received by filter
0 packets dropped by kernel

客户端对应结果:
> www.qq.com
Server: [192.168.1.107]
Address: 192.168.1.107

*** [192.168.1.107] can't find www.qq.com: Server failed
> www.icbc.com.cn
Server: [192.168.1.107]
Address: 192.168.1.107

DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: www.icbc.com.cn
Address: 211.95.81.1

> www.mycisco.cn
Server: [192.168.1.107]
Address: 192.168.1.107

*** [192.168.1.107] can't find www.mycisco.cn: Server failed

本作品采用 知识共享署名 4.0 国际许可协议 进行许可
标签: bind linux redhat 域转发
最后更新:2009年04月02日

纳米

http://linjing.io

打赏 点赞
< 上一篇
下一篇 >

文章评论

取消回复

纳米

http://linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
Kubernetes: CKA #664
Microsoft: MCSE MCDBA
Cisco: CCNP
Juniper: JNCIS
F5:
F5 Certified Solution Expert, Security
F5 Certified Technology Specialist, LTM/GTM/APM/ASM
F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 分类目录
    • Avi Networks (3)
    • Cisco ACI (1)
    • CISCO资源 (21)
    • F5 with ELK (8)
    • F5-Tech tips (38)
    • F5技术 (203)
    • Juniper (4)
    • Linux (7)
    • Nginx (18)
    • SDN (4)
    • ServiceMesh (19)
    • WEB编程 (8)
    • WINDOWS相关 (7)
    • 业界文章 (18)
    • 交换机技术 (20)
    • 化云为雨/Openstack (35)
    • 协议原理 (52)
    • 容器/k8s (64)
    • 我的工作 (19)
    • 我的生活 (70)
    • 网站技术 (19)
    • 路由器技术 (80)
    • 项目案例 (28)
    文章归档
    标签聚合
    F5 k8s openstack nginx istio DNS envoy gtm docker network flannel api irule bigip neutron cc kubernetes ELK vxlan BGP dhcp VPN IPSec lbaas ingress ingress controller nginx plus sidecar IPSec VPN NAT sql
    最新 热点 随机
    最新 热点 随机
    Say hello for 2021 二进制flannel部署,非cni网络模式下与k8s CIS结合方案 又是一年国庆 Service Account Token Volume Projection Istio ingressgateway 静态TLS证书加载与SDS发现方式配置区别 Istio里Gateway的port定义与实际ingressgateway的listener端口关系及规则 Helm 3 部署NGINX Ingress Controller 应用交付老兵眼中的Envoy, 云原生时代下的思考 Istio sidecar iptables以及流量控制分析 Istio 熔断策略及envoy配置
    Say hello for 2021
    [原创]NSSA区域下LSA4的产生与传播 Openstack L3-VXLAN网络与 F5 LBaaS 协作之 多 外部BIGIP(ICEHOUSE)及同一外部F5支持多租户测试 ip default-network和ip route 0.0.0.0 0.0.0.0区别 NAT Support for Multiple Pools Using Route Maps [原]config sync 排错指导 Point-to-Point Protocol 聊聊为啥kubernetes的dashboard搞起来这么费劲 一个网管的牢骚 NAT and Same Security Level Interfaces openstack heat模板之配置基本LB到F5 BIGIP
    链接表
    • Jimmy Song‘s Blog
    • SDNap
    • SDNlab
    • SDN论坛
    • Service Mesh社区
    • 三斗室
    • 个人profile

    COPYRIGHT © 2020 Cloud Native应用交付. ALL RIGHTS RESERVED.

    THEME KRATOS MADE BY VTROIS

    京ICP备14048088号-1

    京公网安备 11010502041506号

    [ Placeholder content for popup link ] WordPress Download Manager - Best Download Management Plugin