大型区域通常会将子区域委托给其他网络。大公司将区域委托给办公室甚至国家，互联网服务提供商将地址空间委托给客户，甚至像我这样的小组织也可能为不同的办公室拥有子域。如果你幸运地在总部或ISP管理DNS，你必须能够将区域委派给你的客户。如果你想用DNSSEC保护这些子区域，你需要正确地委派这些区域并输入正确的DS记录。
大多数区域是另一个区域的子区域。它们通常被称为 subdomains （子域），尽管这并不总是严格准确的。我的区域 mwl.io 是 .io 的子区域。另一种说法是 .io 已将 mwl.io 委托给我。当我的写作帝国走向全球时，我可能需要建立自己的代表团，如 us.mwl.io 和 uk.mwl.io ，为它们分配自己的名称服务器，并最终拥有 comfychair.manchester.uk.mwl.io 等主机名。
所有区域都需要其父域中的NS记录，声明该区域的名称服务器。让相同的名称服务器为子区域和父区域服务是可以的，但你的名字需要为它们提供单独的名称服务器。如果你想在 us.mwl.io 和 uk.mwl.io 下有单独的记录，它们需要在父区域中有单独的区域文件和单独的NS记录。
子区域最常见的用途之一是为地址空间委派反向DNS。一家全球性公司可能会使用10/8作为内部地址，并将各种/16或/24块分配给不同的部门或位置。（他们也可能使用RFC 2317在非八位字节边界上进行委托，但在这里证明这只会使示例复杂化。）这样的组织有一个内部权威服务器，负责维护每个委托的NS记录。
假设我们的全球公司已将10.0/16授权给美国，10.1/16授权给与英国。您运行负责将区域授权给其他部门的总部名称服务器。10/8的权威名称服务器需要三个单独的区域文件，每个区域一个。这是10/8区域的区域文件的开头，其中包含每个子域的NS记录。
$TTL 3600$ORIGIN 10.in-addr.arpa.@ SOA mwl.io. mwl.mwl.io. 2021093002 3600 900 3600000 3600 NS ns1.mwl.io. NS ns2.mwl.io.;USA 0 NS ns1.mwl.io. 0 NS ns2.mwl.io.;UK 1 NS ns3.mwl.io. 1 NS ns4.mwl.io.权威服务器上的10.0/16区域包含/24区域的NS记录，以及递归客户端查找这些服务器所需的任何粘合（glue）记录。同样，10.1/16区域需要其NS和粘合记录。
10.1/16授权的委托服务器不需要每个区域的桌面、文件服务器或其他常见DNS条目的任何记录。它只需要NS和粘合记录来引导递归客户端到10.1.0/24等区域的权威服务器，就像上面的例子一样。
只有当您到达委托链的底部（delegation chain）时，才需要输入实际的特定于主机的记录。
一旦您的客户端可以成功地对您的内部地址执行反向DNS检查，并且您已经验证了每个级别的委派都正确地委派了自己的NS记录，您就可以继续。用一系列查询仔细检查你的工作。同样，您必须查询自己的名称服务器，而不是公共服务器。
xxxxxxxxxx$ dig -x 10 any这应该会为您提供10/8的权威名称服务器列表。然后选择一个你知道应该委派的子区域，比如10.0/16。
xxxxxxxxxx$ dig -x 10.0 any您应该获得此区域的权威名称服务器列表。选择您知道应该委派的该区域的子区域，例如10.0.1/24。
xxxxxxxxxx$ dig -x 10.0.1 any您应该获得此子区域的权威名称服务器列表。最后，在您知道应该存在的主机上获取反向DNS。
xxxxxxxxxx$ dig -x 10.0.1.1 +shortgateway.nyc.us.mwl.io.一切都被正确地委派，您的客户端可以通过委派链递归来解析各个主机。你可以继续。
在尝试将DNSSEC委托给您的委托区域之前，请确保您的主区域具有有效的签名，并且无关的解析器可以验证它们。如果我想保护 mwl.io 的子区域，我必须首先保护 mwl.io 本身。如果在中间有一个断裂的环节，信任链就不起作用。如果您正在委派私人地址空间或外部世界无法访问的真正私人域，请仔细检查您的递归服务器是否可以执行常规DNSSEC验证。
当您将DNSSEC添加到您负责的区域时，您将为您的区域创建密钥，并将DS记录提交给您的注册商或RIR。注册商将DS记录添加到父区域。运行父区域时，您负责为子区域添加DS记录。DS记录是公共信息，因此不要采取特殊手段来确保机密性。虽然注册商有提交DS记录的漂亮网站，但您的组织可能没有。如何传输和验证这些记录取决于您的组织和安全配置文件，但您最终会得到一个看起来像这样的区域文件：
x$TTL 3600$ORIGIN 10.in-addr.arpa.@ SOA mwl.io. mwl.mwl.io. 2021093002 3600 900 3600000 3600 NS ns1.mwl.io. NS ns2.mwl.io.;USA 0 NS ns1.mwl.io. 0 NS ns2.mwl.io. 0 DS 6696 13 2 F838747750FC505D90C20F2E9317E1A834ACB47E07274AD8CD29EFD5E8FE4B32;UK 1 NS ns3.mwl.io. 1 NS ns4.mwl.io. 1 DS 408 13 2 6D25E5CAAC3FB76D645204DEAAB5E6D789FB83FA5D2D5CB0484CCD1C51D9AC42重新加载该区域，这些DS记录将把子区域附加到信任链。
如果你使用BIND，保护你委托的区域就像保护委托给你的区域一样，第5章对此进行了讨论。将策略应用于该区域以生成密钥。在CSK或KSK上运行dnssec dsfromkey以获取DS记录。将该记录发送给父区域管理员。搞定。
如果您有问题，请回到第6章中的故障排除步骤。最常见的错误包括错误的时钟和与子区域的KSK或CSK不匹配的DS记录，这与处理区域的父域时可能出现的错误完全相同。
有时组织想要完全私有的区域。最常见的情况是，他们使用RFC 6761地址，如10/8、172.16/12和192.168/16，并且必须提供自己的反向DNS。您可以使用DNSSEC保护这些私有地址，至少对于使用您自己的递归名称服务器的内部客户端是这样。
许多组织还希望在防火墙内使用私有域名。某些协议使用 .local ，但这是为mDNS保留的。像 .test 和 .example 这样的域名可供内部使用，但在生产中使用它们看起来很摇摇欲坠（ramshackle）。一些大型组织创建了自己的顶级域名，但ICANN不断授权新的顶级域名。你有两个选择。域名 home.arpa 专门分配用于专用网络，如您的房子。如果你是一家大公司，不想看起来像一个家庭网络，注册一个公共域名，并为其提供最小或不存在的公共DNS。不过，如果你坚持编造一些东西，你仍然可以通过创建一个新的信任锚来使用DNSSEC来保护它。
信任锚是KSK的公钥。如果你告诉你的递归名称服务器信任该密钥，你将拥有自己的不依赖于外部世界的信任链。这通常被称为信任岛（island of trust）。
在开始之前，请记住查询区域的权威服务器永远不会返回经过身份验证的数据。如果你想在 10.in-addr.arpa 上进行DNSSEC验证，你就无法查询权威服务器。相反，您必须配置一个递归服务器，并将其配置为查询该区域的权威服务器。如果您的名称服务器既权威又递归，那么如果没有非常棘手的配置，就无法部署信任岛。棘手的配置很脆弱，虚拟机很便宜。
像对任何公共区域一样对您的私有区域进行签名，并在父区域中输入DS记录。
最高私人区域的KSK是您的私人信任锚。您必须在递归、验证的名称服务器上部署它。如果您在10/8部署DNSSEC，并且通过网络进行/16和/24委派，则10/8的KSK是整个区域的信任锚点。进入该区域的密钥目录，找到KSK或CSK文件。第一行将标识密钥的作用，而最后一行是密钥。
xxxxxxxxxx; This is a key-signing key, keyid 22456, for 10.in-addr.arpa.…10.in-addr.arpa. 3600 IN DNSKEY 257 3 13 NflrczcSQ…用dig来验证这一点：
$ dig zonename dnskey @nameserver +nocomments +nostats
这将吐出该区域的所有DNSKEY记录，您应该在结果中看到您的密钥。
密钥22456是我们的KSK。将最后一行拉到单独的文件中。
xxxxxxxxxx$ tail -1 K10.in-addr.arpa.+013+22456.key > /tmp/trust-anchor.txt我们将编辑密钥，使其适合BIND信任锚。其他名称服务器使用类似但不一定相同的格式。
xxxxxxxxxx10.in-addr.arpa. 3600 IN DNSKEY 257 3 13 NflrczcSQ…删除此行中的TTL（3600）、IN和DNSKEY。用字符串 static-key 替换它们。在地址和密钥周围加上双引号，并在末尾加上分号：
xxxxxxxxxx"10.in-addr.arpa." static-key 257 3 13 "NflrczcSQ…";保存文件。这是您的信任岛的私人信任锚。现在，您可以将递归服务器配置为信任10/8区域的此密钥，并将其用于查询。
BIND自动维护公共根区域信任锚。对于信任岛，您必须配置私有信任锚。在 named.conf 中添加 trust-anchors 节：
trust-anchors { zone static-key 257 3 algorithm key ; };
区域声明限制BIND仅对该区域使用此信任锚。 static-key 关键字告诉BIND，它不应该像检查全局信任锚一样检查此密钥的更新。257 3 表示这是用于DNSSEC的密钥签名密钥。接下来给出算法编号，然后用引号括住密钥本身。
我们10/8的钥匙看起来像这样：
xxxxxxxxxxtrust-anchors { "10.in-addr.arpa." static-key 257 3 13 "NflrczcSQTFxHIp2qCGO…";};现在告诉BIND将此域的查询提交给您的内部权威服务器，而不是公共根服务器。转发器既不验证也不缓存，因此不要转发查询。使用 stub zone 。Stub区域将查询定向到特定的名称服务器，但结果会在本地缓存。
xxxxxxxxxxzone "10.in-addr.arpa." { type stub; primaries { 192.0.2.100; 203.0.113.100; };};重新加载名称服务器。此递归名称服务器现在在此区域上使用您的信任锚点。
要验证您的信任岛是否正常工作，请查询您的递归名称服务器。
xxxxxxxxxx$ dig -x 10.0.1.1 @localhost +ad…;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1…;; ANSWER SECTION:1.1.0.10.in-addr.arpa. 3010 IN PTR gateway.nyc.us.mwl.io.…此查询返回PTR记录，并设置AD标志。这是经过身份验证的数据。您的DNSSEC有效。你有一个舒适的小信任岛。
现在您已经有了一个用于主机和地址的安全分布式数据库，让我们通过向其中填充其他信息来完成我们的探索。