标签: bind

由于 OpenDNS 现在需要一个在 pro 包中才能打开过滤功能，预算紧张，我们需要免费的 DNS 过滤。

阅读有关如何使用 bind 阻止域的链接后，我将 SquidGuard 黑名单和我需要的类别中的连接域收集到一个大列表中。然后我将它输入到这个 python 脚本中，生成一个包含大约 200 万个区域的文件。

named-checkconf 可以很好地解析它，但是重新加载 named 需要将近 10 分钟，然后它不会解决任何问题，并且服务器会减慢速度以进行爬行。删除包含导致命名再次正常工作。

将 BIND9 设置为有效地用作 DNS 防火墙的正确方法是什么？如果还可以阻止任何解析为可以解决整个问题的特定 IP 地址的域。

我以非权威身份运行绑定，只是一个缓存服务器。

在尝试仅解析某些域时，我们公司的 DNS 服务器遇到了问题，我们在 CentOS 6.5 服务器上运行 BIND 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6。我们对某些区域具有自治权，我们的内部客户端和邮件系统使用此服务器进行解析。我们无法解析的域之一是 www.dhl.com，这是我们在使用 dig 查询时得到的结果：

[root@serverx etc] dig www.dhl.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> www.dhl.com
;; global options: +cmd
;; connection timed out; no servers could be reached

和

[root@serverx etc]# dig +trace www.dhl.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +trace www.dhl.com
;; global options: +cmd
.           517419  IN  NS  g.root-servers.net.
.           517419  IN  NS  a.root-servers.net.
.           517419  IN  NS  h.root-servers.net.
.           517419  IN  NS  m.root-servers.net.
.           517419  IN  NS  f.root-servers.net.
.           517419  IN  NS …

我使用 BIND 为大约 15,000 个域名操作一些 DNS 服务器。一些客户希望开始使用全站点内容交付 CDN，对此的要求是支持使用 ANAME / ALIAS DNS 记录，现在几家大型 DNS 提供商都支持这些记录。

有没有办法在 BIND 之上实现这些记录类型，或者您能否就如何引入此类功能提出建议？

我们的办公网络在内部是双栈的，但与 Internet 其余部分的连接仅支持 IPv4。我在 Linux 机器上设置了 BIND 9.9 来处理 DNS 解析。

有没有办法在不禁用 IPv6 的情况下将 BIND 配置为在联系其他 DNS 服务器时更喜欢使用 IPv4？我想启用 IPv6，以便在我们与外界建立 IPv6 连接后一切正常，但同时不会用error (network unreachable) resolving 'microsoft.com/DS/IN': 2001:7fd::1#53消息堵塞日志。

我的目标是在不首先查找它们的地址的情况下阻止绑定中的某些域（这是一个小型缓存绑定 dns 服务器）。

目前，我的配置将转发对 badhost.com 的请求并获取 IP 地址（我可以在 wireshark 中看到这一点），然后它将用 NXDOMAIN 覆盖该响应。

绑定日志：

client 192.168.1.1#46107 (badhost.com): rpz QNAME NXDOMAIN rewrite badhost.com via badhost.com.rpz

但是获取 IP 地址毫无意义，它会延迟查询。我只是想让它快速返回被阻止域的 NXDOMAIN，而不进行转发。

配置：

options {
  response-policy { zone "rpz" policy nxdomain; };
  cleaning-interval 360;
  forward only;
  forwarders { x.x.x.x; y.y.y.y; };
  allow-recursion { any; };
  allow-query { any; };
  allow-query-cache { any; };

}

zone "rpz" {
  type master;
  file "/etc/bind/rpz.zone";
};
zone "0.0.127.in-addr.arpa" {
        type master;
    notify no;
        file "pz/127.0.0";
};
zone "1.168.192.in-addr.arpa" { …

cat /etc/bind/named.conf.options

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.

我没有找到任何有关名称服务器和我之间的防火墙应用的确切防火墙规则的信息。

So I'm kinda a newbie and I'm following this to connect a domain to my server. here is my codes:

named.conf.options:

acl "trusted" {
        124.243.241.164;
        124.243.241.164;
        124.243.241.164;
        124.243.241.164;
};


options {
    directory "/var/cache/bind";

    recursion yes;                 
    allow-recursion { trusted; };  
    listen-on { 124.243.241.164; };  
    allow-transfer { none; };      

    forwarders {
            8.8.8.8;
            8.8.4.4;
    };


    dnssec-validation auto;

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
};

named.conf.local:

zone "ns1.raze.one" {
        type master;
        file "/etc/bind/zones/db.ns1.raze.one";
        allow-transfer { 124.243.241.164; };
 };
zone "243.124.in-addr.arpa" …

在典型的隐藏主 DNS 网络布局中，基本上有两个组件：

• 隐藏的主 DNS 服务器，可能位于 NAT 或防火墙后面，或者完全暴露
• 从属权威非递归 DNS 服务器

从属 DNS 服务器上的区域文件通常没有（也不应该）向这个隐藏的主 DNS 服务器提供信息。但是，这些相同的从DNS服务器确实需要使用像某些DNS选项server，allow-update，allow-transfer，和一些访问控制列表。

起初，那些需要server并且allow-update似乎需要 IP 地址匹配列表。这将named.conf作为此类隐身信息的主要来源（即隐藏主控的 IP 地址）。

是否可以通过使用密钥而不使用named.conf文件中的任何 IP 地址来进一步限制将 IP 地址暴露给隐藏的主 DNS 服务器？

我正在寻找的关键答案是我们是否可以最大限度地减少隐藏主服务器在其配置文件级别以及区域数据库中的暴露。

我在两台服务器（CentOS 6 和 7）上运行了绑定 9.9.5，用于缓存和转发邮件服务器的 DNS 查询。服务器可以正常运行数周，然后突然以 SERVFAIL 响应所有查询。第一次发生时，两台服务器在同一天开始出现故障。现在，一周后，它再次发生，但只发生在一台服务器上。重新启动named会使问题消失。

这是/etc/named.conf（此处包含不相关部分的完整文件）的重要部分：

acl "trusted" {
    localhost;
    localnets;
    10.128.0.0/9;
};
options {
    listen-on port 53 { 127.0.0.1; 10.128.0.0/9; };
    listen-on-v6 port 53 { ::1; };
    directory               "/var/named";
    dump-file               "/var/named/data/cache_dump.db";
    statistics-file         "/var/named/data/named_stats.txt";
    memstatistics-file      "/var/named/data/named_mem_stats.txt";
    bindkeys-file           "/etc/named.iscdlv.key";
    managed-keys-directory  "/var/named/dynamic";
    auth-nxdomain no;
    version "asdf";

    dnssec-enable       yes;
    dnssec-validation   yes;
    dnssec-lookaside    auto;

    recursion yes;
    forward only;
    forwarders { 169.254.169.254; };

    allow-query     { trusted; };
    allow-recursion { trusted; };
};

当服务器处于失败状态时，一个 dig 查询响应： …

BIND 9.16 引入了一项新dnssec-policy功能，作为长期建立的功能的进一步自动化的 DNSSEC 密钥管理和签名工具auto-dnssec maintain。

该文档似乎没有涵盖从旧版本到新版本的迁移，但相关的 wiki 页面似乎表明dnssec-policy.

也就是说，建立一个新区域dnssec-policy非常简单，但是将现有区域从 迁移auto-dnssec maintain到dnssec-policy似乎并不像人们预期的那样有效。
我所期望的是与现有密钥兼容的策略将继续使用这些密钥。

似乎发生的情况是，所有现有密钥都会立即从区域中删除，因为它们已经“过期”并被新密钥替换，即使新策略强制要求一组兼容的密钥（相同的算法和大小）并且现有密钥已未定义生命周期终止属性（仅Created、Publish和Activate.key 文件中的计时）。

我在测试时使用的策略如下所示（命名以反映测试期间的内容）：

dnssec-policy alg13-ksk-unlimited-zsk-60day {
     keys {
         ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
         zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
     };
};

这是配置从 更改为 时的日志auto-dnssec maintain;输出dnssec-policy alg13-ksk-unlimited-zsk-60day;：

zone zone.example/IN (signed): reconfiguring zone keys
keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for policy alg13-ksk-unlimited-zsk-60day
keymgr: DNSKEY …