在 中dnsmasq，可以将域转发到不同的名称服务器。我怎样才能做到这一点named？
server=/foo.com/10.0.10.1
server=/vpn.foo.com/8.8.8.8
我正在使用本地 BIND9 服务器来托管一些本地 dns 记录。在尝试挖掘本地域名时，如果我没有明确告诉 dig 使用我的本地 BIND9 服务器，我将无法找到它。
user@heimdal:~$ dig +short heimdal.lan.se
user@heimdal:~$ dig +short @192.168.1.7 heimdal.lan.se
192.168.1.2
使用 Ubuntu 17.04 和 systemd-resolved。这是我的/etc/resolved的内容
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
以及 systemd-resolve --status 的输出
Global
DNS Servers: 192.168.1.7
192.168.1.1
DNSSEC NTA: 10.in-addr.arpa …SSHFP 记录在 ssh 服务器上生成如下，然后添加到绑定中的区域：
$ ssh-keygen -r www.test.us.
www.test.us. IN SSHFP 1 1 ad04dfaf343a93beeb939eed1612168f7eadbed7
www.test.us. IN SSHFP 2 1 432209c72c4f0e99546d601dd96c04ce804191f9
可以通过 DNS 从 ssh 客户端获取所需的记录，如下所示：
$ dig www.test.us any
;; QUESTION SECTION:
;www.test.us. IN ANY
;; ANSWER SECTION:
www.test.us. 120 IN SSHFP 1 1 AD04DFAF343A93BEEB939EED1612168F7EADBED7
www.test.us. 120 IN SSHFP 2 1 432209C72C4F0E99546D601DD96C04CE804191F9
www.test.us. 120 IN A 192.168.1.50
但是，客户端上的 ssh 在连接时无法找到它们：
$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes www
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/test/.ssh/config
debug1: …我在家里使用 BIND 作为我的 DNS 服务器。对于我的授权开始（SOA 记录），我总是使用推荐格式的序列号
YYYYMMDD##
##当天更改的柜台在哪里。
不幸的是，我更改了序列号并错误地添加了 1 个数字。更新名称守护程序后，我无法再恢复了。
有没有可能的方法来重置 BIND 内部库中的串行/计数器？
我在我的家庭网络上运行一个 bind9 dns 服务器，为我的域本地 / 192.168.xx 中的所有内部服务器提供服务 - 其中之一，extweb.local 192.168.1.33 也可以从互联网上看到为 home.sickel.net（好吧，不完全是，但你明白了）
是否可以设置我的内部 dns 以便将 home.sickel.net 解析为 192.168.1.33？sickel.net 上的所有其他主机都在外部运行，不应由我的内部 dns 解析。
（所有这些主要是为了让其他家庭成员更轻松，以便他们始终可以将服务器称为 home.sickel.net，无论他们是在家还是通过 www 访问）
我家庭网络上的所有服务器都运行 debian。它们都在同一个子网中，通过一个网关连接到互联网。
我有一个主bind9DNS 服务器和 2 个在 IPv4（Debian Jessie）上运行的从服务器，使用/etc/bind/named.conf：
listen-on-v6 { none; };
当我尝试从不同的服务器连接时，每个连接至少需要 5 秒（我使用Joseph 的时间信息进行调试）：
$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com
time_namelookup: 5.512
time_connect: 5.512
time_appconnect: 5.529
time_pretransfer: 5.529
time_redirect: 0.000
time_starttransfer: 5.531
----------
time_total: 5.531
根据curl，查找需要大部分时间，但是标准nslookup非常快：
$ time nslookup example.com > /dev/null 2>&1
real 0m0.018s
user 0m0.016s
sys 0m0.000s
强制curl使用 IPv4 后，情况变得更好：
$ curl -4 -w "@curl-format.txt" -o /dev/null -s https://example.com
time_namelookup: 0.004
time_connect: 0.005
time_appconnect: …我在我公司的服务器上设置了 DNS，它工作得很好，除了我的一些电话有问题。例如其中一部手机是“Huawei P9 lite”，它的主机名（在手机上设置，没有root就没有机会更改）是“HUAWEI_P9_lite”，这导致我的日志充斥着错误。
有没有办法处理主机名中的下划线？我知道我可以设置一个选项来忽略check-names，但我宁愿不这样做。也许我可以以某种方式为某些设备（基于 MAC 地址）强制使用主机名？
在同一台服务器上还有一个 DHCP 服务器。
是否有可能将 BIND 设置为本地网络上的 DNS 服务器，并在查找时执行脚本？
我想根据传入的 DNS 查找执行 Python 或 Bash 脚本，我该如何解决？
如果在 Bind 中可能，请告诉我如何，如果没有，请告诉我在 Ubuntu 上运行的其他 DNS 服务器实现中是否可能。
非常感谢。
我正在使用 centos6.5 和 bind9，并且通过执行以下步骤设法将记录添加到 DNS 区域：
创建密钥：
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST example.com.
编辑配置 文件：
// TSIG Key
key "example.com." {
algorithm hmac-md5;
secret "THE KEY GENERATED ABOVE";
};
zone "example.com" IN {
type master;
file "example.com.zone";
allow-update{ key "example.com."; };
};
将命名授权授予 /var/named 文件夹：
# chown -R named:named /var/named
# find . -type d -exec chmod 770 {} \;
# find . -type f -exec chmod 660 {} \;
我使用此脚本添加记录：
#!/bin/bash
#Defining Variables
DNS_SERVER="localhost"
DNS_ZONE="example.com."
USER_NAME="dd2.example.com."
IP="192.168.1.7" …这是我解决的问题的报告，但我觉得该解决方案可能对其他人有用。
该问题出现在 Raspbian 9.13 上。由于某些（可能是硬件）原因仍有待发现，我的基于 Raspberry pi 的路由器崩溃了并且无法重新启动。我发现它卡在树莓派刚刚通电时显示的类似彩虹的图像上。
不管怎样，我重新启动了 Pi，一切都像往常一样工作。
唯一不起作用的是 Bind 9。守护进程正在运行，但名称解析不起作用。
我查看了以下帮助：https://dnsinstitute.com/documentation/dnssec-guide/ch05s04.html，因为我在 /var/log/named/dnssec.log 中发现了奇怪的日志：
validating ./NS: verify failed due to bad signature (keyid=60955): RRSIG validity period has not begun
我发现的一个可能的解决方案是，确实，时间不对：圆周率显示的时间是过去五个小时前的时间。这解释了为什么它在未来发现 RRSIG 的有效性。
问题是：它无法正确设置时间，因为它无法解析 NTP 服务器名称。因为名称解析根本不起作用，因为时间不对。