我发现我可以像这样编辑区域文件
$ORIGIN us.example.com. @ IN DNAME another.example.com. 但是如果我不事先知道所有的子域名，那么有可能做这样的事情：
$ORIGIN *.example.com. @ IN DNAME another.example.com.
基本上我想从每个子域redirect到单点。
这是可能的/正确的？ 我发现RFC 6672build议反对通配符的使用。 为什么这样？ 是关于我的情况呢？
编辑：如果以上不正确，我可以这样做：
*.example.com. IN DNAME example.com. example.com. A 192.168.1.1
或这个
*.example.com. A 192.168.1.1
抛开$ORIGIN问题（Vasili是100％正确的），定义了DNAMEloggingtypes（ RFC6672 ）的RFC积极劝阻它。
3.3。 通配符
不鼓励使用DNAME和通配符[RFC4592]。 因此，不应使用“* .example.com DNAME example.net”格式的logging。
通配符扩展和DNAMEredirect之间的相互作用是非确定性的。 由于处理是非确定性的，DNSSECvalidationparsing器可能无法validation通配DNAME。
一个服务器可能会给出一个警告，说明如果装载了这样的通配DNAME，则行为是未指定的。 服务器可以拒绝，拒绝加载该区域，或拒绝动态更新。
虽然语言“不应该”和“可能”不禁止你试图这样做，你真的不应该这样做。 遵循RFC4592的参考，我们碰到这个：
4.4。 DNAME RRSet在通配符域名
DNAME [RFC2672] RRSet的所有权由通配域名表示，对DNS的一致性构成威胁，应避免或彻底拒绝。 这样的DNAME RRSet代表不同高速caching的规则的非确定性合成。 随着caching的不同规则（以不可预测的方式）被caching，caching将不再是连贯的。 （“随着caching被馈送”是指通过recursion或迭代服务器在响应中获得的logging的caching中的存储）。
这些标准定义的RFC不仅提供了为什么这是一个坏主意的技术原因，它积极鼓励DNS软件不支持该function，而不明确禁止它。 这些原因足以让我三思而后行。
这将不起作用，因为$ ORIGIN必须包含有效的区域名称。 通配符不是有效的区域名称。
充其量，您可以希望在BINDconfiguration中创build所需的所有区域，并将它们全部指向同一个通用区域文件。