Все остальные в основном устарели и не используются.
См. https://miek.nl/2009/july/31/dns-classes/ для некоторых объяснений, таких как:
Класс CH используется вChaosnet, которая является сетевой реализацией, которая этого не сделала, в отличие от текущей комбинации Ethernet + TCP / IP.[..] Сегодня класс CH неправильно используется BIND для следующих хитрых трюков: ...
и
Класс HS имеет свои истоки Project Athena (см. также Википедию. Это сервер именования или более поздний ldap. С классом HS вы можете помещать данные пользователя и группы в свой DNS, так что вы можете обойтись без сервера ldap. Если вы хотите, пакет hesiod по-прежнему может быть установлен.поиграйте с этим.
Раздел 3.2 RFC2929 (сентябрь 2000!) уже говорит:
DNS-КЛАССЫ мало используются, но представляют собой другое измерениераспределенной базы данных DNS. [..] Однако, поскольку глобальные сети и DNS развивались, IN или Internet, CLASS доминировали в использовании DNS.
В настоящее время широко распространено мнение, что спецификация DNSнедостаточно ясно относительно классов и степени их изоляции друг от друга.
В этом последнем документе (https://tools.ietf.org/id/draft-sullivan-dns-class-useless-03.html) в июле 2016 г. приведены пояснения о текущем состоянии и что делатьв будущем:
Записи ресурсов системы доменных имен частично идентифицируются по их классу.Поле класса неэффективно и не используется так, как оно было задумано.В этом меморандуме нет рекомендаций относительно реестра параметров DNS, но он призывает тех, кто определяет новые RRTYPE, определять их для всех классов.
[..]
На момент написания статьи было назначено только три «обычных» класса.Класс 1 - это Интернет или класс IN.Класс 3 - это класс Chaos или CH.Класс 4 - это класс Hesiod или HS.Класс 2 отмечен в [RFC1035] как класс CSNET или CS, но текущий реестр (в http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-2) больше не включает назначение.
[..]
Классы DNS фактически являются рудиментарными
Учитывая вышеприведенные соображения, ясно, что классы DNS вряд ли будут полезны в будущем.Разработчики новых систем имен должны учитывать дизайн классов в DNS.Если подобная функция желательна, ее дизайн должен быть другим, чтобы быть полезным.Однако, учитывая то, как DNS удалось эффективно развиваться без классов, однако, стоит спросить, полезна ли эта функция вообще.
Вы можете найти множество обсуждений по этому вопросу, особенно врабочая группа IETF dnsop, занимающаяся этими темами:
На этот конкретный интернет-проект также ссылаются в RFC 8324 - Конфиденциальность DNS, авторизация, специальное использование, кодирование, символы, сопоставление и корневая структура: время для другого взгляда? как [Sullivan-Class] в:
В последние годы спрос на новые и расширенные услуги и использование DNS, в свою очередь, привел к предложениям по расширениям DNS или изменениямразличные сорта.[..] Некоторые свойства исходной спецификации DNS, такие как свойство CLASS и типы меток, также были предложены настолько плохо заданными, что их не рекомендуется использовать [Sullivan-Class].
и
3.6.Альтернативные пространства имен для общего пользования в структуре DNS: проблема CLASS
Стандарты DNS включают в себя спецификацию значения CLASS, которое «идентифицирует семейство протоколов или экземпляр протокола» (RFC 1034, раздел 3.6, и в других местах).В то время как CLASS эффективно использовался в первые дни DNS для управления различными семействами протоколов в одной и той же административной среде, недавние попытки использовать его для разделения пространства имен DNS другими способами, например, для имен не-ASCII (частично для решения проблем)в разделах 3.2 и 3.3) или использование механизмов DNS для совершенно разных пространств имен выявили фундаментальные проблемы с механизмом [класс Салливана].Возможно, самой фундаментальной из этих проблем является несогласие относительно того, предполагалось ли существование нескольких КЛАССОВ в данной зоне (с записями в RRSET) или разные классы подразумевают разные зоны.Различные реализации делают разные предположения [Faltstrom-2004] [Vixie-20170704].Эти проблемы привели к тому, что рекомендации были исключены полностью [класс Салливана], но обсуждения списка IETF и рабочих групп в середине 2017 года дали понять, что нет четкого консенсуса по этому вопросу.