无法加载包含“富文本”PTRlogging的反向查找区域

概要

我尝试使用ISC Bind 9.9.5设置广域Bonjour（又名DNS-SD ），但无法加载提供“富文本”服务域发现的反向查找区域。

背景

根据浏览和注册域的发现（域枚举） ：

五个特殊的RR名字是为此目的而保留的：

b._dns-sd._udp.<domain>. db._dns-sd._udp.<domain>. r._dns-sd._udp.<domain>. dr._dns-sd._udp.<domain>. lb._dns-sd._udp.<domain>. 

通过对这些名称执行PTR查询，客户可以分别学习：

• 两个DNS区域：一个用于内部，另一个用于DMZ服务器，有可能吗？
• 如何以最less的configurationpipe理我的所有域名？
• BIND – 使用视图时SERVFAIL错误
• debian上的BIND 9.8.4，转发一个区域失败解决
• 内部和外部寻址之间的DNS故障转移

• 推荐浏览的域名列表。
• 一个推荐的默认域用于浏览。
• build议使用dynamic更新注册服务的域列表。
• 一个推荐的默认域用于注册服务。
• “传统浏览”或“自动浏览”域。

  [ deletia ] 

查询名称的<domain>部分也可以从主机的IP地址以不同的方式派生。 主机使用其IP地址并计算该地址及其子网掩码的逻辑与，以得出子网的“基本”地址（该子网的“networking地址”，或者等同于“全部”在该子网上的“零”主机地址）。 然后，它构造与该基地址相​​对应的常规DNS“反向映射”名称，并将其用作上述查询的名称的<domain>部分。 例如，如果主机的地址为192.168.12.34，子网掩码为255.255.0.0，那么子网的“基本”地址为192.168.0.0，并为此设备发现推荐的自动浏览域子网，主机发出名称为“lb._dns-sd._udp.0.0.168.192.in-addr.arpa”的DNS PTR查询。

另外，在域名下：

富文本服务子域名是允许和鼓励的，例如：

  Building 2, 1st Floor . example . com . Building 2, 2nd Floor . example . com . Building 2, 3rd Floor . example . com . Building 2, 4th Floor . example . com . 

因此，应该期望在DNS RR中看到以下几行：

 lb._dns-sd._udp.0.0.168.192.in-addr.arpa. PTR Building\ 2\,\ 1st\ Floor.example.com. 

问题

虽然我能够加载包含这样的PTRlogging的其他（例如向前查找）区域，我发现在in-addr.arpa我收到以下错误：

dns_rdata_fromtext：db.0.168.192.in-addr.arpa:26：在'Building \ 2 \，\ 1st \ Floor.example.com'附近：bad name（check-names）

所以，我的问题是：

1. 为什么这只发生在in-addr.arpa内？ 绑定显然给这样的区域特殊的待遇，但为什么？

2. 我怎样才能遵循build议，使“富文本”的服务子域名，同时从客户的networking地址发现？