BIND e Active Directory® - Redes de PME

Índice geral da série: Redes de computadores para PMEs: introdução

Olá amigos!. O objetivo principal deste artigo é mostrar como podemos integrar o serviço DNS baseado no BIND9 em uma rede Microsoft, muito comum em muitas PMEs.

Surge do pedido oficial de um amigo que mora em La Tierra del Fuego -O fueguino- especializada em Redes Microsoft® - Inclui certificados - para guiá-lo nesta parte da migração de seus servidores para Linux. Os custos de Suporte Os técnicos que pagam Microsoft® já estão Insuportável pela Sociedade em que trabalha e da qual é o seu Principal Acionista.

Meu amigo O fueguino tem um grande senso de humor, e desde que viu a série de três filmes «O Senhor dos Anéis»Ele foi cativado por muitos dos nomes de seus personagens sombrios. Portanto, amigo leitor, não se surpreenda com os nomes do seu domínio e dos seus servidores.

Para os iniciantes no tema, e antes de continuar lendo, recomendamos que você leia e estude os três artigos anteriores sobre Redes de PME:

• DNS e DHCP no openSUSE 13.2 "Harlequin"
• DNS e DHCP no CentOS 7
• DNS e DHCP no Debian 8 "Jessie"

É como assistir a três das quatro partes de «Submundo»Publicado até hoje, e que este é o quarto.

Parâmetros gerais

Após várias trocas via o email, finalmente eu estava claro sobre os principais parâmetros de sua rede atual, que são:

Nome de domínio mordor.fan LAN Network 10.10.10.0/24 ======================================== == ================================================ Servidores Objetivo do endereço IP (servidores com sistema operacional Windows) ===================================================== === ============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Servidor de arquivos do Windows darklord.mordor.fan. 10.10.10.6 Proxy, gateway e firewall em Kerios troll.mordor.fan. 10.10.10.7 Blog baseado em ... não me lembro de shadowftp.mordor.fan. 10.10.10.8 Servidor FTP blackelf.mordor.fan. 10.10.10.9 Serviço de e-mail completo blackspider.mordor.fan. 10.10.10.10 Serviço WWW palantir.mordor.fan. 10.10.10.11 Bate-papo no Openfire para Windows

Eu pedi permissão para O fueguino definir quantos aliases forem necessários para limpar minha mente e me deu sua permissão:

CNAME real ================================== sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

Eu declarei todos os registros DNS importantes em minha instalação de um Active Directory Windows 2008 que fui forçado a implementar para me orientar na elaboração deste post.

Sobre os registros SRV do DNS de um Active Directory

Os registros SRV o Localizadores de serviço - amplamente utilizados no Microsoft Active Directory - são definidos no Solicitação de RFC de comentários 2782. Eles permitem a localização de um serviço com base no protocolo TCP / IP por meio de uma consulta DNS. Por exemplo, um cliente em uma rede Microsoft pode localizar a localização dos controladores de domínio - Controladores de domínio que fornecem o serviço LDAP sobre o protocolo TCP na porta 389 por meio de uma única consulta DNS.

É normal que nas Florestas - florestase árvores - Árvores de uma grande rede Microsoft, existem vários controladores de domínio. Através da utilização de registros SRV nas diferentes Zonas que compõem o Espaço de Nomes de Domínio daquela Rede, podemos manter uma Lista de Servidores que prestam serviços similares e bastante conhecidos, ordenados por preferência de acordo com o protocolo de transporte e porta de cada um dos os servidores.

Em Solicitação de RFC de comentários 1700 Definindo nomes simbólicos universais para serviços conhecidos - Serviço bem conhecidoe nomes como «_telnet«,«_smtp»Para serviços telnet y SMTP. Se um nome simbólico não for definido para um serviço conhecido, um nome local ou outro nome pode ser usado de acordo com as preferências do usuário.

O objetivo de cada campo «especial»Que é usado na declaração de um Registro de Recurso SRV é o seguinte:

• Domínio: "Pdc._msdcs.mordor.fan.«. Nome DNS do serviço ao qual o registro SRV se refere. O nome DNS no exemplo significa -mais ou menos- Controlador de domínio primário da zona _msdcs.mordor.fan.
• e eficaz: "_Ldap". Nome simbólico do serviço que é prestado definido de acordo com Solicitação de RFC de comentários 1700.
• Protocolo: "_Tcp". Indica o tipo de protocolo de transporte. Normalmente, pode assumir os valores _tcp o _udp, embora -e de fato- qualquer tipo de protocolo de transporte indicado no Solicitação de RFC de comentários 1700. Por exemplo, para um serviço bate-papo baseado em protocolo XMPP, este campo teria o valor de _xmpp.
• Prioridade"0«. Declare a prioridade ou preferência para o Host que oferece este serviço que veremos mais tarde. As consultas DNS dos clientes sobre o serviço definido por este registro SRV, ao receber a resposta adequada, tentarão entrar em contato com o primeiro host disponível com o menor número listado no campo. Prioridade. O intervalo de valores que este campo pode assumir é 0 a 65535.
• Peso"100«. Pode ser usado em combinação com Prioridade para fornecer um mecanismo de balanceamento de carga quando houver vários servidores que fornecem o mesmo serviço. Deve haver um registro SRV semelhante para cada servidor no arquivo de zona, com seu nome declarado no campo Host que oferece este serviço. Antes de servidores com valores iguais no campo Prioridade, o valor do campo Peso ele pode ser usado como um nível adicional de preferência para obter uma seleção de servidor exata para balanceamento de carga. O intervalo de valores que este campo pode assumir é 0 a 65535. Se o balanceamento de carga não for necessário, por exemplo como no caso de um único servidor, é recomendado atribuir o valor 0 para tornar o registro SRV mais fácil de ler.
• Número da porta - porta"389«. Número da porta em Host que oferece este serviço que fornece o serviço indicado no campo e eficaz. O número de porta recomendado para cada tipo de serviço conhecido é indicado no Solicitação de RFC de comentários 1700, embora possa ter um valor entre 0 e 65535.
• Host que oferece este serviço - Destino"sauron.mordor.fan.«. Especifica o FQDN que identifica inequivocamente o hospedeiro que fornece o serviço indicado pelo registro SRV. Um tipo de registro «A»No namespace de domínio para cada FQDN do servidor ou hospedeiro que fornece o serviço. Mais simples, um registro de tipo A na (s) zona (s) direta (s).
  • Nota:
    Para indicar com autoridade que o serviço especificado pelo registro SRV não é fornecido neste host, um único (.) ponto.

Queremos apenas repetir que a operação correta de uma rede ou de um Active Directory® depende muito da operação correta do Serviço de Nomes de Domínio..

Registros DNS do Active Directory

Para fazer as Zonas do novo Servidor DNS baseadas em BIND, devemos obter todos os registros DNS do Active Directory®. Para facilitar a vida, vamos para a equipe sauron.mordor.fan -Active Directory® 2008 SR2- e no console de administração DNS ativamos a transferência de zona -direta e reversa- para as zonas principais declaradas neste tipo de serviço, que são:

• _msdcs.mordor.fan
• mordor.fan
• 10.10.10.in-addr.harp

Após a etapa anterior ter sido realizada, de preferência a partir de um computador Linux cujo endereço IP esteja dentro do intervalo da sub-rede usada pela Rede Windows, executamos:

buzz @ sysadmin: ~ $ dig @ 10.10.10.3 _msdcs.mordor.fan axfr> temp /rrs._msdcs.mordor.fan
buzz @ sysadmin: ~ $ dig @ 10.10.10.3 mordor.fan axfr> temp / rrs.mordor.fan
buzz @ sysadmin: ~ $ dig @ 10.10.10.3 10.10.10.in-addr.arpa axfr> temp / rrs.10.10.10.in-addr.arpa

• Lembre-se de artigos anteriores que o endereço IP do dispositivo administrador de sistema.desdelinux.ventilador es 10.10.10.1 ou 192.168.10.1.

Nos três comandos anteriores podemos eliminar a opção 10.10.10.3 -pergunte ao servidor DNS com esse endereço- se declararmos no arquivo / Etc / resolv.conf para o IP do servidor sauron.mordor.fan:

buzz@sysadmin:~$ cat /etc/resolv.conf # Gerado pela pesquisa do NetworkManager desdelinux.fan servidor de nomes 192.168.10.5 servidor de nomes 10.10.10.3

Após a edição com extremo cuidado, pois corresponde a qualquer arquivo de zona em um BIND, obteremos os seguintes dados:

Registros RRs da zona original _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; Relacionado a SOA e NS _msdcs.mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; GLOBAL CATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliases - no banco de dados LDAP particular e modificado de um Active Directory - de SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP modificado e privado de um Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificado e privado de um _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan do Active Directory. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

Registros RRs da zona original mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; Relacionado a SOA, NS, MX e ao registro A que mapeia; o Nome de Domínio para o IP da SAURON; Coisas de um mordor.fan do Active Directory. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 86400 3600 mordor.fan. 600 IN A 10.10.10.3 mordor.fan. 3600 IN NS sauron.mordor.fan. mordor.fan. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; Também importantes registros A DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; GLOBAL CATALOG _gc._tcp.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; LDAP modificado e privado de um Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificados e privados de um Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. ; ; Registros A com IPs fixos -> servidores Blackelf.mordor.fan. 3600 IN A 10.10.10.9 blackspider.mordor.fan. 3600 IN A 10.10.10.10 darklord.mordor.fan. 3600 IN A 10.10.10.6 mamba.mordor.fan. 3600 IN A 10.10.10.4 palantir.mordor.fan. 3600 IN A 10.10.10.11 sauron.mordor.fan. 3600 IN A 10.10.10.3 shadowftp.mordor.fan. 3600 IN A 10.10.10.8 troll.mordor.fan. 3600 IN A 10.10.10.7; ; Registros CNAME ad-dc.mordor.fan. 3600 IN CNAME sauron.mordor.fan. blog.mordor.fan. 3600 IN CNAME troll.mordor.fan. fileserver.mordor.fan. 3600 IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. 3600 IN CNAME shadowftp.mordor.fan. mail.mordor.fan. 3600 IN CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 IN CNAME palantir.mordor.fan. proxy.mordor.fan. 3600 IN CNAME darklord.mordor.fan. www.mordor.fan. 3600 IN CNAME blackspider.mordor.fan.

Registros RRs da zona original 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Relacionado a SOA e NS 10.10.10.in-addr.arpa. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; Registros PTR 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 IN PTR sauron.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 IN PTR mamba.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 IN PTR dnslinux.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 IN PTR darklord.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 IN PTR troll.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 9.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.

Até aqui podemos pensar que temos os dados necessários para continuar em nossa aventura, não sem antes observar o TTL e outros dados que de forma muito concisa a saída e observação direta do DNS de um Microsft® Active Directory® 2008 SR2 64 bits nos fornece.

Imagens do DNS Manager em SAURON

Equipe Dnslinux.mordor.fan.

Se olharmos de perto, para o endereço IP 10.10.10.5 nenhum nome foi atribuído a ele precisamente para que fosse ocupado pelo nome do novo DNS dnslinux.mordor.fan. Para instalar o par DNS e DHCP, podemos ser guiados pelos artigos DNS e DHCP no Debian 8 "Jessie" y DNS e DHCP no CentOS 7.

Sistema operacional básico

Meu amigo O fueguinoAlém de ser um verdadeiro especialista em Microsoft® Windows - ele possui alguns Certificados emitidos por aquela empresa - ele leu e colocou em prática alguns dos artigos sobre desktops publicados em DesdeLinux., e ele me disse que queria especificamente uma solução baseada em Debian. 😉

Para lhe agradar, começaremos com uma instalação nova e limpa de um servidor baseado em Debian 8 "Jessie". No entanto, o que escreveremos a seguir é válido para as distribuições CentOS e openSUSE cujos artigos mencionamos anteriormente. BIND e DHCP são os mesmos em qualquer distro. Pequenas variações são introduzidas pelos mantenedores do pacote em cada distribuição.

Faremos a instalação conforme indicado em DNS e DHCP no Debian 8 "Jessie", tomando cuidado para usar o IP 10.10.10.5 e a rede 10.10.10.0/24., mesmo antes de configurar o BIND.

Nós configuramos o BIND no estilo Debian

/etc/bind/named.conf

O arquivo /etc/bind/named.conf nós o deixamos como está instalado.

/etc/bind/named.conf.options

O arquivo /etc/bind/named.conf.options deve ser deixado com o seguinte conteúdo:

root @ dnslinux: ~ # cp /etc/bind/named.conf.options /etc/bind/named.conf.options.original

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
opções {diretório "/ var / cache / bind"; // Se houver um firewall entre você e os servidores de nome com os quais // deseja falar, pode ser necessário consertar o firewall para permitir // portas múltiplas para falar. Consulte http://www.kb.cert.org/vuls/id/800113 // Se seu ISP forneceu um ou mais endereços IP para servidores de // nomes estáveis, você provavelmente deseja usá-los como encaminhadores. // Remova o comentário do bloco seguinte e insira os endereços substituindo // o marcador de posição all-0. // encaminhadores {// 0.0.0.0; //}; // ===================================================== ======================= $ // Se o BIND registrar mensagens de erro sobre a expiração da chave raiz, // você precisará atualizar suas chaves. Consulte https://www.isc.org/bind-keys // ====================================== ====================================== $

    // Não queremos DNSSEC
        não habilitar dnssec;
        //validação dnssec automática;

        auth-nxdomain no; # conforme RFC1035

 // Não precisamos escutar endereços IPv6
        // ouvir na v6 {any; };
    ouvir na v6 {nenhum; };

 // Para verificações de localhost e sysadmin
    // através de // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Não temos DNS escravo ... até agora
 allow-transfer {localhost; 10.10.10.1; };
};

// Registrando BIND
exploração madeireira {

        consultas de canal {
        arquivo "/var/log/named/queries.log" versões 3 tamanho 1m;
        informação de gravidade;
        tempo de impressão sim;
        print-severity sim;
        categoria de impressão sim;
        };

        erro de consulta do canal {
        arquivo "/var/log/named/query-error.log" versões 3 tamanho 1m;
        informação de gravidade;
        tempo de impressão sim;
        print-severity sim;
        categoria de impressão sim;
        };

                                
consultas de categoria {
         consultas;
         };

erros de consulta de categoria {
         erro de consulta;
         };

};

• Apresentamos a captura dos logs do BIND como um NOVO aparição em série de artigos sobre o assunto. Nós criamos euuma pasta e arquivos necessários para o Logging do BIND:

root @ dnslinux: ~ # mkdir / var / log / named
root @ dnslinux: ~ # touch /var/log/named/queries.log
root @ dnslinux: ~ # touch /var/log/named/query-error.log
root @ dnslinux: ~ # chown -R bind: bind / var / log / named

Nós verificamos a sintaxe dos arquivos configurados

root @ dnslinux: ~ # named-checkconf 
root @ dnslinux: ~ #

/etc/bind/named.conf.local

Nós criamos o arquivo /etc/bind/zones.rfcFreeBSD com o mesmo conteúdo indicado em DNS e DHCP no Debian 8 "Jessie".

root @ dnslinux: ~ # nano /etc/bind/zones.rfcFreeBSD

O arquivo /etc/bind/named.conf.local deve ser deixado com o seguinte conteúdo:

// // Faça qualquer configuração local aqui // // Considere adicionar as zonas 1918 aqui, se elas não forem usadas em sua // organização
incluem "/etc/bind/zones.rfc1918"; incluem "/etc/bind/zones.rfcFreeBSD";

zona "mordor.fan" {tipo mestre; arquivo "/var/lib/bind/db.mordor.fan"; }; zona "10.10.10.in-addr.arpa" {tipo mestre; arquivo "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

zona "_msdcs.mordor.fan" {tipo mestre;
 os nomes de verificação ignoram; arquivo "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

Arquivo de zona mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; série 1D; atualizar 1H; repetir 1W; expirar 3H); mínimo ou; Tempo de cache negativo para viver;
; TENHA MUITO CUIDADO COM OS SEGUINTES REGISTROS
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "Bem-vindo ao The Dark Lan de Mordor";
_msdcs.mordor.fan. IN NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. IN A 10.10.10.5
; TERMINE COM MUITO CUIDADO COM OS SEGUINTES REGISTROS;
DomainDnsZones.mordor.fan. IN A 10.10.10.3 ForestDnsZones.mordor.fan. IN A 10.10.10.3; ; GLOBAL CATALOG _gc._tcp.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. ; ; LDAP modificado e privado de um Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. ; ; KERBEROS modificados e privados de um Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. ; ; Registros A com IPs fixos -> servidores Blackelf.mordor.fan. IN A 10.10.10.9 blackspider.mordor.fan. IN A 10.10.10.10 darklord.mordor.fan. IN A 10.10.10.6 mamba.mordor.fan. IN A 10.10.10.4 palantir.mordor.fan. IN A 10.10.10.11
sauron.mordor.fan. IN A 10.10.10.3
shadowftp.mordor.fan. IN A 10.10.10.8 troll.mordor.fan. IN A 10.10.10.7; ; Registros CNAME ad-dc.mordor.fan. IN CNAME sauron.mordor.fan. blog.mordor.fan. IN CNAME troll.mordor.fan. fileserver.mordor.fan. IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. IN CNAME shadowftp.mordor.fan. mail.mordor.fan. IN CNAME balckelf.mordor.fan. openfire.mordor.fan. EM CNAME palantir.mordor.fan. proxy.mordor.fan. EM CNAME darklord.mordor.fan. www.mordor.fan. IN CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zona mordor.fan/IN: serial carregado 1 OK

Os tempos TTL 600 de todos os registros SRV, nós os manteremos no caso de instalarmos um Slave BIND em algum momento. Esses registros representam os serviços do Active Directory® que leem principalmente os dados do banco de dados LDAP. Como esse banco de dados muda com frequência, os tempos de sincronização devem ser curtos, em um esquema DNS Mestre-Escravo. De acordo com a filosofia da Microsoft observada de Active Directory 2000 a 2008, o valor de 600 é mantido para esses tipos de registros SRV.

Os TTL dos servidores com IP fixo, eles estão abaixo do tempo declarado no SOA de 3 horas.

Arquivo de zona 10.10.10.in-addr.arpa

root @ dnslinux: ~ # nano /var/lib/bind/db.10.10.10.in-addr.arpa
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; série 1D; atualizar 1H; repetir 1W; expirar 3H); mínimo ou; Tempo de cache negativo para viver; @ IN NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 IN PTR palantir.mordor.fan. 3 IN PTR sauron.mordor.fan. 4 IN PTR mamba.mordor.fan. 5 IN PTR dnslinux.mordor.fan. 6 IN PTR darklord.mordor.fan. 7 IN PTR troll.mordor.fan. 8 IN PTR shadowftp.mordor.fan. 9 IN PTR blackelf.mordor.fan.

root @ dnslinux: ~ # named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
zona 10.10.10.in-addr.arpa/IN: serial carregada 1 OK

Arquivo de zona _msdcs.mordor.fan

Vamos levar em consideração o que é recomendado no arquivo /usr/share/doc/bind9/README.Debian.gz Sobre a localização dos arquivos das Zonas Master não sujeitas a atualizações dinâmicas por DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; série 1D; atualizar 1H; repetir 1W; expirar 3H); mínimo ou; Tempo de cache negativo para viver; @ IN NS dnslinux.mordor.fan. ; ; ; GLOBAL CATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliases - no banco de dados LDAP particular e modificado de um Active Directory - de SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP modificado e privado de um Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificado e privado de um _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan do Active Directory. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

Verificamos a sintaxe e podemos ignorar o erro que ela retorna, pois na configuração desta Zona no arquivo /etc/bind/named.conf.local nós incluímos a declaração os nomes de verificação ignoram;. A zona será carregada corretamente pelo BIND.

root @ dnslinux: ~ # named-checkzone _msdcs.mordor.fan /etc/bind/db._msdcs.mordor.fan 
/etc/bind/db._msdcs.mordor.fan:14: gc._msdcs.mordor.fan: nome do proprietário incorreto (nomes de verificação) zona _msdcs.mordor.fan/IN: serial carregado 1 OK

root @ dnslinux: ~ # systemctl restart bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - Servidor de nomes de domínio BIND carregado: carregado (/lib/systemd/system/bind9.service; habilitado) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Ativo: ativo (em execução) desde Sun 2017-02-12 08:48:38 EST; 2s atrás Docs: man: named (8) Processo: 859 ExecStop = / usr / sbin / rndc stop (code = exited, status = 0 / SUCCESS) PID principal: 864 (named) CGroup: /system.slice/bind9.service └─864 / usr / sbin / named -f -u bind 12 de fevereiro 08:48:38 dnslinux nomeado [864]: zona 3.efip6.arpa/IN: serial carregada 1 de fevereiro de 12 08:48:38 dnslinux nomeado [864 ]: zona befip6.arpa/IN: serial carregada em 1 de fevereiro 12:08:48 dnslinux chamado [38]: zona 864.efip0.arpa/IN: serial carregada em 6 de fevereiro de 1 12:08:48 dnslinux chamada [38]: zona 864.efip7.arpa/IN: serial carregada 6 de fevereiro 1 12:08:48 dnslinux nomeado [38]: zona mordor.fan/IN: serial carregada 864 de fevereiro 1 12:08:48 dnslinux nomeado [38]: exemplo de zona .org / IN: serial carregada 864 fev 1 12:08:48 dnslinux nomeado [38]: zona _msdcs.mordor.fan/IN: serial carregada 864 fev 1 12:08:48 dnslinux nomeado [38]: zona inválida / IN : carregado serial 864 de fevereiro 1 12:08:48 dnslinux chamado [38]: todas as zonas carregadas
12 de fevereiro 08:48:38 dnslinux chamado [864]: corrida

Consultamos o BIND

Antes Depois de instalar o DHCP, devemos realizar uma série de verificações que incluem até mesmo unir um cliente Windows 7 ao domínio mordor.fan representado pelo Active Directory instalado no computador sauron.mordor.fan.

A primeira coisa a fazer é parar o serviço DNS no computador sauron.mordor.fane declare em sua interface de rede que a partir de agora em seu servidor DNS será o 10.10.10.5 dnslinux.mordor.fan.

Em um console do próprio servidor sauron.mordor.fan nós executamos:

Microsoft Windows [Versão 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Todos os direitos reservados.

C: \ Usuários \ Administrador> nslookup
Servidor padrão: dnslinux.mordor.fan Endereço: 10.10.10.5

> gc._msdcs
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 Nome: gc._msdcs.mordor.fan Endereço: 10.10.10.3

> mordor.fan
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 Nome: mordor.fan Endereço: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 Nome: sauron.mordor.fan Endereço: 10.10.10.3 Aliases: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> definir tipo = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan SRV local serv ice: priority = 0 weight = 100 port = 88 svr hostname = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan endereço de internet = 10.10.10.3 dnslinux.mordor.fan endereço de internet = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan Local do serviço SRV: prioridade = 0 peso = 100 porta = 389 svr hostname = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan endereço de internet = 10.10.10.3 dnslinux.mordor.fan endereço de internet = 10.10.10.5
> sair

C: \ Usuários \ Administrador>

Consultas DNS feitas de sauron.mordor.fan são satisfatórios.

A próxima etapa será criar outra máquina virtual com o Windows 7 instalado. Como ainda não temos o serviço DHCP instalado, daremos ao computador o nome «win7»O endereço IP 10.10.10.251. Também declaramos que seu servidor DNS será o 10.10.10.5 dnslinux.mordor.fan, e que o domínio de pesquisa será mordor.fan. Não registraremos esse computador no DNS porque também o usaremos para testar o serviço DHCP depois de instalá-lo.

Em seguida, abrimos um console CMD e nele executamos:

Microsoft Windows [Versão 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Todos os direitos reservados.

C: \ Usuários \ buzz> nslookup
Servidor padrão: dnslinux.mordor.fan Endereço: 10.10.10.5

> mordor.fan
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 Nome: mordor.fan Endereço: 10.10.10.3

> definir tipo = SRV
> _ldap._tcp.DomainDnsZones
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan Local do serviço SRV: prioridade = 0 peso = 0 porta = 389 svr hostname = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor endereço de internet .fan sauron.mordor.fan = 10.10.10.3 dnslinux.mordor.fan endereço de internet = 10.10.10.5
> _kpasswd._udp
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 _kpasswd._udp.mordor.fan Local do serviço SRV: prioridade = 0 peso = 0 porta = 464 svr hostname = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan endereço de internet sauron.mordor.fan = 10.10.10.3 dnslinux.mordor.fan endereço de internet = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Servidor: dnslinux.mordor.fan Endereço: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan Local do serviço SRV: prioridade = 0 peso = 0 porta = 389 svr hostname = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan endereço de internet = 10.10.10.3 dnslinux.mordor.fan endereço de internet = 10.10.10.5
> saída

C: \ Usuários \ buzz>

Consultas DNS feitas a partir do cliente «win7»Também foram satisfatórios.

No Active Directory, criamos o usuário «Saruman«, Com o objectivo de o utilizar na adesão ao cliente win7 para o domínio mordor.fan., usando o método «ID da rede«, Usando nomes de usuário saruman@mordor.fan y administrador@mordor.fan. A associação foi bem-sucedida e é comprovada pela seguinte captura de tela:

Sobre atualizações dinâmicas no Microsoft® DNS e BIND

Como temos o serviço DNS parado no Active Directory® não foi possível para o cliente «win7»Registre seu nome e endereço IP nesse DNS. Muito menos em dnslinux.mordor.fan já que não fizemos nenhuma declaração permitir atualização para qualquer uma das áreas envolvidas.

E foi aqui que se formou a boa luta com meu amigo O fueguino. No meu primeiro email sobre este aspecto comentei:

• Em artigos da Microsoft sobre o uso de BIND e Active Directory®, eles recomendam que, especialmente a Direct Zone, seja permitida a atualização -penetrado- diretamente por clientes Windows que já estão associados ao domínio do Active Directory.
• É por isso que, por padrão, nas zonas DNS de um Active Directory® Secure Dynamic Updates são permitidos. por clientes Windows já ingressados ​​no domínio do Active Directory. Se não estiverem unidos, eles se abstêm das consequências.
• O DNS de um Active Directory oferece suporte a atualizações dinâmicas "Apenas seguro", "Não seguro e seguro" ou "Nenhum", o que equivale a dizer SEM atualizações ou Nenhuma.
• Sim de verdade a Filosofia da Microsoft não concorda que seus clientes NÃO atualizarão seus dados em seus DNS (s), ela não deixaria aberta a possibilidade de desabilitar atualizações dinâmicas em seus DNS (s), a menos que essa opção seja deixada para fins mais ocultos.
• A Microsoft oferece "Segurança" em troca de Darkness, como me disse um colega e amigo que passou nos cursos de Certificados Microsft®. Verdade. Além disso, El Fueguino me confirmou.
• Um cliente que adquire um endereço IP através de DHCP instalado em uma máquina UNIX® / Linux, por exemplo, não será capaz de resolver o endereço IP de seu próprio nome até que você se junte ao domínio do Active Directory, desde que Microsoft® ou um BIND seja usado como DNS sem atualizações dinâmicas por DHCP.
• Se eu instalar o DHCP no próprio Active Directory®, devo declarar que as Zonas são atualizadas pelo DHCP da Microsoft®.
• Se vamos utilizar o BIND como DNS para a rede Windows, é lógico e recomendável instalarmos o duo BIND-DHCP, com este atualizando dinamicamente o BIND e o assunto concluído.
• No mundo das redes LAN em UNIX® / Linux, uma vez que as atualizações dinâmicas foram inventadas no BIND, apenas o Sr. DHCP é permitido «entrar»À Sra. BIND com suas atualizações. O relaxamento que fica com ordem, por favor.
• Quando eu declaro na zona mordor.fan por exemplo: allow-update {10.10.10.0/24; };, O próprio BIND me informa ao iniciá-lo ou reiniciá-lo que:

  • zona 'mordor.fan' permite atualizações por endereço IP, que é inseguro

• No sacrossanto mundo UNIX® / Linux, tão atrevido com DNS é simplesmente inadmissível.

Você pode imaginar o resto da troca com meu amigo O fueguino através e-mails, Chat de telegrama, telefonemas pagos por ele (claro cara, não tenho quilo pra isso), e até recados de pombos-correios do século XXI!

Ele até ameaçou não me mandar um filho de seu animal de estimação, seu Iguana «Petra»Que ele havia me prometido como parte do pagamento. Lá eu estava realmente assustado. Então comecei de novo, mas de outro ângulo.

• O "quase" Active Directory que pode ser alcançado com o Samba 4, resolve este aspecto de forma magistral, tanto quando usamos seu DNS interno, ou o BIND compilado para suportar zonas DLZ - Zonas Dinamyc Loadedou zonas carregadas dinamicamente.
• Continua a sofrer do mesmo: quando um cliente adquire um endereço IP através de um DHCP instalado em outro Máquina UNIX® / Linux, você não será capaz de resolver o endereço IP do seu próprio nome até que seja adicionado ao domínio do Samba 4 AD-DC.
• Integre o BIND-DLZ e o DHCP duo na mesma máquina onde o AD DC Samba 4 é um trabalho para um verdadeiro especialista.

O fueguino Ele me chamou para o capítulo e gritou comigo: NÃO estamos falando sobre AD DC Samba 4, mas o Microsoft® Active Directory®!. E eu humildemente respondi que estava encantado com parte dos seguintes artigos que iria escrever.

Foi quando eu disse a ele que a decisão final sobre atualizações dinâmicas para computadores clientes em sua rede foi deixada por sua própria vontade. Que eu só daria a ele o tipo escrito antes sobre allow-update {10.10.10.0/24; };, e mais nada. Que não fui responsável pelo que resultou daquela promiscuidade que cada cliente Windows -ou Linux- na sua rede «vai penetrar»Com impunidade ao BIND.

Se você soubesse, meu amigo, leitor, que esse era o ponto final da briga, não acreditaria. Meu amigo O fueguino ele aceitou a solução - e ele vai me enviar a iguana «Pete«- que agora eu compartilho com você.

Nós instalamos e configuramos DHCP

Para mais detalhes leia DNS e DHCP no Debian 8 "Jessie".

root @ dnslinux: ~ # aptitude install isc-dhcp-server

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # Em quais interfaces o servidor DHCP (dhcpd) deve atender às solicitações DHCP? # Separe várias interfaces com espaços, por exemplo, "eth0 eth1". INTERFACES = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n USER dhcp-key
Tecla Kdhcp. +157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key. +157 + 29836.private
Formato de chave privada: v1.3 Algoritmo: 157 (HMAC_MD5) Chave: 3HT / bg / 6YwezUShKYofj5g == Bits: AAA = Criado: 20170212205030 Publicar: 20170212205030 Ativar: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
chave dhcp-chave {algoritmo hmac-md5; segredo "3HT / bg / 6YwezUShKYofj5g =="; };

root @ dnslinux: ~ # install -o root -g bind -m 0640 dhcp.key /etc/bind/dhcp.key
root @ dnslinux: ~ # install -o root -g root -m 0640 dhcp.key /etc/dhcp/dhcp.key

root @ dnslinux: ~ # nano /etc/bind/named.conf.local
// // Faça qualquer configuração local aqui // // Considere adicionar as zonas 1918 aqui, se elas não forem usadas em sua // organização, inclua "/etc/bind/zones.rfc1918"; incluem "/etc/bind/zones.rfcFreeBSD";
// Não se esqueça ... esqueci e paguei com erros. ;-)
incluem "/etc/bind/dhcp.key";


zona "mordor.fan" {tipo mestre;
        allow-update {10.10.10.3; chave dhcp-key; };
        arquivo "/var/lib/bind/db.mordor.fan"; }; zona "10.10.10.in-addr.arpa" {tipo mestre;
        allow-update {10.10.10.3; chave dhcp-key; };
        arquivo "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; zona "_msdcs.mordor.fan" {tipo mestre; os nomes de verificação ignoram; arquivo "/etc/bind/db._msdcs.mordor.fan"; };

root @ dnslinux: ~ # named-checkconf 
root @ dnslinux: ~ #

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
provisório ddns-update-style; ddns-updates on; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignorar atualizações do cliente; autoritário; opção ip-forwarding off; opção nome de domínio "mordor.fan"; incluem "/etc/dhcp/dhcp.key"; zone mordor.fan. {127.0.0.1 primário; chave dhcp-key; } zona 10.10.10.in-addr.arpa. {127.0.0.1 primário; chave dhcp-key; } redlocal de rede compartilhada {sub-rede 10.10.10.0 máscara de rede 255.255.255.0 {roteadores de opção 10.10.10.1; opção máscara de sub-rede 255.255.255.0; opção de endereço de transmissão 10.10.10.255; opção servidores de nomes de domínio 10.10.10.5; opção netbios-name-servers 10.10.10.5; intervalo 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

root @ dnslinux: ~ # dhcpd -t
Servidor DHCP do Internet Systems Consortium 4.3.1 Copyright 2004-2014 Internet Systems Consortium. Todos os direitos reservados. Para obter informações, visite https://www.isc.org/software/dhcp/ Arquivo de configuração: /etc/dhcp/dhcpd.conf Arquivo de banco de dados: /var/lib/dhcp/dhcpd.leases Arquivo PID: / var / run /dhcpd.pid

root @ dnslinux: ~ # systemctl restart bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 

root @ dnslinux: ~ # systemctl start isc-dhcp-server.service
root @ dnslinux: ~ # systemctl status isc-dhcp-server.service

O que está relacionado a Verifica com clientesE o Modificação manual de arquivos de zona, deixamos para você, amigo leitor, ler diretamente do DNS e DHCP no Debian 8 "Jessie"e aplique-o às suas condições reais. Realizamos todas as verificações necessárias e obtivemos resultados satisfatórios. Claro que enviamos uma cópia de todos eles para O fueguino. Não haverá mais!

dicas

geral

• Tenha muita paciência antes de começar.
  
• Primeiro instale e configure o BIND. Verifique tudo e veja todos os registros que você declarou em cada arquivo nas três ou mais zonas, tanto do Active Directory quanto do próprio servidor DNS no Linux. Se possível, em uma máquina Linux que não esteja associada ao domínio, faça as consultas DNS necessárias ao BIND.
  
• Junte-se a um cliente Windows com um endereço IP fixo para o domínio existente e verifique novamente todas as configurações BIND do cliente Windows.
• Depois de ter certeza absoluta de que a configuração do seu novo BIND está totalmente correta, arrisque-se a instalar, configurar e iniciar o serviço DHCP.
• Em caso de erros, repita todo o procedimento a partir de zero 0.
• Tenha cuidado ao copiar e colar! e os espaços restantes em cada linha dos arquivos named.conf.xxxx
  
• Posteriormente, ele não se queixou - muito menos ao meu amigo o fueguino - de não ter sido devidamente aconselhado.

Outras dicas

• Dividir e conquistar.
• Em uma rede de PME, é mais seguro e mais benéfico instalar um BIND autorizado para as zonas de LAN internas que não recorrem a nenhum servidor raiz: recursão não;.
• Em uma rede de PME localizada em um provedor de acesso à Internet - ISP, talvez os serviços procuração y SMTP eles precisam resolver nomes de domínio na Internet. o Lula você tem a opção de declarar seu DNS externo ou não, enquanto em um servidor de e-mail baseado em Postfix o MDaemon® Também podemos declarar os servidores DNS que usaremos nesse serviço. Em casos como este, ou seja, casos que não prestam serviços à Internet e que estão sob um Provedor de Serviços de Internet, você pode instalar um BIND com Despachantes apontando para o DNS do ISP, e declará-lo como DNS secundário nos servidores que precisam resolver consultas externas à LAN, caso contrário é possível declará-las através de seus próprios arquivos de configuração.
• Se você tem uma Zona Delegada sob sua inteira responsabilidadeEm seguida, outro galo cantou:
  • Instale um servidor DNS baseado em NSD, que é um servidor DNS com autoridade por definição, que responde a consultas de computadores na Internet. Para algumas informações programa de aptidão nsd. 😉 Por favor, proteja-o muito bem com tantas paredes corta-fogo quantas forem necessárias. Hardware e software. Será um DNS para a Internet, e que «Tsar»Não devemos dá-lo com calças baixas. 😉
  • Como nunca me vi em um caso como este, ou seja, o responsável por uma Zona Delegada, teria que pensar muito bem o que recomendar para a resolução de nomes de domínio externos à nossa LAN para os serviços que dela necessitam . Os clientes da SME Network não precisam disso. Consulte a literatura especializada, ou um especialista nestes assuntos, pois estou longe de ser um deles. A sério.
  • A recursão não existe em servidores autoritários. OK?. Caso alguém o faça com um BIND.
• Embora especificemos explicitamente no arquivo /etc/dhcp/dhcpd.conf a declaração ignorar atualizações do cliente;, se executarmos em um console de computador dnslinux.mordor.fan a ordem jornalctl -f, veremos que ao iniciar o cliente win7.mordor.fan recebemos as seguintes mensagens de erro:

  • 12 de fevereiro 16:55:41 dnslinux chamado [900]: cliente 10.10.10.30 # 58762: atualização 'mordor.fan/IN' negada
    12 de fevereiro 16:55:42 dnslinux chamado [900]: cliente 10.10.10.30 # 49763: atualização 'mordor.fan/IN' negada
    12 de fevereiro 16:56:23 dnslinux chamado [900]: cliente 10.10.10.30 # 63161: atualização 'mordor.fan/IN' negada
    

  • Para eliminar essas mensagens, devemos ir às opções avançadas de configuração da placa de rede e desmarcar a opção «Registre os endereços desta conexão no DNS«. Isso evitará que o cliente tente se auto-registrar no DNS do Linux para sempre e o problema será resolvido. Desculpe, mas não tenho uma cópia do Windows 7 em espanhol. 😉
• Para saber mais sobre todas as consultas sérias - e malucas - que um cliente Windows 7 faz, confira o log de consultas.log que para algo nós declaramos na configuração BIND. O pedido seria:

  • root @ dnslinux: ~ # tail -f /var/log/named/queries.log

• Se você não permite que os computadores clientes se conectem diretamente à Internet, por que precisam dos servidores DNS raiz? Isso diminuirá significativamente a saída do comando jornalctl -f e do anterior, se o seu servidor DNS Autoritário para as Zonas Internas não se conecta diretamente à Internet, o que é altamente recomendável do ponto de vista da segurança.

  root @ dnslinux: ~ # cp /etc/bind/db.root /etc/bind/db.root.original
  root @ dnslinux: ~ # cp / dev / null /etc/bind/db.root

• Se você não precisa da declaração dos servidores raiz, então por que você precisa da recursão - Recursão?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  opções {
   ....
   recursão não;
   ....
  };

Conselhos específicos dos quais ainda não estou muito claro

El mandhcpd.conf diz-nos o seguinte, entre muitas -muitas- outras coisas:

        A declaração de otimização de atualização

            sinalizador de otimização de atualização;

            Se o parâmetro de otimização de atualização for falso para um determinado cliente, o servidor tentará uma atualização de DNS para aquele cliente cada vez que o cliente renovar sua concessão, em vez de apenas tentar uma atualização quando parecer necessário. Isso permitirá que o DNS se recupere das inconsistências do banco de dados mais facilmente, mas o custo é que o servidor DHCP deve fazer muito mais atualizações de DNS. Recomendamos ler esta opção habilitada, que é o padrão. Esta opção afeta apenas o comportamento do esquema de atualização de DNS provisório e não tem efeito no esquema de atualização de DNS ad-hoc. Se este parâmetro não for especificado ou for verdadeiro, o servidor DHCP será atualizado apenas quando as informações do cliente forem alteradas, o cliente obtiver uma concessão diferente ou a concessão do cliente expirar.

A tradução ou interpretação mais ou menos exata é deixada para você, caro leitor.

Pessoalmente, aconteceu comigo - e aconteceu durante a elaboração deste artigo - que quando eu vinculo um BIND a um Active Directory®, ele é de Microsft® ou Samba 4, se eu mudar o nome de um computador cliente registrado em o domínio Active Directory® ou de AD–DC do Samba 4, ele mantém seu antigo nome e endereço IP na Direct Zone, e não o contrário, que é atualizado corretamente com o novo nome. Em outras palavras, os nomes antigos e novos são mapeados para o mesmo endereço IP na Zona Direta, enquanto no reverso apenas o novo nome aparece. Para me entender bem, você deve tentar você mesmo.

Eu acho que é uma espécie de vingança contra O fueguino -não para mim, por favor- por tentar migrar seus serviços para o Linux.

É claro que o nome antigo desaparecerá quando seu TTL 3600, ou a hora que declaramos na configuração DHCP. Mas queremos que desapareça imediatamente, como acontece em um BIND + DHCP sem um Active Directory por meio.

A solução para essa situação eu encontrei inserindo a declaração otimização de atualização falsa; no final do topo do arquivo /etc/dhcp/dhcpd.conf:

provisório ddns-update-style; ddns-updates on; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignorar atualizações do cliente;
otimização de atualização falsa;

Se algum leitor souber mais sobre isso, por favor me esclareça. Eu aprecio muito isso.

Resumo

A gente tem nos divertido muito com o assunto, né? Sem sofrimento porque temos um BIND funcionando como servidor DNS em uma rede Microsoft®, oferecendo todos os registros SRV e respondendo de forma adequada às consultas DNS feitas a eles. Por outro lado, temos um servidor DHCP que concede endereços IP e atualiza de forma dinâmica as zonas BIND corretamente.

Mas não podemos pedir ... no momento.

Espero meu amigo O fueguino Fique feliz e satisfeito com a primeira etapa de sua migração para o Linux para tornar os custos insuportáveis ​​do Suporte Técnico Microsft® suportáveis.

Nota importante

O personagem "O fueguino»É totalmente fictício e produto da minha imaginação. Qualquer semelhança ou coincidência com pessoas reais é a mesma: Pura Coincidência Involuntária da minha parte. Eu apenas o criei para tornar a escrita e leitura deste artigo um pouco agradável. Agora, se você puder me dizer que o problema de DNS está escuro.