首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
DNS 参考资料
› List of DNS Record Types
› dig 使用说明
› djbdns
› DNS Parameters
› dnslib for Python
广告
TrustyWolf
V2EX  ›  DNS

用 BIND 搭建高可用性 DNSSEC Hidden Master Server - 2016 年版

  •  6      
  •   TrustyWolf · 2016-03-28 05:51:46 +08:00 · 7187 次点击
    这是一个创建于 2944 天前的主题，其中的信息可能已经有所发展或是发生改变。

    V2.0 - 2016.03.28 2016 年版 - DNSSEC Test Project
    V1.0 - 2014.10.31 2014 年版 - 发表于 V2EX /t/143009

    这是一个大坑 Orz
    距上一版发布已经一年半了，想想自己在 V2EX 发布过的所有主题贴，
    只有这篇有些许技术含量和参考价值，很是残念。
    这次春假打算把这个坑填完，也算是对自己有个交代了。

    因本人能力有限，本文可能存在错误或者过于主观的个人观点。
    希望大家能抱着批判的态度阅读 Orz

    本文同时发布于我的 个人博客
    并使用 CC BY-NC-SA 4.0 进行许可

    1. 关于 DNSSEC

    关于 DNSSEC 的背景、目的和原理，强烈建议大家先阅读清华大学段海新老师的这篇文章，讲解的非常好，只是由于年代原因，其中 BIND 配置的章节已经过时，关于配置部分请大家参考下文。

    简而言之， DNSSEC 通过数字签名的方法得以让用户验证 DNS 解析结果的真实性和完整性，但并不提供对 DNS 信息的加密，也就是说，在网络上传输的 DNS 信息依然是明文的，但是经过了可靠的签名。个人感觉这很类似于电子邮件领域的 PGP 签名，但 PGP 的公钥是自由发布的，可能并不可靠，而 DNSSEC 则建立了一套可靠的公钥基础设施（ PKI ），使得公钥像 SSL 证书一样也有了证书信任链。段老师的文章里还提到了可信锚（ Trust Anchors ），这就像 SSL 的根证书，在早些年 DNSSEC 的证书链还并未完善，有些顶级域的 DS 记录并未进入根域，这时候就需要 DNSSEC Look-aside Validation (DLV) 来提供证书信任链的支持，现在绝大部分的顶级域都已不再需要 DLV ， ISC 也将于 2017 年停止对 DLV 的支持。

    另一方面， DNSSEC 虽然是对现有 DNS 协议的扩展，但是对 DNS 报文的大小提出了更高的要求，支持 DNSSEC 的域名服务器必须支持 EDNS0 （见 RFC2671 ），即允许 DNS 报文大小必须达到 1220 字节（而不是最初的 512 字节），在目前的实际操作中， DNS 报文大小通常是 4096 字节。

    我们来做一个小实验验证一下：

    $ dig icann.org +dnssec +noadditional +multiline

; <<>> DiG 9.10.3-P4-RedHat-9.10.3-12.P4.fc25 <<>> icann.org +dnssec +noadditional +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50665
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;icann.org.             IN A

    可以看到 udp: 4096 ，代表报文大小。并且 DNSSEC 的验证并不是直接查询一次递归服务器得到 RRSIG 记录就行了的，还需要查询上一级域中的 DS 记录才能完成验证，所以说如果 DNSSEC 被广泛部署和运用，无疑大量增加了 DNS 服务器和网络的负担，也成为了 DNSSEC 部署的最大阻力之一。

    一个网域完成 DNSSEC 的部署需要以下前提条件：

    1. YOUR TOP-LEVEL DOMAIN (TLD) MUST BE SIGNEDTLD （顶级域的支持）
    2. YOUR DOMAIN REGISTRAR MUST SUPPORT DNSSEC （域名注册商的支持）
    3. YOUR DNS HOSTING PROVIDER MUST SUPPORT DNSSEC （ DNS 服务提供商的支持）

    早在 2010 年 5 月， ICANN 就已在全球 13 台 Root DNS Server 上部署了 DNSSEC ，并设立了专门的网站。根据最近的 TLD DNSSEC Report，全球 1262 个 TLD 中已有 1093 个的 DS 记录被添加进了 Root Zone ，也就是说 86.6% 的顶级域都已支持 DNSSEC 。域名注册商的支持方面也取得了不小的进展，国外各大域名注册商都逐渐对 DNSSEC 的 DS 记录添加功能提供了支持，比如 GoDaddy、Namecheap、Gandi.net 以及被 V2EXer 们讨论较多，性价比很高的NameSilo 等。具体的支持情况可以查询 ICANN 的 报表（不断更新中）。

    如上所述，目前看来 DNSSEC 部署最薄弱的环节还是在 DNS 服务提供商提供的 Master DNS 和运营商的递归 DNS ，当然，对于经济和技术实力有限的服务商来说，对 DNSSEC 保持谨慎的态度的确是一个明智的选择，因为在当今的网络环境中 DNS 非常脆弱， DNSSEC 并没有从根本上解决 DNS 服务本身的安全问题，针对 DNS 的 DDos 攻击依然存在，并且部署了 DNSSEC 之后被攻击所造成的后果可能更加严重，还可能产生新的隐私和安全问题，比如针对 DNSSEC NSEC 记录的恶意遍历攻击。

    在公共递归 DNS 领域，Google Public DNS 从 2013 年开始支持 DNSSEC 查询请求。国内， CNNIC 的 SDNS 云解析服务 也提供对 DNSSEC 的支持。而在运营商的递归 DNS 领域，国内基本还没有运营商支持 DNSSEC ，下面给出验证一台递归 DNS 是否支持 DNSSEC 的方法。

    $ dig icann.org +dnssec +noadditional +multiline @1.2.4.8 | grep RRSIG
icann.org.              600 IN RRSIG A 7 2 600 (
icann.org.              66748 IN RRSIG NS 7 2 86400 (

    如上所示， icann.org 是支持 DNSSEC 的域名，而 @1.2.4.8 指定了查询的 DNS 服务器（这里是 CNNIC 的公共 DNS ），当然如果不知道本地的递归 DNS 地址的话也可以留空。 dig 查询到了 RRSIG 记录，证明该递归 DNS 支持 DNSSEC 。

    而在 DNS 服务提供商领域，几乎很少有支持 DNSSEC 的免费 DNS 托管服务， Dyn, Inc. 和 Amazon 等服务提供商都在收费 DNS 产品中提供了对 DNSSEC 的支持。特例也是有的，那就是大土豪 CDN 服务提供商 CloudFlare ，在其与免费 CDN 所配套的 DNS 服务中提供了对 DNSSEC 的支持，并采用了 ECDSA 加密算法减少加密带来的服务器负担。

    2. DNSSEC Test Project

    好了，关于 DNSSEC 我们就介绍到这里，虽说 DNSSEC 有上述的缺点，但是作为一名励志成为大牛技术者的技术宅学生（ 大雾，并不妨碍咱的学习，当然学习了解 DNSSEC 的最好的方法就是自己动手部署一个支持它的网域。下面咱就从一个网域管理员的角度从零开始用 BIND 进行部署 DNSSEC 的测试。

    BIND 和 NSD 这两款常用的 DNS 服务器软件从很早的版本开始就已支持 DNSSEC 。 BIND 与 NSD 相比，虽然性能稍弱，但是相关的功能和文档都更加丰富，在各大 Linux 发行版的文档中都有 BIND 的身影，在 DNSSEC 领域更是如此，从 BIND 9.9 开始，新增了 Inline Signing 功能，这意味着 DNSSEC 的签名过程可以实现全自动，设定完毕后，平时的使用与维护操作与未导入 DNSSEC 功能时基本无异。

    本次测试搭建的是 Hidden Master Server ，关闭递归功能并开启区域传递，实际 DNS 查询流量由右侧的 Secondary DNS Server 负担，感谢 PUCK Free Secondary DNS Service 和 Roller Network 提供免费并且支持 DNSSEC 的 Secondary DNS 服务，整体架构如下：

    dnssec-inline-signing.png

    为了实现高可用性，运用了 Inline Signing 并用无期限的 KSK 签署整个域，不使用 ZSK ，避免了密钥的期限和更新问题。生成密钥的算法使用了 ECDSAP256SHA256 。

    0 ）测试环境

    $ cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 
$ named -v
BIND 9.9.4-RedHat-9.9.4-29.el7_2.3 (Extended Support Version)

    其他的发行版可能在命令或者配置文件的位置上稍有不同，本文仅供参考。

    1 ）系统准备

    • 系统安装和初始化设定（略）

    • SELinux 设定

      网络上的很多教程都在配置 BIND 时关闭了 SELinux，SELinux 严格控制着 BIND 对配置目录的访问和读写权限，这对提升 BIND 的安全性有极大的帮助，但也对配置文件存放的位置有了严格的要求，稍有差错 BIND 进程就会无法启动。 CentOS 7 运行 named-chroot 时无需更改配置文件的位置。经实际测试后发现named-chroot与 SELinux 并无冲突且无需对SELinux的规则作出修改，故出于安全考虑本次实验中开启 SELinux 。

      参考资料： 1. SELinux-DNS 2. RHEL 7 网络指南中关于 BIND 的章节

      其中 RHEL 7 网络指南中详细说明了 BIND 的各项配置文件的存放位置。

      $ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

    • 防火墙（ Firewalld ）设定

      $ sudo firewall-cmd --permanent --add-service=dns && sudo firewall-cmd --reload

    • BIND 安装

      $ sudo yum -y install bind-chroot && sudo systemctl enable named-chroot.service
$ named -v
BIND 9.9.4-RedHat-9.9.4-29.el7_2.3 (Extended Support Version)

      安装之后系统默认会生成 /etc/rndc.key，但是安全性较低，咱重新生成一个较高安全性的

      $ sudo rm -rf /etc/rndc.key
$ sudo rndc-confgen -a -b 256 -r /dev/urandom
$ sudo chown root:named /etc/rndc.key && sudo chmod 640 /etc/rndc.key

      默认配置下的 BIND 是一个支持 DNSSEC 的递归 DNS ，但只能供本机查询

      $ sudo systemctl start named.service
$ sudo systemctl status named.service
● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2016-03-27 19:47:20 JST; 2min 21s ago
...
$ systemctl stop named.service
    • Secondary DNS 服务商的设定 （略）

    2 ） DNSSEC Master Server 的部署

    • 配置文件的修改

      请参考 RHEL 7 的官方文档:

      $ sudo vi /etc/named.conf
# 用 ACL 管理 Secondary DNS Server

# Slave Servers
#
acl ntt { 
    204.42.254.5;
    2001:418:3f4::5;
};

acl roller { 
    208.79.240.3;
    208.79.241.3;
    2607:fe70:0:3::b;
    2607:fe70:0:4::b;
};

options {
  #listen-on port 53 { 127.0.0.1; }; # 注释掉以监听所有 IPv4 地址
  #listen-on-v6 port 53 { ::1; }; # 注释掉以监听所有 IPv6 地址
  version "DNSSEC Test System"; # 隐藏 DNS 服务器版本信息
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";
# allow-query     { localhost; };
  allow-query     { ntt; roller; }; # 只允许 Secondary DNS 查询
  allow-query-cache     { none; }; # 禁止查询缓存

/* 
 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
 - If you are building a RECURSIVE (caching) DNS server, you need to enable 
   recursion. 
 - If your recursive DNS server has a public IP address, you MUST enable access 
   control to limit queries to your legitimate users. Failing to do so will
   cause your server to become part of large scale DNS amplification 
   attacks. Implementing BCP38 within your network would greatly
   reduce such attack surface 
*/
  # recursion yes;
  recursion no; # 关闭递归功能

# 确保 dnssec 开启
dnssec-enable yes;
dnssec-validation yes;

/* Path to ISC DLV key */
/* In case you want to use ISC DLV, please uncomment the following line. */
//bindkeys-file "/etc/named.iscdlv.key"; # DLV 已经退出历史舞台

managed-keys-directory "/var/named/dynamic";

pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";

/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ # 出于安全考虑禁用 MD5
disable-algorithms "."  {
        RSAMD5;
    };
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
        category lame-servers { null; };
};

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

# Master Zones
#
zone "wolflab.net" IN {
  # Hidden master
  type master;
  file "dynamic/wolflab.net/wolflab.net.zone";
  allow-transfer { ntt; roller; };
  also-notify { 216.218.133.2; 2001:470:600::2; };
  # DNSSEC
  key-directory "dynamic/wolflab.net";
  update-check-ksk no;
  inline-signing yes;
  auto-dnssec maintain;
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

    • Zone 文件的修改、密钥生成和权限管理

      $ sudo mkdir /var/named/dynamic/wolflab.net
$ sudo vi /var/named/dynamic/wolflab.net/wolflab.net.zone
; wolflab.net V0.3 2016.03.27
;
wolflab.net.86400INSOAtest.wolflab.net. trustywolf.fedoraproject.org. (
2016032702;serial
10800;refresh
1800;retry
604800;expire
86400);minimum
; NS Server
wolflab.net.86400INNS    1.ntt.ns.wolflab.net.
wolflab.net.86400INNS    1.roller.ns.wolflab.net.
wolflab.net.86400INNS    2.roller.ns.wolflab.net.
; NS Server IP Addr
1.ntt.ns    3600INA    204.42.254.5
1.ntt.ns    3600INAAAA2001:418:3f4::5
1.roller.ns    3600INA    208.79.240.3
1.roller.ns    3600INAAAA2607:fe70:0:3::b
2.roller.ns    3600INA    208.79.241.3
2.roller.ns    3600INAAAA2607:fe70:0:4::b
; Web
@            3600INA    1.2.3.4
www          3600INA    5.6.7.8
...
$ sudo dnssec-keygen -a ECDSAP256SHA256 -f KSK -r /dev/urandom -K /var/named/dynamic/wolflab.net wolflab.net
$ sudo chmod 770 /var/named/dynamic/wolflab.net
$ sudo chmod 640 /var/named/dynamic/wolflab.net/K*.key
$ sudo chmod 640 /var/named/dynamic/wolflab.net/*.zone
$ sudo chown -R named:named /var/named/dynamic/wolflab.net

      稍微解释一下密钥生成时的参数：-a 密钥算法 -f 密钥类型（如果是 ZSK ，不需要此参数） -r 乱数来源 -K 输出目录

      生成了一对 KSK 密钥对 Kwolflab.net.+013+27278.key 和 Kwolflab.net.+013+27278.private，其中的 13 代表算法，而 27278 则是 KEY Tag ，一会去域名注册商的控制面板添加 DS 记录时会用到。

      named.conf 中 Zone 的配置里 update-check-ksk no; 代表忽略 ZSK 密钥，只使用 KSK 签署整个域，auto-dnssec maintain; 开启密钥的自动更新和配置。

    • 配置检查，测试

      $ sudo named-checkconf
$ sudo named-checkzone wolflab.net /var/named/dynamic/wolflab.net/wolflab.net.zone 
zone wolflab.net/IN: loaded serial 2016032702
OK
$ sudo systemctl start named.service
$ sudo systemctl status named.service
$ sudo rndc status
version: 9.9.4-RedHat-9.9.4-29.el7_2.3 (DNSSEC Test System) <id:8f9657aa>
CPUs found: 1
worker threads: 1
UDP listeners per interface: 1
number of zones: 8
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
$ sudo cat /var/named/data/named.run
managed-keys-zone: journal file is out of date: removing journal file
managed-keys-zone: loaded serial 2
zone 0.in-addr.arpa/IN: loaded serial 0
...
zone wolflab.net/IN (unsigned): loaded serial 2016032702
all zones loaded
running
zone wolflab.net/IN (signed): loaded serial 2016032702
zone wolflab.net/IN (signed): receive_secure_serial: unchanged
zone wolflab.net/IN (signed): sending notifies (serial 2016032702)
zone wolflab.net/IN (signed): reconfiguring zone keys
zone wolflab.net/IN (signed): next key event: 27-Mar-2016 22:53:40.332
client 204.42.254.5#38476 (wolflab.net): transfer of 'wolflab.net/IN': AXFR-style IXFR started
...
client 208.79.241.3#39571 (wolflab.net): transfer of 'wolflab.net/IN': AXFR-style IXFR ended
zone wolflab.net/IN (signed): sending notifies (serial 2016032707)
$ dig wolflab.net +dnssec +noadditional | grep RRSIG
wolflab.net.            3600    IN      RRSIG   A 13 2 3600 20160426120628 20160327115340 27278 wolflab.net. l8sMxaf124gGM9lUorEgLZXQyaqMonsiEqnRMFsXsFyz7KWWhkxnfHDU LtCu091T5y70EGX1SaDiKnG4V8Z0Kw==
wolflab.net.            86400   IN      RRSIG   NS 13 2 86400 20160426120628 20160327115340 27278 wolflab.net. G4/rPdcJ3E6rRKppP26HuCxC4Lg5qK4co/Dt3NB2wfmpP7oB2+F60b22 p3wV12mUFZkphYO9VhSBopGTQbV44Q==

      可以看到 dig 查询到了 RRSIG 记录，并且其中的 KEY-ID 27278 与之前生成的一致，部署成功！

    • 将 NSEC 记录转换为 NSEC3 记录

      关于 NSEC 和 NSEC3 的区别，请看这里，如果懂日语的话也可以参考这里，不得不说日本人画画的功力超级强大，复杂的技术几幅图就可以搞明白了 QAQ

      默认情况下， DNSSEC 使用 NSEC 记录来提供对不存在域名查询的确认，但这样也带来了一定的隐私问题，并造成了可以被递归攻击的可能， NSEC3 用哈希算法解决了这一问题，但这也会增加数据包的大小，造成一定的负担。

      $ dig bucunzai.wolflab.net +dnssec +noadditional +multiline | grep NSEC
wolflab.net.            10800 IN RRSIG NSEC 13 2 86400 (
wolflab.net.            10800 IN NSEC dnssec.wolflab.net. A NS SOA RRSIG NSEC DNSKEY TYPE65534

      我们随便 dig 查询一个不存在的域名，可以看到，目前使用的是 NSEC 记录，并且 dnssec.wolflab.net 这个真实存在的域名也暴露了，如果不希望这样，可以切换至 NSEC3 记录。

      配置上，由 NSEC 切换至 NSEC3 非常简单：

      $ sudo rndc signing -nsec3param 1 0 10 macadd wolflab.net
request queued

      这里的 10 是 NSEC3 使用的 Iteration 值，保持默认即可，而 macadd 是 Salt 值，是一个 16 进制数，且位数是 2 的倍数，咱这边取了 6 位。当然，你也可以随机生成它，使用下边的命令：

      $ sudo rndc signing -nsec3param 1 0 10 $(head -c 300 /dev/urandom | sha1sum | cut -b 1-16) wolflab.net
request queued

      这样应该更加稳妥并安全一些。我们在本地再次用 dig 查询一下：

      $ dig bucunzai.wolflab.net +dnssec +noadditional +multiline | grep NSEC
7585TJA4ACH33DMVN63QJ8LKS6EVU05U.wolflab.net. 10800 IN RRSIG NSEC3 13 3 86400 (
7585TJA4ACH33DMVN63QJ8LKS6EVU05U.wolflab.net. 10800 IN NSEC3 1 0 10 MACADD (
9A18DO8IAMUE44J23C0MVST1UMIT0G3S.wolflab.net. 10800 IN RRSIG NSEC3 13 3 86400 (
9A18DO8IAMUE44J23C0MVST1UMIT0G3S.wolflab.net. 10800 IN NSEC3 1 0 10 MACADD (
                                A NS SOA RRSIG DNSKEY NSEC3PARAM
AMV2HBM6CSNKT22R8DGLVCLQN95R5LP4.wolflab.net. 10800 IN RRSIG NSEC3 13 3 86400 (
AMV2HBM6CSNKT22R8DGLVCLQN95R5LP4.wolflab.net. 10800 IN NSEC3 1 0 10 MACADD (

      可以看到， NSEC3 已经启用成功，这样就很难知道dnssec.wolflab.net 这个域名是真实存在的了。

    • DS 记录的生成和上传

      经过以上步骤的测试，wolflab.net的 DNSSEC 记录已经符合规范。到这里可千万不能高兴太早，因为最后也是最重要的一部并没有完成： DS 记录的生成和上传。

      读过段老师的文章后，我们知道了 DS 记录其实就是之前生成的公钥的哈希值，用来提交给上一级的域名服务器。如果没有 DS 记录，那么这台 DNSSEC Master Server 公钥的真实性就没法得到证明，之前所有的努力都功亏一篑了。

      得到 DS 记录的方法有两种：

      $ dig wolflab.net DNSKEY | dnssec-dsfromkey -f - wolflab.net
wolflab.net. IN DS 27278 13 1 3154E9E29A2C597E85ED0A83CC49F45640E2432C
wolflab.net. IN DS 27278 13 2 58CC7785B063D7FD0668DA087DF181C9BF0A282EC3606A2D16AD1859120A2B9B
$ sudo dnssec-dsfromkey -a SHA-1 /var/named/dynamic/wolflab.net/K*.key
wolflab.net. IN DS 27278 13 1 3154E9E29A2C597E85ED0A83CC49F45640E2432C
$ sudo dnssec-dsfromkey -a SHA-256 /var/named/dynamic/wolflab.net/K*.key
wolflab.net. IN DS 27278 13 2 58CC7785B063D7FD0668DA087DF181C9BF0A282EC3606A2D16AD1859120A2B9B

      得到之后我们就可以去域名注册商的管理面板里添加这两行记录了，这里我以 NameSilo 为例：

      dnssec-ds-1.jpg

      全部添加完毕之后应该是这样的：

      dnssec-ds-2.jpg

      验证一下结果：

      $ dig wolflab.net ds +noadditional +multiline | grep DS
;wolflab.net.           IN DS
wolflab.net.            86400 IN DS 27278 13 1 (
wolflab.net.            86400 IN DS 27278 13 2 (

    • DNSSEC 在线检验工具

      DNSSEC Debugger

      dnssec-check-1.jpg

      DNSViz

      dnssec-check-2.jpg 前者速度较快，能够快速确定问题所在，后者比较直观，信息量更大。

    3 ） DNSSEC Master Server 的后续维护和管理

    由于此次搭建的是高可用性 DNSSEC Master Server ，并没有设置密钥的有效期，而且整个签署过程都是自动完成的。所以维护起来相当方便，不会造成因为密钥过期等原因导致的认证故障。

    当对 Zone 进行过修改后，使用 rndc reload 命令即可完成对整个域的重新签署，无需人工干预。

    但是出于安全考虑，强烈建议定期重新生成 KSK 密钥并更新 DS 记录，并确保密钥文件权限的正确。

    3. DNSSEC 的其他应用

    DNSSEC 除了可以验证域名解析结果之外，还可以与 TLSA 记录结合用来验证 x509 (SSL) 证书的真实性。这种技术被成为 DNS-based Authentication of Named Entities (DANE)，被定义于 RFC 6698 。

    生成 TSLA 的过程也很简单：

    $ openssl x509 -noout -fingerprint -sha256 < server.crt | tr -d :
SHA256 Fingerprint=2164CDDDCFAF27FF6A280043E6E3906CCB6BB4DD99938B795C0BA64ED42D7989

    其中 server.crt 就是 SSL 证书。

    然后在 Zone 文件中添加如下的记录：

    _443._tcp.dnssec       3600	IN	TLSA    1 0 1 2164CDDDCFAF27FF6A280043E6E3906CCB6BB4DD99938B795C0BA64ED42D7989

    dnssec 是原有的记录，可以按需替换为 www 等。之后使用 rndc reload 命令重新自动配置 BIND 。

    $ dig +dnssec +noall +answer +multi _443._tcp.dnssec.wolflab.net. TLSA
_443._tcp.dnssec.wolflab.net. 3600 IN TLSA 1 0 1 (
                                2164CDDDCFAF27FF6A280043E6E3906CCB6BB4DD9993
                                8B795C0BA64ED42D7989 )
_443._tcp.dnssec.wolflab.net. 3600 IN RRSIG TLSA 13 5 3600 (
                                20160426190854 20160327182354 27278 wolflab.net.
                                MupIX+iMEAItSiKOLz97pSGVcpkAyE4U6yu4cGnY6p5C
                                d9f/xf72KRGLyJ3Dkshy2BFAZoqkBxd7HACUA9zbxg== )

    使用 CZ.NIC Labs 提供的两款浏览器插件可以得到更加直观的显示效果，如图：

    dnssec-tlsa.jpg

    这款插件也可以对 DNSSEC 进行检测。

    4. 总结

    从 1997 年第一个有关 DNSSEC 的标准 RFC 2065 发布至今已经快 20 年了，但是很显然还有很漫长的路要走。

    最后很想用一个小时候看的动画片《春田花花同学会》里校长一段很经典的台词来结束这篇文章，也算是抒发一下心中的感慨了。

    各位同学，本校创校快将五十年，未够五十年，但是，差不多五十年啦。很快，本校创校就要超过五十年啦。 恩，在这接近五十年，未够五十年间，本校已经为社会培养了很多条栋梁，很块，本校会为社会培养出更多条栋梁。 也许有人会问，校长，你在这五十年里，培养了这么多条社会栋梁，实际上，又有什么用呢？在这，我可以很清楚地告诉大家，本校创办，还要很久才够五十周年。 至于本校会不会有机会去庆祝我们的五十周年呢？为我们的社会，培养出更多的栋梁。就要看本校这个月……能不能收齐同学的学费啦。谢谢各位。

    在技术进步的路上，的确还有很多的学费要交。不研究历史的人，注定要重复历史。

    最后，感谢方校长，让我下定决心踏上异国求学之路。

    Trusty Wolf

    2016 年 3 月 28 日于东京

    Ps. 由于目前支持 DNSSEC 的免费 Secondary DNS 服务太少且都集中在欧美，如果您觉得这篇文章对您有所帮助且您有长期稳定运行并支持 DNSSEC 的 DNS 服务器，希望您也能为 wolflab.net 提供 Secondary DNS QAQ

    PPs. @CloudXNS 你家的 DNS 蜘蛛简直丧心病狂 Log 满屏幕的 *.ns.dns-spider.ffdns.net 和 *.ns.dns-spider.myxns.cn Orz

    第 1 条附言  ·  2016-03-28 16:29:33 +08:00
    这里有一些个人认为比较有价值的文档供大家参考：
    https://trustywolf.fedorapeople.org/docs/dnssec/
  • DNSSEC
  • DNS
  • sudo
  • named
    25 条回复  •  2016-08-03 23:30:55 +08:00
    heiybb
        1
    heiybb  
       2016-03-28 06:45:38 +08:00 via Android
    支持一下
    dynaguy
        2
    dynaguy  
       2016-03-28 07:45:38 +08:00
    我有一个域名，注册在 GODADDY 。使用它家的 DNS 服务器。没有自己的 DNS 服务器如何使自己的域名得到 DNSSEC 呢？我到 GODADDY 看了一下，要升级账号（交月费）就会有自动 DS 记录。我这种基本客户有啥办法吗？
    msg7086
        3
    msg7086  
       2016-03-28 08:27:28 +08:00
    其实 DANE 能认证自签名证书么……
    laincat
        4
    laincat  
       2016-03-28 09:11:39 +08:00
    好详细~！支持一下！
    bobopu
        5
    bobopu  
       2016-03-28 10:27:23 +08:00
    支持。
    bubbles
        6
    bubbles  
       2016-03-28 10:35:28 +08:00
    支持一下，先收藏，再慢慢看。
    SFJ4MEGabMk2
        7
    SFJ4MEGabMk2  
       2016-03-28 10:46:04 +08:00
    👍， CloudXNS 的 DNS 爬虫是想干嘛？
    erenno1
        8
    erenno1  
       2016-03-28 12:06:26 +08:00
    礼貌回帖，支持下
    TrustyWolf
        9
    TrustyWolf  
    OP
       2016-03-28 12:23:39 +08:00 via iPhone   ❤️ 1
    @dynaguy 如果不打算自己搭建 DNS 的话，可以使用 CloudFlare 的 DNS 服务器，大土豪 CF 是免费支持 DNSSEC 的。而且他家的 DNS 使用了任播技术，生效很快。
    TrustyWolf
        10
    TrustyWolf  
    OP
       2016-03-28 12:26:57 +08:00 via iPhone
    @msg7086 可以的，但是要稍微改一下文中的 TLSA 记录，变为 IN TLSA 3 0 1 哈希值，也就是吧开头的 1 改为 3 。
    bclerdx
        11
    bclerdx  
       2016-03-28 13:11:59 +08:00
    科普知识，记号~
    chinvo
        12
    chinvo  
       2016-03-28 13:20:52 +08:00
    我在主从 ns 之间用的 dnscrypt /斜眼
    CloudXNS
        13
    CloudXNS  
       2016-03-28 14:21:23 +08:00
    @TrustyWolf
    @i386
    很抱歉影响到你们， CloudXNS 的爬虫是为运维工具 http://tools.cloudxns.net 服务的。
    若你们感觉受到干扰，可通过服务器防火墙屏蔽，亦可联系 CloudXNS 官方客服提供您的服务器 IP ，我们将联系技术人员在爬虫系统上过滤。
    TrustyWolf
        14
    TrustyWolf  
    OP
       2016-03-28 15:45:54 +08:00
    @CloudXNS 嘛，并没有受到干扰啦，咱就是觉得 CloudXNS 的爬取机制稍微有点问题，其他国外的 DNS 爬虫并不会在一个周期内进行多达 22 次的爬取，而且被服务器 denied 之后依然会爬。还有咱这台服务器只是在 SOA 记录里出现的啊，并不是 NS 记录里的服务器 QAQ
    TrustyWolf
        15
    TrustyWolf  
    OP
       2016-03-28 15:51:47 +08:00
    @chinvo 咱用的两台从服务器并不支持 TSIG QAQ
    dreammes
        16
    dreammes  
       2016-03-28 16:05:38 +08:00 via iPhone
    支持一下
    abel163
        17
    abel163  
       2016-03-28 16:26:39 +08:00
    绑定
    ovear
        18
    ovear  
       2016-03-28 16:28:09 +08:00 via Android
    菊巨。。前排支持
    TrustyWolf
        19
    TrustyWolf  
    OP
       2016-03-28 16:30:17 +08:00
    @ovear 并不是菊苣啦 =w=
    kn007
        20
    kn007  
       2016-03-28 16:36:05 +08:00
    前排支持！
    SFJ4MEGabMk2
        21
    SFJ4MEGabMk2  
       2016-03-28 21:27:41 +08:00 via iPhone
    @TrustyWolf 我曾经刚配置一个域名的 NS 记录，没多久 cloudxns 的爬虫就爬过 ns 服务器的 IP ，奇怪他们怎么得到信息的？
    dynaguy
        22
    dynaguy  
       2016-03-29 04:31:13 +08:00
    @TrustyWolf 可不可以这样：由 GoDaddy,Export 我的 zone file ， 然后在本地 dnssec-keygen 生成密钥，再手工将 DS 信息上交。问题是 dnssec-keygen 是不是必须在 DNS 服务器自身上运行？还是用另一台机器也可以？
    TrustyWolf
        23
    TrustyWolf  
    OP
       2016-03-29 13:59:51 +08:00   ❤️ 1
    @dynaguy dnssec-keygen 在任何一台装了 BIND 的机器上都可以运行，但是生成的密钥是用来供 dnssec-signzone 签署整个域用的，也就是说，网络上真正传递的域名信息是已经经过签名的，里面有 RRSIG 记录。所以说就算你把 DS 上传上去， dig 查询的结果里没有 RRSIG 记录也是不行的。咱这篇文章采用了自动签名的方法 dnssec-signzone 是自动完成的，你可以看看我上一版的文章 /t/143009 ，那是采用手工签署的方式，看完你就应该明白你理解的错误点在哪里了 ^_^
    hosiet
        24
    hosiet  
       2016-04-29 21:40:13 +08:00 via Android
    非常感谢，配置 DNSSEC 时参考了这篇文章（博客版），然后果断被坑到沟里去了，最后没按照这里面的步骤来做。不过某些内容还是很有用的。

    最后还是参考了 ISC 知识库中的文章，建议阅读: https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html
    bclerdx
        25
    bclerdx  
       2016-08-03 23:30:55 +08:00
    顶起，收藏备用了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3641 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 04:30 · PVG 12:30 · LAX 21:30 · JFK 00:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.