我正在尝试设置 BIND,以便它捕获对它的所有请求,并将它们指向一组特定的 NS 服务器和特定的 A 记录。
我有大约 500 个域名,并且以每天 10-15 个的速度添加新域名,因此我不想为每个域名明确添加一个区域。
我当前的设置是:在我的named.conf中,我有一个名为external的视图,其中包含以下区域:
zone "." {
type master;
file "ext.zone";
};
这符合所有请求。
ext.zone 是:
$TTL 3600 @IN SOA.root.nsdomain.com.( 1;串行 3600;刷新 300 ;重试 3600;到期 300 );负缓存 TTL 在 NS ns1.example.com 在 NS ns2.example.com ns1 在 192.0.2.4 中 ns2 在 192.0.2.5 *. 在 192.0.2.6 中
因此,目标是:对于所有 NS 请求,返回ns1.example.com
并且ns2.example.com
对于所有 A 请求,除了ns1.example.com
或ns2.example.com
,返回192.0.2.6
。对于ns1.example.com
返回192.0.2.4
,对于ns2.example.com
返回192.0.2.5
。
这几乎有效,唯一的问题是,当我进行挖掘时,我得到:
dig @localhost somedomain.example ; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 > @localhost somedomain.example ;(找到 1 个服务器) ;; 全局选项:printcmd ;; 得到答案: ;; 操作码:QUERY,状态:NOERROR,id:37733 ;; 标志:qr aa rd;查询:1,答案:1,权限:2,附加:2 ;; 问题部分: ;somedomain.example. 在 ;; 答案部分: somedomain.example.3600 IN A 192.0.2.6 //如预期 ;; 权威部分: . 3600 IN NS ns1.example.com。// 预期,但我不知道开头的“。”是否不好。 . 3600 IN NS ns2.example.com。//见上文。 ;; 附加部分: ns1.example.com. 3600 IN A 192.0.2.6 // 不是预期的,应该是 192.0.2.4 ns2.example.com. 3600 IN A 192.0.2.6 // 不是预期的,应该是 192.0.2.5
我该如何解决这个问题?我是不是做了什么可怕的事情?有没有更好的方法?
答案1
您的区域原点取决于您的配置。您正在为和而不是 和.
创建记录,因为 和 未定义,因此它们通过通配符匹配。ns1.
ns2.
ns1.example.com.
ns2.example.com.
ns1.example.com
ns2.example.com
编辑:这是您的配置和区域的编辑:
zone "example.com." {
type master;
file "ext.zone";
};
扩展区域:
$TTL 3600
@ IN SOA ns1 root (
1 ; Serial
3600 ; Refresh
300 ; Retry
3600 ; Expire
300 ) ; Negative Cache TTL
IN NS ns1
IN NS ns2
IN A 192.0.2.6
ns1 IN A 192.0.2.4
ns2 IN A 192.0.2.5
* IN A 192.0.2.6
区域中的所有内容都与命名配置中的区域名称相关,因此添加第二个区域只指向同一个文件:
zone "example.net." {
type master;
file "ext.zone";
};
答案2
要设置子域通配符,bind
您应该使用以下格式:
name.tld. IN A IP # main domain ip
*.name.tld. IN A IP # wildcard subdomains ip
例子:
mydomain.com. IN A 1.1.1.1
*.mydomain.com. IN A 1.1.1.1
答案3
根据您的配置ns1.example.com
是192.0.2.4
和ns2.example.com
是192.0.2.5
。您必须在example.com
区域中配置 NS 服务器名称解析以获取正确的 IP。
希望我说清楚了。如果您需要更多信息,请回复我。
答案4
DNS 通配符可能会带来麻烦!
所以我不想为每个域明确添加一个区域。
有很多方法可以实现 — — 从 SHELL 脚本到基于 SQL 的 DNS 服务器。
更新(2019-11): 正如我所说8 年前,SHELL 脚本是一种可行的方法,并且已经通过接受的答案提出的解决方案“添加区域条目”得到了证明 — 显然不是基于通配符的使用。;-)
在 2019 年,更容易找到解释 DNS 通配符缺点的资源,尽管其中大多数都是在“互联网诞生之初”编写的,但它们仍然具有一定的价值。例如,RFC1912 提到了一些与 DNS 通配符使用相关的内容。主要问题清楚地解释为“…”
通配符 MX 可能很糟糕,因为它们使一些应该失败的操作成功。 “…”
尽管它也有一些现实生活中的、有点过时的例子。