Cloud Native应用交付

  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
Cloud Native Application Services: cnadn.net
  1. 首页
  2. Linux
  3. 正文

redhat上装bind9.3.4

2009年04月2日 12218点热度 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

相关文章

  • openssl client authentication bundle CA 验证备忘
  • [转]Iperf 带宽性能测试使用方法与参数说明
  • [转]isic使用说明
  • tcl实例详解
  • Ubuntu配置作为DNS服务器
本作品采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可
标签: bind linux redhat 域转发
最后更新:2009年04月2日

纳米

linjing.io

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

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

页面AI聊天助手

纳米

linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
TOGAF: ID 152743
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
  • 点击查看本博技术要素列表
  • 归档
    分类
    • AI
    • Automation
    • Avi Networks
    • Cisco ACI
    • CISCO资源
    • F5 with ELK
    • F5-Tech tips
    • F5技术
    • Juniper
    • Linux
    • NGINX
    • SDN
    • ServiceMesh
    • WEB编程
    • WINDOWS相关
    • 业界文章
    • 交换机技术
    • 化云为雨/Openstack
    • 协议原理
    • 容器/k8s
    • 我的工作
    • 我的生活
    • 网站技术
    • 路由器技术
    • 项目案例
    标签聚合
    k8s network irule gtm istio envoy docker DNS api flannel neutron bigip openstack F5 nginx
    最近评论
    汤姆 发布于 8 个月前(09月10日) 嗨,楼主,里面的json怎么下载啊,怎么收费啊?
    汤姆 发布于 8 个月前(09月09日) 大佬,kib的页面可以分享下吗?谢谢
    zhangsha 发布于 1 年前(05月12日) 资料发给我下,谢谢纳米同志!!!!lyx895@qq.com
    李成才 发布于 1 年前(01月02日) 麻烦了,谢谢大佬
    纳米 发布于 1 年前(01月02日) 你好。是的,因为以前下载系统插件在一次升级后将所有的下载生成信息全弄丢了。所以不少文件无法下载。DN...
    浏览次数
    • Downloads - 183,766 views
    • 联系我 - 118,966 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 116,509 views
    • Github - 103,659 views
    • F5常见log日志解释 - 79,774 views
    • 从传统ADC迈向CLOUD NATIVE ADC - 下载 - 74,623 views
    • Sniffer Pro 4 70 530抓包软件 中文版+视频教程 - 74,320 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 67,770 views
    • 关于本站 - 60,907 views
    • 这篇文档您是否感兴趣 - 55,495 views
    链接表
    • F5SE创新
    • Jimmy Song‘s Blog
    • SDNlab
    • Service Mesh社区
    • 三斗室
    • 个人profile
    • 云原生社区

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

    Theme Kratos Made By Seaton Jiang

    京ICP备14048088号-1

    京公网安备 11010502041506号