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 进行许可
关于 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 的部署需要以下前提条件：
早在 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 加密算法减少加密带来的服务器负担。
好了，关于 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 服务，整体架构如下：
为了实现高可用性，运用了 Inline Signing 并用无期限的 KSK 签署整个域，不使用 ZSK ，避免了密钥的期限和更新问题。生成密钥的算法使用了 ECDSAP256SHA256 。
$ 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)
其他的发行版可能在命令或者配置文件的位置上稍有不同，本文仅供参考。
系统安装和初始化设定（略）
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
配置文件的修改
请参考 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 为例：
全部添加完毕之后应该是这样的：
验证一下结果：
$ 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 Master Server ，并没有设置密钥的有效期，而且整个签署过程都是自动完成的。所以维护起来相当方便，不会造成因为密钥过期等原因导致的认证故障。
当对 Zone 进行过修改后，使用 rndc reload 命令即可完成对整个域的重新签署，无需人工干预。
但是出于安全考虑，强烈建议定期重新生成 KSK 密钥并更新 DS 记录，并确保密钥文件权限的正确。
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 进行检测。
从 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
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.