Perguntas[bind](server)

Somos um novo ISP e um dos nossos clientes recentes tem um servidor de e-mail por trás do nosso IP público e está solicitando rDNS de nós. Temos um prefixo /21 e damos ao nosso cliente um prefixo /29 para seus serviços. Fiz algumas pesquisas e descobri que nós, como um ISP, somos responsáveis ​​por fazer rDNS, mas simplesmente não consigo encontrar muitas informações sobre como isso é configurado.

Criei um servidor bind9 como teste e criei uma zona de teste com zona reversa que está funcionando bem localmente, mas como faço para configurar isso sem mexer no domínio de nossos clientes?

Eu realmente apreciaria sua ajuda.

Cumprimentos,

Estou usando o BIND 9.18.28-0ubuntu0.24.04.1-Ubuntu para atender zonas assinadas por DNSSEC, mas quando atualizo uma zona, o serial SOA da zona assinada não se relaciona com o SOA não assinado.

Após a última atualização, meu arquivo de zona para a zona assinada tem o serial SOA 2024081200, mas a versão assinada da zona tem o serial 2024040710.

Se eu fizer uma alteração no arquivo de zona e alterar o serial SOA para 2024081301 e recarregar o Bind, o serial assinado muda para 2024040711.

Parece que não importa quais mudanças eu faça, o serial para a zona assinada é incrementado apenas em um. Quero que ele use o serial do arquivo de zona não assinado como a nova base para o serial assinado (incrementando-o em um quando as chaves são rotacionadas).

A zona está configurada assim

zone "example.com" IN {
    type primary;
    file "/var/cache/bind/zones/example.com";
    dnssec-policy default;
    inline-signing yes;
};

E minha política dnssec se parece com isso

dnssec-policy standard {
    dnskey-ttl 600;
    keys {
            ksk lifetime P365D algorithm ecdsap256sha256;
            zsk lifetime P60D algorithm ecdsap256sha256;
    };
    max-zone-ttl P1D;
    parent-ds-ttl PT1H;
    parent-propagation-delay PT1H;
    publish-safety PT1H;
    retire-safety PT1H;
    signatures-refresh P5D;
    signatures-validity P14D;
    signatures-validity-dnskey P14D;
    zone-propagation-delay PT5M;
};

O que estou perdendo?

Pergunta de novato. No BIND tenho que criar dois Name Servers, ns1 e ns2, para resolver 3 domínios relacionados a 3 sites no Apache. Apache e seus 3 domínios estão em um servidor dedicado chamado srv1.domain.tld Os dois servidores de nomes estão em dois VPS (ns1.domain.tld e ns2.domain.tld) ​​Obviamente todos os domínios são gerenciados pelo provedor com seu painel DNS. No painel de 3 domínios indiquei os dois novos Name Servers pessoais enquanto no painel domain.tld inseri os três registros A para os dois VPS e o servidor dedicado.

Gostaria de saber se no BIND, além das 3 zonas para os três domínios, tenho que criar uma zona para domínio.tld porque neste caso substituirá a zona gerenciada pelo provedor e suas configurações. Ou eu estou errado?

Hesito em fazer essa pergunta porque suspeito que estou sendo estúpido, mas...

No servidor Ubuntu 22.04 executando o bind 9.18.18, quando executo ddns-confgen -k host.example.com, ele gera algumas instruções referentes às chaves e configurações necessárias para a configuração do servidor nomeado. Também inclui o seguinte:

# After the keyfile has been placed, the following command will
# execute nsupdate using this key:
nsupdate -k <keyfile>

A página de manual afirma:

O nome da chave pode ser especificado usando o parâmetro -k e o padrão é ddns-key. A chave gerada é acompanhada por texto de configuração e instruções que podem ser usadas com nsupdate e nomeadas ao configurar DNS dinâmico

Onde está a "chave gerada" a que ela se refere (não há nada na página de manual sobre um caminho ou qualquer opção para isso)? Ele não aparece no diretório em que executei o comando, mas preciso dessa chave para fornecer ao nsupdatecomando ao atualizar a zona.

Estou usando nsupdate -lum script local para atualizar registros DNS no Bind9.

Está funcionando, exceto que preciso que o PHP tenha acesso de leitura à chave em /run/named/session.key.

Posso conceder acesso ao PHP alterando o grupo da chave para o usuário do processo PHP e adicionando g+rpermissões de leitura a ele, mas as permissões são revertidas bind:bindsempre chmod 600que o Bind é reiniciado.

Existe uma maneira de configurar as permissões padrão no Bind9 para /run/named/session.keyque um grupo diferente seja o proprietário e a leitura do grupo seja habilitada ( chmod 640) quando o Bind for iniciado?

Eu configurei um Bind9 para ser o DNS da minha rede. Estou usando-o como encaminhador e como resolução IP interna.

O problema é que não consigo reverter o DNS dos IPs da Internet.

Por exemplo, tenho um servidor proxy que mostra todos os domínios que tenho uma conexão aberta, mas depois de começar a usar o bind9, ele mostra apenas endereços IP e não domínios.

Não estou tentando resolver ips locais; Quero resolver ips de internet.

Fiz um teste, como você pode ver abaixo:

 C:\Users\ivola>nslookup youtube.com ns.lan
Server:  UnKnown
Address:  192.168.50.232

Non-authoritative answer:
Name:    youtube.com
Addresses:  2a03:2880:f10e:83:face:b00c:0:25de
          199.96.58.105




C:\Users\ivola>nslookup 199.96.58.105 ns.lan
Server:  UnKnown
Address:  192.168.50.232

*** Unknown: can't find 199.96.58.105: Non-existent domain

Minha configuração é muito básica:

opções {

    directory "/var/cache/bind";

    empty-zones-enable no;
    allow-query { any; };
     forwarders {
            8.8.4.4;        //google
            1.1.1.1;        //cloudflare
            8.8.8.8;        //google
            94.247.43.254;  //open nic
            194.36.144.87;  //open nic
            129.134.30.12;  //whatsapp
     };

    dnssec-validation auto;

    zone "lan" IN {
            type master;
            file "/etc/bind/lan.zone";

};

lan.zona:

$ TTL 2d

$ORIGIN lan.

@ EM SOA ns.lan.
mail.hotmail.com. (2023111002; serial 12h; atualizar 15m; tentar novamente 3w; expirar 2h; ttl mínimo)

                    IN      NS      ns.lan. ns                      IN      A       192.168.50.232 homeserver              IN      A      

192.168.50.11 openwrt EM UM 192.168.50.1 qbittorrent.direct EM UM 192.168.50.11 direto
EM UM 192.168.50.251 confronto EM UM
192.168.50.11 yacd.clash EM UM 192.168.50.11 *.homeserver EM UM 192 .168.50.11 esxi IN A 192.168. 50,10 extras EM A
192.168.50.232 umbrel EM A 192.168.50.232 ax3 EM A 192.168.60.1

Estamos executando o BIND 9.16.6 Red Hat v7.7. Estou procurando algumas dicas sobre a ordem da atualização e qual comando executar para desligar cada nó normalmente. Temos um mestre oculto separado e 2 escravos.

Isto é uma resposta ao CVE-2023-2828.

Estou usando o BIND 9.18 para fins de teste. Eu crio uma zona que suporta DNS dinâmico e tento usar nsupdatepara atualizar o registro de recursos do domínio. Após 15 minutos, a atualização é gravada com êxito no arquivo de zona original. No entanto, quando eu uso digpara consultar o domínio e a resposta não muda. Então eu desligo named, reinicio e uso digpara consultar o domínio novamente, e a resposta mostra a atualização. Eu tento atualizar manualmente o arquivo de zona usando rndce o resultado é o mesmo - o arquivo de zona é atualizado com sucesso, mas a atualização só fica visível digdepois que eu reinicio o bind9.

Minha dúvida é, tenho que reiniciar periodicamente o bind9 para tornar as atualizações visíveis para as consultas?

Obrigado!

Estou tentando configurar um servidor DNS para meus domínios usando o Bind. O servidor se comporta corretamente para domínios não personalizados como google.comou github.com, mas para meus domínios sempre retorna "SERVFAIL". Já verifiquei o arquivo de zona usando named-checkzoneque retorna "OK".

Configuração da minha zona (definida em named.conf.local):

zone "michlfranken" {
  type master;
  file "/var/cache/bind/db.isiko404.dev";
};

Meu arquivo de opções:

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
                80.241.218.68;
                46.182.19.48;
        };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation yes;

        listen-on-v6 { any; };
        listen-on { any; };
};

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.

1. 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]
2. 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?
3. 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.