Classless Reverse Map delegate не работает с "dig -x". Это на что-то влияет?

Question

ПаутинаZytrax.com, где я узнал оБесклассовое обратное делегирование карты, говорит, что это dig -x <ip address>не должно работать, если используется этот метод делегирования (с использованием CNAMES).

Например:

Это не должно работать: dig -x 192.168.23.66

И это должно сработать: dig 66.64/27.168.192.IN-ADDR.ARPA

И это работает, когда я немного его модифицирую (указываю сервер, на который он был делегирован, и что мне нужна PTR-запись): dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA

Кажется, это работает так, как описано в руководстве:

Я установил похожее делегирование, и оно ведет себя так, как описано выше: когда я использую dig -xIP-адрес из делегированного диапазона, делегирующий сервер имен сообщает мне, кто имеет полномочия. 66.64/27.168.192.IN-ADDR.ARPA.Сервер, на который была делегирована бесклассовая сеть, работает только с третьей командой ( dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA).

Это нормально и безопасно?

Так как это не работает с dig -x (или nslookup), интересно, есть ли еще вещи, которые не работают. Могут ли резолверы разрешать такие IP-адреса без проблем? Например, могут ли почтовые серверы выполнять обратный поиск без проблем, если используется этот метод делегирования? Есть ли причины, по которым его не следует использовать?

Мой пример(с небольшими изменениями):

dig @ns1.example.com -x 192.168.134.1

;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60  IN  CNAME   1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN   NS      ns2.example.com.


dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.

;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR     1st_super.example.com.

Почему это не сработало

Название зоны, в которую я делегировал полномочия, было неправильным, и поскольку во втором запросе я использовал неправильное название, то получил ответ (эти две ошибки частично компенсировали друг друга).

Неправильно (не наоборот):

0-127.192.168.134.in-addr.arpa.

должно было:

0-127.134.168.192.in-addr.arpa.

После исправления этой ошибки и назначения делегирующего сервера подчиненным для делегированной зоны все dig -x <ipaddress>работает.

Answer 1

TL;DR

Если вы создадитеRFC2317-style classless in-addr.arpa delegate, совершенно нормально, что вы не можете напрямую запросить полномочный сервер имен для подделегирования с обратным отображением IP-адреса.
Что действительно важно, так это то, что сервер-резолвер может искать обратное имя (например dig -x 192.0.2.1 @8.8.8.8, для любой комбинации IP-адреса и сервера-резолвера, которая имеет отношение к вашей среде / вашему варианту использования).

Объяснение RFC2317

Общая проблема, для которой RFC2317 предоставляет своего рода обходной путь, заключается в том, что основанное на соглашениях сопоставление адреса IPv4 с обратным именем в DNS (например, 192.0.2.1-> 1.2.0.192.in-addr.arpa) предшествует бесклассовым делегированиям и фактически блокирует возможные точки делегирования для /0, /8, 16, /24, /32. (Вы можете делегировать только по каждой метке, а сопоставление определено так, чтобы просто сделать каждый октет адреса IPv4 меткой в ​​обратном порядке.)
Сопоставление должно было бы быть определено по-другому, сопоставлением с какой-то более детализированной схемой именования, чтобы фактически разрешить что-то вроде /27делегирования.

RFC2317 НЕ меняет фундаментальной ситуации, он фактически не меняет протокол никоим образом.
Все, что он делает, это предлагает схему, которую операторы-люди могут использовать для обхода ограничения, что бесклассовые делегирования невозможны.

Эту схему можно обобщить следующим образом:

1. Вы определяете псевдонимы (добавляете CNAMEзаписи) для некоторого набора имен в фактической обратной зоне (в соответствии с соглашением об именовании), сопоставляя их с новыми именами вновое пространство имен
   (Новое пространство имен действительно может иметьлюбойимя, но RFC2317 предлагает использовать описательное имя и разместить новое пространство имен как дочернее по отношению к существующей зоне где-то в in-addr.arpa)
2. Вы делегируете зону, соответствующую этомуновое пространство именкак надо

Результатом является то, что сервер-разрешитель, которому было предложено выполнить поиск, 1.2.0.192.in-addr.arpaпросто сделает это обычным образом и столкнется с этой CNAMEзаписью вместо той PTR, которую он действительно искал.
Затем он просто следует за CNAMEв новое пространство имен, не нуждаясь ни в каких знаниях о RFC2317, даже существующих, и если все было настроено так, как предлагается RFC2317, он найдет , PTRкоторый он может использовать в этом новом имени.

Если бы у вас, например, была 2.0.192.in-addr.arpa.зона ns1.other.example., включающая это:

1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.

Процесс поиска фактического обратного имени ( 1.2.0.192.in-addr.arpa.) приведет к получению CNAME, а распознаватель просто обработает CNAMEего обычным образом, следуя ему, куда бы он ни привел.

В этом примере он ведет к 1.0/27.2.0.192.in-addr.arpa., а также есть делегирование для зоны 0/27.2.0.192.in-addr.arpa.в ns7.example.com., поэтому распознаватель может просто продолжить процесс поиска дляновое имяи все получится.

С другой стороны, если вы отправите запрос на , 1.2.0.192.in-addr.arpa.он ns7.example.com.ничего об этом не узнает.
ns7.example.com. неесть обратная зона для этого адреса, у него есть только слабо связанная зона, на которую фактическая обратная зона ссылается с помощью этих псевдонимов.

Чтобы проверить, что делегирование в стиле RFC2317 работает, прежде всего, вы можете проверить, успешно ли реальный резолвер ищет имена.
Но, углубившись в детали, вы бы проверили, что отвечает сервер имен для реальной обратной зоны ( CNAMEв данном случае это должно быть a), проверили, куда делегируется каноническое имя ( CNAME«цель»), а затем проверили, отвечает ли этот сервер имен так, как и предполагалось, для канонического имени, указанного в CNAMEзаписи.