除了INTERNET之外，还有其他DNS类有用的用例吗

Question

IN(ternet)类是默认类。

我知道另一个有用的，CHAOS:

censurfridns:

% dig @91.239.100.100 version.bind TXT CHAOS +short
"9.11.4-P2+dampening"

其他的有用例吗？

• CS又名CSNET类(已过时)
• HS又名Hesiod[Dyer 87]

来源http://www.faqs.org/rfcs/rfc2929.html

RR类IANA注意事项

DNS类很少被使用，但构成了另一个维度DNS分布式数据库的。特别是的名称空间或根服务器之间的必要关系一类和另一类的。相同的名称可以有尽管标签类型相同，空标签只能用作根在每一个班级。然而，正如全球网络和DNS进化、IN或互联网，CLASS已经主导了DNS的使用。

DNS类别有两个子类别：包含类和仅在查询或更新中有意义的QCLASSE。

当前CLASS分配和未来
分配的注意事项如下：

Decimal    Hexadecimal
0    0x0000 - assignment requires an IETF Standards Action.
1    0x0001 - Internet (IN).
2    0x0002 - available for assignment by IETF Consensus as a data CLASS.
3    0x0003 - Chaos (CH) [Moon 1981].
4    0x0004 - Hesiod (HS) [Dyer 1987].
5 - 127    0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only.
128 - 253    0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only.
254    0x00FE - QCLASS None [RFC 2136].
255    0x00FF - QCLASS Any [RFC 1035].
256 - 32767    0x0100 - 0x7FFF - assigned by IETF Consensus.
32768 - 65280    0x8000 - 0xFEFF - assigned based on Specification Required as defined
in [RFC 2434].
65280 - 65534    0xFF00 - 0xFFFE - Private Use.
65535    0xFFFF - can only be assigned by an IETF Standards Action.

Answer 1

所有其他的基本上都已过时，不再使用。

请参阅https://miek.nl/2009/july/31/dns-classes/对于一些解释，例如：

CH类在Chaosnet中有其用途，这是一个没有实现的网络实现，与当前的以太网+TCP/IP组合不同。[..]今天，由于以下巧妙的技巧，CH类被BIND误用了：。。。

和

HS类的起源是Project Athena(另请参阅维基百科。这是一个命名服务器ala nis或更新的ldap。有了HS类，你可以将用户和组数据放在DNS中，所以你可以不用ldap服务器。如果你想玩这个，包hesiod仍然可以安装。

RFC2929第3.2节(2000年9月！)已经说过：

DNS类很少被使用，但构成了DNS分布式数据库。[..]然而，随着全球网络和DNS的发展，IN或Internet已经主导了DNS的使用。

现在人们普遍认为，DNS规范对类以及它们之间的隔离程度不够清楚。

此最新文档(https://tools.ietf.org/id/draft-sullivan-dns-class-useless-03.html)2016年7月，对目前的状况和未来的行动进行了解释

域名系统资源记录部分由其类标识。类字段无效，并且没有按照预期的方式使用。这份备忘录没有建议使用DNS参数注册表，但敦促那些定义新RRTYPE的人为所有类定义它们。

[..]

截至本文撰写之时，只有三个"普通的"；分配的类。第一类是互联网或IN类。第3类是混沌或CH类。第4类是赫西俄德或HS类。类2在[RFC1035]中被标记为CSNET或CS类，但当前注册表(位于http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-参数-2)不再包括赋值。

[..]

3. DNS类实际上是残余的

考虑到上述因素，很明显，DNS类在未来不太可能有用。新名称系统的设计者应该考虑DNS中类的设计。如果需要类似的功能，则其设计需要不同才能有用。然而，考虑到DNS在没有类的情况下有效发展的方式，值得一问的是，该功能是否有用。

您可以找到很多关于它的讨论，特别是在IETF工作组dnsop中，这些讨论涉及以下主题：

• https://www.mail-archive.com/[e-mail]/msg14877.html
• https://www.iab.org/mail-archive/web/inip-discuss/current/msg00060.html

RFC 8324-DNS隐私、授权、特殊用途、编码、字符、匹配和根结构中也引用了这个特定的互联网草案：是时候另眼相看了吗？作为[沙利文类]在：

近年来，对新服务和扩展服务的需求以及DNS又导致了DNS扩展或更改的提议各种各样的。[..]A原始DNS规范的一些功能，例如CLASS属性和标签类型，也被认为非常糟糕指定应弃用[Slivan Class]。

和

3.6.DNS框架中公用的备用命名空间：CLASS问题

DNS标准包括CLASS值的规范；识别协议族或协议实例"；(RFC 1034，第3.6节和其他地方)。虽然CLASS在DNS的早期被有效地用于管理同一管理环境中的不同协议族，最近试图使用它以其他方式(如非ASCII名称)划分DNS名称空间(部分是为了解决第3.2和3.3节中的问题)，或者将DNS机制用于完全不同的名称空间，这暴露了该机制的基本问题[Slivan Class]。也许这些问题中最根本的问题是，对于给定区域内是否打算存在多个CLASS(RRSET中有记录)，或者不同的CLASS是否意味着不同的区域，存在分歧。不同的实现方式会做出不同的假设[Faltstrom-2004][Vixie-207004]。这些问题导致建议完全取消[沙利文类]，但2017年年中IETF名单和工作组的讨论表明，在这一问题上没有明确的共识。