A delegação de mapa reverso sem classe não funciona com "dig -x". Isso afeta alguma coisa?

Question

A teiaZytrax. com, onde aprendi sobreDelegação de mapa reverso sem classe, diz que dig -x <ip address>não deveria funcionar se este método de delegação (usando CNAMES) for usado.

Por exemplo:

Isso não deveria funcionar: dig -x 192.168.23.66

E isso deve funcionar: dig 66.64/27.168.192.IN-ADDR.ARPA

E funciona quando eu modifico um pouco (especifique o servidor para onde foi delegado e que desejo o registro PTR): dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA

Parece funcionar conforme descrito no tutorial:

Defino uma delegação semelhante e ela se comporta conforme descrito acima: Quando utilizo dig -xcom um endereço IP do intervalo delegado, o servidor de nomes delegante me informa quem tem autoridade sobre 66.64/27.168.192.IN-ADDR.ARPA.O servidor para o qual a rede sem classe foi delegada funciona apenas com o terceiro comando ( dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA) .

Está tudo bem e seguro?

Como não funciona com dig -x (ou nslookup), gostaria de saber se há mais coisas que não funcionam. Os resolvedores podem resolver esses endereços IP sem problemas? Por exemplo, os servidores de email podem realizar pesquisa reversa sem problemas se esse método de delegação for usado? Há alguma razão para não usá-lo?

Meu exemplo(ligeiramente modificado):

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.

Por que não funcionou

O nome da zona para a qual deleguei estava errado e como usei o nome errado na segunda consulta, obtive uma resposta (os dois erros anularam-se parcialmente).

Errado (não invertido):

0-127.192.168.134.in-addr.arpa.

deveria ter ficado:

0-127.134.168.192.in-addr.arpa.

Com esse erro corrigido e com o servidor de delegação sendo escravo da zona delegada, tudo dig -x <ipaddress>funciona.

Answer 1

DR

Se você criar umRFC2317-style classless in-addr.arpa delegação, é totalmente normal que você não possa consultar o servidor de nomes oficial para a subdelegação diretamente com o mapeamento reverso do endereço IP.
O que realmente importa é que um servidor resolvedor possa procurar o nome reverso (por exemplo dig -x 192.0.2.1 @8.8.8.8, para qualquer combinação de endereço IP e servidor resolvedor que seja relevante em seu ambiente/para seu caso de uso).

Explicação RFC2317

O problema geral para o qual o RFC2317 fornece uma espécie de solução alternativa é como o mapeamento baseado em convenção do endereço IPv4 para o nome reverso no DNS (por exemplo, 192.0.2.1-> 1.2.0.192.in-addr.arpa) antecede as delegações sem classe e bloqueia efetivamente os possíveis pontos de delegação para /0, /8, 16, /24, /32. (Você só pode delegar em cada rótulo, e o mapeamento é definido para simplesmente transformar cada octeto do endereço IPv4 em um rótulo, na ordem inversa.)
O mapeamento teria que ser definido de forma diferente, mapeando em algum esquema de nomenclatura mais refinado. para realmente permitir algo como uma /27delegação.

RFC2317 NÃO altera a situação fundamental; na verdade, não altera o protocolo de forma alguma.
Tudo o que faz é sugerir um esquema que os operadores humanos possam utilizar para contornar a limitação de que as delegações sem classes não são possíveis.

Esse esquema pode ser resumido como:

1. Você define aliases (adiciona CNAMEregistros) para algum conjunto de nomes na zona reversa real (de acordo com a convenção de nomenclatura), mapeando-os para novos nomes em umnovo espaço para nome
   (O novo namespace pode realmente terqualquernome, mas RFC2317 sugere usar um nome descritivo e ter o novo namespace como filho de sua zona existente em algum lugar abaixo de in-addr.arpa)
2. Você delega a zona correspondente a estenovo espaço para nomecomo necessário

O resultado é que o servidor resolvedor solicitado a procurar 1.2.0.192.in-addr.arpasimplesmente fará isso normalmente e encontrará aquele CNAMEregistro em vez daquele PTRque realmente estava procurando.
Em seguida, ele simplesmente segue CNAMEpara o novo namespace sem precisar de qualquer conhecimento do RFC2317, mesmo existente, e se as coisas foram configuradas conforme sugerido pelo RFC2317, ele encontrará um PTRque pode usar com esse novo nome.

Se você, por exemplo, tivesse uma 2.0.192.in-addr.arpa.zona ns1.other.example.que incluísse isto:

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.

O processo de pesquisa para o nome reverso real ( 1.2.0.192.in-addr.arpa.) resultaria em CNAME, e o resolvedor apenas trataria o nome CNAMEnormalmente, seguindo-o para onde quer que ele levasse.

Neste exemplo, isso leva a 1.0/27.2.0.192.in-addr.arpa., e também há uma delegação para a zona 0/27.2.0.192.in-addr.arpa.to ns7.example.com., então o resolvedor pode simplesmente continuar o processo de pesquisa para onovo nomee tudo vai dar certo.

Se, por outro lado, você enviar uma consulta para 1.2.0.192.in-addr.arpa.ele ns7.example.com., não saberá nada sobre isso.
ns7.example.com. nãotiver a zona reversa para esse endereço, ele terá apenas uma zona vagamente relacionada à qual a zona reversa real se refere por meio desses aliases.

Para verificar se uma delegação no estilo RFC2317 funciona, em primeiro lugar, você pode verificar se um resolvedor real consegue procurar os nomes.
Mas, investigando os detalhes, você verificaria com o que o servidor de nomes da zona reversa real responde (deveria ser CNAMEneste caso), verificaria onde o nome canônico (o CNAME"destino") é delegado e, em seguida, verificaria se esse servidor de nomes responde conforme pretendido para o nome canônico conforme especificado pelo CNAMEregistro.