Estamos tendo um site de pré-lançamento para testar o DNS (e outros serviços) antes de ficar quente. Eu nunca envolvi IPs públicos aqui anteriormente e pode não funcionar como eu pretendia. Temos uma rede /29 do nosso ISP que são IPs públicos. 121.24.124.144/29. Para testar nosso DNS para diferentes "views" nós configuramos o lado LAN de um roteador para emular esta rede; com o roteador como o GW para o nosso ISP. Além de não ser capaz de se conectar de fora (o que obviamente poderia ser feito por meio de encaminhamento de porta), essa não é a intenção aqui.)
Topologia:
O roteador que está conectado ao nosso ISP está conectado por dhcp com NAT à nossa rede. IP da LAN definido como 121.24.124.145/29 (Esta é a nossa própria rede IP, portanto, não deve ser conectada de fora neste momento) Deve (e funciona) funcionar como prisioneiro no mundo da área local. Por enquanto.
O roteador (shelby) onde nosso DNS está conectado possui IP WAN como 121.24.124.146 e LAN 192.168.13.1. Servidor DNS (emma) em 192.168.13.2.
> dig -x 121.24.124.146 @192.168.13.2
resulta em:
;; ANSWER SECTION:
146.124.24.121.in-addr.arpa. 86400 IN PTR static-121-24-124-146.cust.com.
;; AUTHORITY SECTION:
124.24.121.in-addr.arpa. 77013 IN NS o.dns.cust.com.
124.24.121.in-addr.arpa. 77013 IN NS f.dns.cust.com.
;; ADDITIONAL SECTION:
f.dns.cust.com. 76895 IN A 19.71.22.3
o.dns.cust.com. 77013 IN A 19.71.18.5
(Qual é o proprietário atual (o ISP) do endereço IP neste momento)
onde eu assumi que nosso dns responderia com
;; ANSWER SECTION:
146.124.24.121.in-addr.arpa. 86400 IN PTR fw-shelby.energia.com.
Qualquer outro host local funciona como pretendido ao fazer uma pesquisa inversa, com IP/FQDN correto. O endereço de encaminhamento funciona bem.
> dig fw-shelby.energia.com
;; ANSWER SECTION:
fw-shelby.energia.com. 10800 IN CNAME shelby.energia.com.
shelby.energia.com. 10800 IN A 121.24.124.146
;; AUTHORITY SECTION:
energia.com. 10800 IN NS emma.energia.com.
;; ADDITIONAL SECTION:
emma.energia.com. 10800 IN A 192.168.13.1
Algumas questões surgem a partir deste resultado.
- O BIND está ciente dos IPs públicos em comparação com os internos (192.168. etc)? [de tal forma que um reverslookup resultará em uma pesquisa externa em vez de nosso fqdn local]
- Nosso arquivo reverso é configurado pelo fato de que a rede é /29, o que significa que começa em .144, o que sugere que o arquivo de pesquisa reversa também começa em 144.124.24.121.in-addr.arpa. Não consigo encontrar nenhuma informação nem exemplos de pequenas redes e arquivos de pesquisa reversa começando em qualquer lugar, exceto em 0....in-addr.arpa. Isso é uma limitação, uma solução incomum ou uma falha fazendo isso?
- Se isso não estiver quebrado nem correto - como isso seria configurado para funcionar?
Arquivos afetados:
/etc/bind/zonefiles/public/named.reverse.zone.conf
zone "144.124.24.121.in-addr.arpa"
{
type master;
file "/etc/bind/zonefiles/public/reverse-144.124.24.121.zone";
allow-update { none; };
};
; /etc/bind/zonefiles/public/reverse-144.124.24.121.zone
; 121.24.124.144 (-121.24.124.151)
$ORIGIN 144.124.24.121.in-addr.arpa.
$TTL 345600
@ IN SOA emma.energia.com. root.emma.energia.com. (
2022101102 ;Serial
86400 ;Refresh 24 hours
7200 ;Retry 2 hours
2592000 ;Expire 30 days
345600 ) ;Minimum 4 days
IN NS emma.energia.com.
145 IN PTR gw-isp.energia.com.
146 IN PTR shelby.energia.com.
147 IN PTR shelley.energia.com.
148 IN PTR mailis.energia.com.
149 IN PTR ava.energia.com.
150 IN PTR www.energia.com.
Eu verifiquei a zona de configuração para $ ORIGIN 124.24.121.in-addr.arpa. Só para descartar que zona reversa não pode ser permitida tão "pequena". Mas não, nenhuma diferença.
Quanto a uma referência:
; Bind reverse hosts
$ORIGIN 13.168.192.in-addr.arpa.
$TTL 345600
@ IN SOA emma.energia.com. root.emma.energia.com. (
1998030900 ;Serial
86400 ;Refresh 24 hours
7200 ;Retry 2 hours
2592000 ;Expire 30 days
345600 ) ;Minimum 4 days
IN NS emma.energia.com.
1 IN PTR gw-shelby.energia.com.
2 IN PTR emma.energia.com.
3 IN PTR gw-rivendale-link-br.energia.com.
4 IN PTR unused-ip-rd4.energia.com.
Funciona bem tanto para frente quanto para trás. Eu não enviei nenhum outro arquivo de configuração nomeado, pois o resto funciona e os logs confirmam que as zonas foram carregadas. Mas se precisar pergunte!
Seria menos frustrante ter nossos próprios nomes reversos surgindo. Os nomes reversos dos ISPs são apenas confusos.
O que você faz internamente com os registros DNS reversos para os endereços IP públicos atribuídos pelo seu provedor depende de você, mas o resto da Internet verá apenas o que seu ISP oferece/suporta/configura para você.
Pessoalmente, eu me alinharia com eles em vez de substituir localmente quaisquer que sejam os registros DNS reversos para 121.24.124.144/29 que estejam ou não definidos.
Normalmente os ISPs:
O problema na sua configuração atual:
Isso configura uma zona DNS reversa para apenas 1 endereço IP, para
121.24.124.144e não para uma sub-rede.dig -x 121.24.124.146falha porque não é121.24.124.144.Não há realmente uma boa solução:
Use
zone "124.24.121.in-addr.arpa"em seu named.conf e você substituirá localmente os registros PTR para todos os IPs de todo o intervalo 121.24.124.0/24.Você pode (regularmente/uma vez) preencher o arquivo de zona com os valores atuais dos registros PTR (de todos os IPs não atribuídos a você) para mitigar.
Você define uma estrofe para cada endereço IP separado atribuído a você:
E, em seguida, configure um arquivo de zona (único) (que usa um pouco de
$ORIGINtruque para permitir que você use abreviação e um arquivo de zona único em vez de criar um arquivo de zona exclusivo para cada IP):