我发现我可以像这样编辑区域文件
$ORIGIN us.example.com.
@ IN DNAME another.example.com.
但是如果我事先不知道所有子域名怎么办？是否可以这样做：
$ORIGIN *.example.com.
@ IN DNAME another.example.com.
基本上，我想从每个子域重定向到单点。
这是可能的/正确的吗？我发现RFC 6672建议不要使用通配符。为什么会这样？这与我上面的情况有关吗？
编辑：如果上面不正确，我可以这样做吗：
*.example.com. IN DNAME example.com.
example.com. A 192.168.1.1
或这个
*.example.com. A 192.168.1.1
答案1
抛开这个$ORIGIN问题（Vasili 对此 100% 正确），定义DNAME记录类型的 RFC（RFC6672) 则积极阻止这种行为。
3.3. 通配符
不鼓励将 DNAME 与通配符结合使用 [RFC4592]。因此，不应使用“*.example.com DNAME example.net”形式的记录。
通配符扩展与 DNAME 重定向之间的交互是不确定的。由于处理过程是不确定的，DNSSEC 验证解析器可能无法验证通配符 DNAME。
如果加载了此类通配符 DNAME，服务器可能会发出警告，指出行为未指定。服务器可能会拒绝它、拒绝加载区域或拒绝动态更新。
虽然“不应该”和“可以”的措辞并不禁止你尝试这样做，但你真的不应该这样做。RFC4592参考，我们遇到了这个：
4.4. 通配符域名的 DNAME RRSet
通配符域名拥有 DNAME [RFC2672] RRSet 会对 DNS 的一致性构成威胁，应避免或彻底拒绝。这样的 DNAME RRSet 代表提供给不同缓存的规则的非确定性合成。随着缓存以不可预测的方式被提供给不同的规则，缓存将不再具有一致性。（“随着缓存被提供给”是指在缓存中存储由递归或迭代服务器响应获得的记录。）
这些标准定义 RFC 不仅提供了技术原因来说明为什么这是一个坏主意，而且还积极鼓励 DNS 软件不支持该功能，尽管没有明确禁止它。这些原因足以让我三思而后行，是否要尝试实现它。
答案2
这根本行不通，因为 $ORIGIN 必须包含有效的区域名称。通配符不是有效的区域名称。
最好的情况下，您可以希望编写脚本来创建 BIND 配置中所需的所有区域，并将它们全部指向同一个通用区域文件。