Dns fx options

Configuração de DNS e arquivos de dados Além do daemon in. name, o DNS em um servidor de nomes consiste em um arquivo de inicialização chamado named. conf. um arquivo de resolução chamado resolv. conf. e quatro tipos de arquivos de dados de zona. Nomes de arquivos de dados DNS Desde que você seja internamente consistente, você pode nomear os arquivos de dados da zona como quiser. Essa flexibilidade pode causar confusão quando se trabalha em sites diferentes ou se refere a diferentes manuais e livros de DNS. Por exemplo, os nomes de arquivo usados ​​nos manuais da Sun e no máximo muitos sites do Solaris variam daqueles usados ​​no livro DNS e BIND por Albitz e Liu, OReilly amp Associates, 1992, e ambas as nomenclaturas têm algumas diferenças em relação às usadas no site. Guia de Operações do Servidor de Nomes de domínio público para BIND. Universidade da Califórnia. Além disso, este manual e outra documentação do DNS usam nomes genéricos que identificam um propósito principal de arquivos e nomes de exemplo específicos para esse arquivo em amostras de registro de código. Por exemplo, os manuais de Solaris Naming usam os hosts de nome genéricos ao descrever a função e a função desse arquivo e os nomes de exemplo db. doc e db. sales. doc nos exemplos de código. Para fins de referência, a Tabela 28-2 compara nomes de arquivos BIND dessas três fontes: Tabela 28-2 Exemplos de nome de arquivo BIND O arquivo named. conf O BIND 8.1 adiciona um novo arquivo de configuração, /etc/named. conf. que substitui o arquivo /etc/named. boot. O arquivo /etc/named. conf estabelece o servidor como um servidor de nomes primário, secundário ou somente de cache. Também especifica as zonas nas quais o servidor tem autoridade e quais arquivos de dados ele deve ler para obter seus dados iniciais. O arquivo /etc/named. conf contém instruções que implementam: Segurança por meio de uma Lista de Controle de Acesso (ACL) que define uma coleção de endereços IP que um host NIS possui acesso de leitura / gravação. Opções aplicadas seletivamente para um conjunto de zonas, em vez de para todas as zonas. O arquivo de configuração é lido por in. named quando o daemon é iniciado pelo script de inicialização dos servidores, /etc/init. d/inetsvc. O arquivo de configuração direciona in. named para outros servidores ou para arquivos de dados locais para um domínio especificado.) Instruções named. conf O arquivo named. conf contém instruções e comentários. As declarações terminam com um ponto e vírgula. Algumas instruções podem conter um bloco de instruções. Novamente, cada declaração no bloco é terminada com um ponto e vírgula. O arquivo named. conf suporta as seguintes instruções: Tabela 28-3 named. conf Declarações Define uma lista de correspondência de endereço IP nomeada usada para controle de acesso. A lista de correspondência de endereços designa um ou mais endereços IP (notação decimal com pontos) ou prefixos IP (notação decimal pontuada seguida por uma barra e o número de bits na máscara de rede). A lista de correspondência de endereço IP nomeada deve ser definida por uma instrução acl antes de poder ser usada em qualquer outro local, sem a permissão de referências futuras. Insere um arquivo de inclusão no ponto em que a instrução include é encontrada. Use include para dividir a configuração em partes mais facilmente gerenciadas. Especifica um ID de chave usado para autenticação e autorização em um determinado servidor de nomes. Veja a declaração do servidor. Especifica as informações que o servidor registra e o destino das mensagens de log. Controla as opções de configuração do servidor global e define valores padrão para outras instruções. Define opções de configuração designadas associadas a um servidor de nomes remoto. Aplica seletivamente opções em uma base por servidor, em vez de para todos os servidores. Define uma zona. Aplica seletivamente opções em uma base por zona, em vez de todas as zonas. Exemplo 28-1 Exemplo de Arquivo de Configuração Principal para uma Migração de Servidor Principal do BIND 4.9.x para BIND 8.1.x Torne-se superusuário e execute o script de shell Korn, / usr / bin / named-bootconf. para converter um arquivo BIND 4.9.x named. boot para um arquivo BIND 8.1.x named. conf. Veja named-bootconf (1M). No Solaris 7, o named. boot é ignorado. O arquivo named. ca O arquivo named. ca estabelece os nomes dos servidores raiz e lista seus endereços. Se a sua rede estiver conectada à Internet, o named. ca listará os servidores de nomes da Internet de outra forma, ele listará os servidores de nomes de domínio raiz da sua rede local. O daemon in. named percorre a lista de servidores até entrar em contato com um deles. Em seguida, obtém desse servidor a lista atual de servidores raiz, que ele usa para atualizar named. ca. O arquivo hosts O arquivo hosts contém todos os dados sobre as máquinas na zona local. O nome desse arquivo é especificado no arquivo de inicialização. Para evitar confusão com / etc / hosts. nomeie o arquivo como algo diferente de hosts. por exemplo, você poderia nomear esses arquivos usando o padrão db. domínio. Usando essa nomenclatura, os arquivos host dos domínios doc e sales. doc podem ser db. doc e db. sales. O arquivo hosts. rev O arquivo hosts. rev especifica uma zona no in-addr. arpa. domínio, o domínio especial que permite o mapeamento reverso (endereço-para-nome). O nome desse arquivo é especificado no arquivo de inicialização. O arquivo named. local O arquivo named. local especifica o endereço da interface de loopback local, ou localhost, com o endereço de rede 127.0.0.1. O nome desse arquivo é especificado no arquivo de inicialização. Como outros arquivos, você pode dar um nome diferente do nome usado neste manual. INCLUDE Files Um arquivo de inclusão é qualquer arquivo chamado em uma instrução INCLUDE () em um arquivo de dados DNS. Os arquivos INCLUDE podem ser usados ​​para separar diferentes tipos de dados em vários arquivos para sua conveniência. Por exemplo, suponha que um arquivo de dados contenha a seguinte linha: Essa linha faz com que o arquivo / etc / named / data / mailboxes seja carregado nesse ponto. Neste exemplo, / etc / named / data / mailboxes é um arquivo INCLUDE. O uso de arquivos INCLUDE é opcional. Você pode usar quantas quiser ou nenhuma. Anterior Como o DNS afeta a entrega de email? Formato de registro de recurso de arquivo de dadosCapítulo 13 Configuração de servidores DNS Configuração de servidores DNS O uso mais comum do DNS é conectar sua rede à Internet global. Para se conectar à Internet, seu endereço IP de rede deve estar registrado com quem está administrando seu domínio pai. Quem é esse administrador varia de acordo com sua localização geográfica e tipo de domínio pai. Este manual não descreve como registrar redes com administradores de domínio. Configuração do Servidor e Nomes dos Arquivos de Dados Para funcionar corretamente, o daemon named. name requer um arquivo de configuração e quatro arquivos de dados. Os endereços IP e números de rede usados ​​nos exemplos e amostras de código neste manual são apenas para fins ilustrativos. Não os use como mostrado, porque eles podem ter sido atribuídos a uma rede ou host real. Arquivo de Configuração O arquivo de configuração do servidor master é /etc/named. conf. (Consulte o arquivo named. conf.) O arquivo de configuração contém uma lista de nomes de domínio e os nomes dos arquivos que contêm informações do host. (Consulte o Guia de Administração de Nomeação do Solaris para obter informações adicionais sobre o arquivo named. conf.) Nomes de arquivos de dados do DNS Desde que você esteja internamente consistente, é possível nomear os arquivos de dados da zona como desejar. Essa flexibilidade pode causar confusão quando se trabalha em sites diferentes ou se refere a diferentes manuais e livros de DNS. Por exemplo, os nomes de arquivo usados ​​nos manuais da Sun e no máximo muitos sites do Solaris variam daqueles usados ​​no livro DNS e BIND por Albitz e Liu, OReilly amp Associates, 1992, e ambas as nomenclaturas têm algumas diferenças em relação às usadas no site. Guia de Operações do Servidor de Nomes de domínio público para BIND. Universidade da Califórnia. Além disso, este manual e outra documentação do DNS usam nomes genéricos que identificam uma finalidade principal de arquivos e nomes de exemplo específicos para esse arquivo em amostras de código. Por exemplo, os manuais de Solaris Naming usam os hosts de nome genéricos ao descrever a função e a função desse arquivo e os nomes de exemplo db. doc e db. sales em amostras de código. Para fins de referência, a Tabela 13-1 compara nomes de arquivos BIND dessas três origens: Tabela 13-1 Exemplos de nome de arquivo Arquivos de dados Os arquivos de dados necessários são: /var/named/named. ca. (Consulte Configurando o Arquivo named. ca e o Guia de Administração de Nomeação do Solaris para obter informações adicionais sobre o arquivo named. ca.) ​​Desde que você esteja internamente consistente, é possível nomear esse arquivo como desejar. O nome hosts é um nome genérico que indica a finalidade e o conteúdo dos arquivos. Mas para evitar confusão com / etc / hosts. você deve nomear esse arquivo com algo diferente de hosts. A convenção de nomenclatura mais comum é db. nome do domínio. Assim, o arquivo hosts para o domínio doc seria chamado db. doc. Se você tiver mais de uma zona, cada zona deverá ter seu próprio arquivo de hosts e cada um desses arquivos de hosts de zona deverá ter um nome exclusivo. Por exemplo, se o seu domínio DNS estiver dividido em zonas doc e sales. doc, você poderá nomear um arquivo hosts db. doc e o outro db. sales. O nome hosts. rev é um nome genérico que indica a finalidade e o conteúdo dos arquivos. Se você tiver mais de uma zona, cada zona deverá ter seu próprio arquivo hosts. rev e cada um desses arquivos hosts. rev da zona deverá ter um nome exclusivo. Por exemplo, se o seu domínio DNS estiver dividido em zonas doc e sales. doc, você poderá nomear um arquivo host. rev doc. rev e o outro sales. rev. /var/named/named. local. Consulte Configurando o Arquivo named. local e o Guia de Administração de Nomeação do Solaris para obter informações adicionais sobre o arquivo named. local.) Desde que você esteja internamente consistente, é possível nomear esse arquivo como desejar. INCLUDE Files Um arquivo de inclusão é qualquer arquivo nomeado em uma instrução INCLUDE () em um arquivo de dados DNS. Os arquivos INCLUDE podem ser usados ​​para separar diferentes tipos de dados em vários arquivos para sua conveniência. (Consulte Guia de Administração de Nomeação do Solaris para obter detalhes adicionais.) Nomes de Domínio Um nome de domínio é o nome atribuído a um grupo de sistemas em uma rede local que compartilham arquivos administrativos DNS. Um nome de domínio é necessário para o banco de dados do serviço de informações da rede funcionar corretamente. Nome de Domínio Padrão O DNS obtém seu nome de domínio padrão do seu arquivo resolv. conf. Se o arquivo resolv. conf não estiver disponível, ou não identificar um domínio padrão, e se o serviço de nomes no nível corporativo for NIS ou NIS, a implementação da Sun no DNS obterá o nome de domínio padrão desses serviços. Se o resolv. conf não estiver disponível ou não fornecer um nome de domínio e você não estiver executando NIS ou NIS, deverá fornecer um arquivo resolv. conf em cada máquina que especificar o domínio (consulte o Resolvedor) ou definir o Variável de ambiente LOCALDOMAIN. Pontos à direita em nomes de domínio Ao trabalhar com arquivos relacionados ao DNS, siga estas regras referentes ao ponto à direita em nomes de domínio: Use um ponto à direita em nomes de domínio em hosts. hosts. rev. named. ca. e arquivos de dados nomeados. Por exemplo, sales. doc. está correto para esses arquivos. Não use um ponto final em nomes de domínio nos arquivos named. boot ou resolv. conf. Por exemplo, sales. doc está correto para esses arquivos. Arquivo resolv. conf A discussão a seguir descreve como configurar o arquivo resolv. conf. Como configurar o arquivo resolv. conf Um exemplo simples de arquivo resolv. conf para um servidor no domínio doc é mostrado abaixo: Exemplo 13-1 Exemplo de arquivo resolv. conf para servidor DNS A migração de arquivo named. conf do BIND 4.9.x para BIND 8.1 Torne-se superusuário e execute o script de shell Korn, / usr / sbin / named-bootconf. para converter um arquivo BIND 4.9.x named. boot em um arquivo BIND 8.1 named. conf. Veja named-bootconf (1M). Os arquivos named. boot e named. conf não podem coexistir no mesmo servidor. Especificando a Função do Servidor Os servidores DNS executam uma ou mais funções: Servidor mestre primário da zona. Cada zona tem um servidor designado como o servidor principal primário para essa zona. Um servidor principal primário de zonas é o servidor autoritativo para essa zona. (Consulte Especificando um servidor mestre primário.) Servidor mestre secundário da zona. Uma zona pode ter um ou mais servidores mestres secundários. Os servidores mestres secundários obtêm seu DNS do servidor principal primário da zona. Você não modifica arquivos de dados em um servidor secundário que modifica os arquivos de dados no servidor primário de zonas e os servidores secundários atualizam seus arquivos do primário. (Consulte Especificando um servidor mestre secundário.) Servidor somente de cache. Todos os servidores estão armazenando servidores em cache, no sentido de que todos eles mantêm um cache de dados DNS. Um servidor somente de armazenamento em cache é um servidor que não é um servidor mestre para nenhuma outra zona além do in-addr. arpa. domínio. (Consulte Especificando um servidor somente de cache.) Servidores de domínio raiz. Se a sua rede estiver conectada à Internet, os servidores de domínio raiz estarão na própria Internet e tudo o que você precisa fazer é fornecer os endereços IP da Internet no arquivo named. ca, conforme explicado em Configurando o arquivo named. ca. Se a sua rede não estiver conectada à Internet, você deverá configurar seu próprio servidor de domínio raiz, conforme explicado em Configurando um mestre raiz não-Internet. Essas várias funções do servidor podem ser executadas pela mesma máquina. Por exemplo, uma máquina pode ser um servidor mestre primário para uma zona e um servidor mestre secundário para outra zona. Quando este manual se refere a um servidor primário, secundário ou somente de armazenamento em cache, ele não está se referindo a uma máquina específica, mas à função que a máquina desempenha para uma determinada zona. Consulte o Guia de Administração de Nomeação do Solaris para obter informações adicionais sobre essas diferentes funções do servidor. Especificando um Servidor Principal Principal Para especificar um servidor como o servidor principal para uma determinada zona, crie três registros primários nesse servidor chamado arquivo. boot: Crie o registro primário para a zona. Esse registro designa o servidor como um servidor primário para a zona e informa ao servidor onde encontrar o arquivo de hosts autoritativos. Um registro primário possui três campos: O primeiro campo designa o servidor como principal. O segundo campo identifica a zona que serve. O terceiro campo identifica o arquivo de hosts. Por exemplo, a seguinte linha em um arquivo de inicialização especifica que o servidor é o principal para a zona de documentos, usando dados autoritativos do arquivo db. doc: Crie um registro primário para o mapa inverso de zonas. Esse registro designa o servidor como um servidor primário para o mapa de endereço reverso de zonas (ou seja, o domínio de endereço reverso para doc) e informa ao servidor onde encontrar o arquivo de hosts autoritativos. Esse registro tem três campos, o primeiro campo designa o servidor como primário, o segundo campo identifica a zona e o terceiro campo identifica o arquivo hosts. rev. O domínio de endereço reverso de uma zona contém o endereço IP das regiões na ordem inversa, seguido por in-addr. arpa. Por exemplo, suponha que o endereço IP das zonas do documento seja 123.45.6. Nesse caso, o domínio de endereço reverso seria 6.45.123.in-addr. arpa. Assim, a seguinte linha em um arquivo de inicialização especifica que o servidor é o servidor primário para o domínio de endereço reverso da zona de documento, usando dados autoritativos do arquivo doc. rev. Crie um registro primário para o endereço reverso da interface ou host de loopback local. Esse registro designa o servidor como um servidor primário para o host de loopback e informa ao servidor onde encontrar o arquivo de hosts autoritativos. Esse registro tem três campos, o primeiro campo designa o servidor como primário, o segundo campo identifica o endereço reverso do host de loopback e o terceiro campo identifica o arquivo de hosts. Os hosts de loopback sempre são identificados como 0.0.127.in-addr. arpa. Assim, a seguinte linha em um arquivo de inicialização especifica que o servidor é o servidor primário para o domínio de endereço reverso do host de loopback usando dados autoritativos do arquivo named. local. Especificando um servidor mestre secundário Para especificar que um servidor deve ser o servidor secundário para uma determinada zona, crie registros secundários nesse servidor chamado arquivo. boot. Registros separados podem designar o servidor como um servidor secundário para a zona, o domínio de endereço reverso de zonas e o host de loopback. Um registro secundário possui três campos obrigatórios: O primeiro campo designa o servidor como secundário. O segundo campo identifica a zona que serve. O terceiro campo identifica o endereço IP do servidor primário para a zona da qual o servidor secundário obtém seus dados autoritativos. Um registro secundário pode ter um ou mais campos opcionais após os campos obrigatórios. Os campos opcionais são: Servidores secundários. Após o endereço IP do servidor principal, você pode adicionar endereços IP de outros servidores secundários. Estes fornecem fontes adicionais a partir das quais o servidor secundário pode obter dados. A adição de endereços IP de servidores secundários pode, em algumas circunstâncias, reduzir o desempenho, a menos que esses endereços IP sejam endereços de rede adicionais de um servidor principal multihome. Arquivo de backup. Após o endereço IP do (s) servidor (es) principal (e secundário opcional), você pode adicionar o nome de um arquivo de hosts de backup. Se houver um nome de arquivo de backup, o servidor secundário carregará seus dados desse arquivo e, em seguida, verificará com os servidores principal (e secundário opcional) para garantir que os dados no arquivo de backup estejam atualizados. Se o arquivo de backup não estiver atualizado, ele será atualizado, com base nas informações recebidas do servidor principal. Por exemplo, as seguintes linhas em um arquivo de inicialização especificam que o servidor é o servidor secundário para a zona de documentos e seu domínio de endereço reverso que obtém seus dados autoritativos do servidor principal com um endereço IP de 129.146.168.119. que ele usa o servidor 192.146.168.38 como uma fonte secundária de dados de zona e inicialmente carrega seus dados do arquivo doc. bakup: No contexto dos vários arquivos de exemplo apresentados neste capítulo, as linhas de arquivo de inicialização de amostra acima correspondem à arquivo de inicialização do servidor dnssecondary, que é um alias para a máquina sirius cujo endereço IP é 192.146.168.38. Um servidor pode atuar como o servidor primário para uma ou mais zonas e como servidor secundário para uma ou mais zonas. A mistura de entradas no arquivo de inicialização determina se um servidor é primário ou secundário para uma determinada zona. Especificando um servidor somente de cache Um servidor somente de cache não mantém nenhum dado autoritativo que lida com consultas e pergunta aos hosts listados no. named arquivo para as informações necessárias. Em outras palavras, um servidor somente de cache manipula o mesmo tipo de consulta que os servidores de nomes autoritários executam, mas não mantém dados autoritativos em si. O Exemplo 13-3 é um arquivo de inicialização de amostra para um servidor somente de armazenamento em cache. Exemplo 13-3 Exemplo de arquivo de inicialização mestre para servidor somente de cache Você não precisa de uma linha especial para designar um servidor como um servidor somente de cache. O que denota um servidor somente de cache é a ausência de qualquer linha de autoridade primária ou secundária no arquivo de inicialização, exceto conforme indicado abaixo. Um servidor somente de cache requer: Uma linha de diretório no arquivo de inicialização Uma linha primária 0.0.127.in-addr. arpa no arquivo de inicialização Um cache. Linha named. ca no arquivo de inicialização Configuração dos arquivos de dados Todos os arquivos de dados usados ​​pelo daemon DNS in. named são gravados no formato de registro de recurso padrão. Cada linha de um arquivo é um registro, chamado de registro de recurso (RR). Cada arquivo de dados do DNS deve conter certos registros de recursos. Consulte o Guia de Administração de Nomeação do Solaris para obter uma descrição dos registros de recursos, seus formatos, os campos que eles contêm, caracteres especiais e entradas de controle. Tipos de registro de recurso Os tipos de registro de recurso mais usados ​​são listados na Tabela 13-3. Eles geralmente são inseridos na ordem mostrada na Tabela 13-3. mas isso não é um requisito. Tabela 13-3 Tipos de registro de recursos comumente usados ​​Consulte o Guia de Administração de Nomeação do Solaris para obter descrições detalhadas desses tipos de registro de recurso. Nos arquivos de amostra incluídos nas seções a seguir, indica a zona atual ou a origem e as linhas que começam com um ponto-e-vírgula () são comentários. Configurando os nomes dos servidores Raiz do arquivo named. ca são indicados no registro NS e endereços no registro A. Você precisa adicionar um registro NS e um registro A para cada servidor raiz que você deseja incluir no arquivo. Como você obtém ou cria seu arquivo named. ca depende se a sua rede está ou não conectada à Internet mundial. Internet named. ca File Se a sua rede estiver conectada à Internet, no momento você obtém o arquivo named. ca dos serviços de registro da InterNIC por meio de: FTP anônimo. O site FTP é: ftp. rs. internic. net. O nome do arquivo é: /domain/named. root. Gopher. O site do Gopher é: rs. internic. net. O arquivo é: named. root. que pode ser encontrado no menu InterNIC Registration Services, no submenu InterNIC Registration Archives. Se você estiver seguindo as convenções de nomenclatura usadas neste manual, mova named. root para /var/named/named. ca. Exemplo 13-4 Exemplo de arquivo Internet named. ca Arquivo não denominado Internet. ca Se sua rede não estiver conectada à Internet, você criará seu próprio arquivo named. ca. Para fazer isso, você designa um dos servidores para ser o servidor raiz e, em seguida, cria um arquivo named. ca em todos os servidores DNS que apontam para esse servidor raiz. Por exemplo, suponha que seu domínio seja denominado privado e você designe a máquina como raiz, como seu servidor raiz não-Internet. A máquina ourroot tem um endereço IP de 192.1.1.10. Seus arquivos named. ca conteriam a linha: Os arquivos de cache também precisam de um registro SOA, registros NS para cada domínio e subdomínio e registros A para cada servidor. Por exemplo, suponha que além de ourroot você também tivesse servidores de nomes DNS chamados ourprimary e oursecondary. Os arquivos named. ca em todos os seus servidores DNS ficariam assim: Exemplo 13-5 Exemplo de arquivo named. ca (não-Internet) Consulte Configurando um mestre raiz não-Internet para uma discussão mais completa sobre como configurar um domínio que não está conectado à Internet. Configurando o arquivo hosts O arquivo hosts contém todos os dados sobre cada máquina na sua zona. Se uma zona abranger mais de um domínio, todas as máquinas em todos os domínios abrangidos pela zona serão listadas no arquivo host da zona (consulte Configurando Subdomínios - Mesma Zona). O nome hosts é um nome genérico que indica a finalidade e o conteúdo dos arquivos. Mas para evitar confusão com / etc / hosts. você deve nomear esse arquivo com algo diferente de hosts. Se você tiver mais de uma zona, cada zona deverá ter seu próprio arquivo de hosts e cada um desses arquivos de hosts de zona deverá ter um nome exclusivo. Por exemplo, se o seu domínio DNS estiver dividido em zonas doc e sales. doc, você poderá nomear um arquivo hosts db. doc e o outro sales. db. doc. Deve haver um arquivo hosts separado, com nome exclusivo, para cada zona. Se você tiver mais de uma zona, cada arquivo de host de zonas deverá incluir informações sobre os servidores mestre (primário e secundário) das outras zonas, conforme descrito em Configurando Subdomínios - Zonas Diferentes. Exemplo 13-6 Arquivo de hosts de amostra Um arquivo de hosts geralmente contém estes elementos: Um registro de início de autoridade (SOA) Um ou mais registros de servidor de nomes (NS) identificando servidores de nome DNS primários e secundários Registros de endereço (A) para cada host na zona O nome canônico (CNAME) registra para cada alias de host na zona Um ou mais registros do Mail Exchange (MX) (consulte Guia de administração de nomeação do Solaris para obter descrições detalhadas desses tipos de registro de recurso). Configurando o arquivo hosts. rev O arquivo hosts. rev configura o mapeamento inverso. O nome hosts. rev é um nome genérico que indica a finalidade e o conteúdo dos arquivos. Se você tiver mais de uma zona, cada zona deverá ter seu próprio arquivo hosts. rev e cada um desses arquivos hosts. rev da zona deverá ter um nome exclusivo. Por exemplo, se o seu domínio DNS estiver dividido em zonas doc e sales. doc, você poderá nomear um arquivo host. rev doc. rev e o outro sales. rev. Exemplo 13-7 Exemplo de arquivo hosts. rev Um arquivo hosts. rev contém estes elementos: Um registro de início de autoridade (SOA) Um ou mais registros do Servidor de Nomes (NS) que identificam servidores de nomes DNS primários e secundários. Nomes de servidores devem ser totalmente qualificados. Um registro PTR para cada host na zona. Os nomes das máquinas devem ser totalmente qualificados. (Consulte o Guia de Administração de Nomeação do Solaris para obter descrições detalhadas desses tipos de registro de recurso.) Configurando o arquivo named. local O arquivo named. local configura a interface de loopback local para o seu servidor de nomes. Exemplo 13-8 Exemplo de arquivo named. local Um arquivo named. local contém estes elementos: Um registro Start of Authority (SOA), que indica o início de uma zona e inclui o nome do host no qual o arquivo de dados named. local reside . Um ou mais registros do Servidor de Nomes (NS) que identificam os servidores de nomes DNS primários e secundários. Os nomes de servidor e domínio devem ser totalmente qualificados. Um registro PTR para o host local Consulte o Guia de Administração de Nomeação do Solaris para obter descrições detalhadas desses tipos de registro de recurso. Inicializando o servidor Para inicializar um servidor: Instale o arquivo de configuração named. conf e os arquivos de dados necessários, conforme descrito nas seções anteriores. Em vez de executar in. named da linha de comando, você pode reinicializar. Testando sua instalação Depois que seus arquivos de inicialização e dados estiverem configurados e nomeados em execução, teste sua instalação da seguinte maneira: Verifique se há mensagens de erro em seu arquivo syslog. Consulte o Guia de Administração de Nomeação do Solaris para obter mensagens de erro de DNS comuns e informações sobre solução de problemas. Procure um nome de host no domínio local com o nslookup. Se sua pesquisa for bem-sucedida, seu servidor de nomes provavelmente está funcionando corretamente. Se você encontrar um Cant find, ou não conseguir inicializar o endereço, o tipo de mensagem do seu servidor ou um domínio inexistente, digite message, isso pode significar que o servidor não está listado corretamente nos arquivos de inicialização ou hosts. Se você obtiver um tipo de mensagem de nome não encontrado ou de domínio inexistente, isso pode significar que o host que você pesquisou não está no arquivo de hosts de servidores ou o domínio está definido incorretamente no resolv. conf. ou há algum outro problema no servidor. Procure um nome de domínio remoto com o nslookup. Se a sua rede estiver conectada à Internet, procure o nome de um domínio remoto. (Se a sua rede não estiver conectada à Internet, procure o nome de um subdomínio em outra zona, se tiver uma.) Por exemplo, para procurar o nome do domínio da Internet internic. net remoto, digite: você é bem sucedido, seu servidor de nomes provavelmente está funcionando corretamente. Se o comando acima não encontrar o nome de domínio remoto, uma causa possível é que a conexão de sua rede com a Internet não está funcionando corretamente. Outra causa possível é que o arquivo named. ca não está instalado ou configurado corretamente. (Na segunda vez que você usar nslookup para encontrar um domínio, sua resposta será retornada como não autoritativa. Isso é normal porque a resposta agora vem do seu cache, não do servidor de nomes remoto.) Procure um nome de host em seu domínio de um domínio remoto. Se sua rede estiver conectada à Internet, procure o nome de um host em seu domínio a partir de um domínio remoto. (Se a sua rede não estiver conectada à Internet, procure o nome de um host em seu domínio a partir de outra zona, se você tiver um.) Por exemplo, para procurar o nome de um host em seu domínio, a partir de uma Internet remota. domain, você digitaria dois argumentos após o comando nslookup: Primeiro o nome do host que você está procurando e, segundo, o nome do servidor de nomes que você está testando: Se você tiver êxito, seu servidor de nomes provavelmente está funcionando corretamente. Se o comando acima não encontrar a máquina que você está procurando, uma causa possível é que seu domínio não está registrado corretamente com quem está administrando o domínio pai (no exemplo acima). Configurando subdomínios Mesma zona. O método mais fácil é incluir o subdomínio na zona de domínios pai. Dessa forma, um conjunto de servidores DNS e arquivos de dados se aplica a todas as máquinas, independentemente de seu domínio. Veja Configurando Subdomínios - Mesma Zona. A vantagem do método da mesma zona é a simplicidade e facilidade de administração. A desvantagem é que um conjunto de servidores deve atender a todas as máquinas em todos os domínios das zonas. Se houver muitas máquinas, os servidores ficarão sobrecarregados e o desempenho da rede poderá diminuir. Zonas diferentes. Você pode colocar diferentes domínios em diferentes zonas. Isso é mais complexo porque você precisa especificar como os clientes de uma zona obtêm informações de DNS sobre hosts em outra zona. Consulte Configurando Subdomínios - Zonas Diferentes. A vantagem do método de zona diferente é que você pode designar diferentes conjuntos de servidores para servir máquinas em diferentes domínios dessa maneira, você distribui a carga do servidor para que nenhum grupo de servidores seja sobrecarregado. A desvantagem é que a manutenção da configuração é mais complicada. Configuração de subdomínios - mesma zona Os arquivos de dados para zonas com vários domínios devem incluir registros para todas as máquinas e servidores em cada domínio abrangido pela zona. Configurar uma zona de vários domínios é o mesmo que configurar uma zona com um único domínio, exceto que nomes de domínio totalmente qualificados são usados ​​no arquivo de hosts para identificar máquinas em domínios remotos. Em outras palavras, no arquivo hosts, quando você identifica uma máquina no domínio local dos servidores, é necessário usar apenas o nome da máquina. Mas quando você identifica uma máquina em algum outro domínio, você deve identificar a máquina com um nome de domínio totalmente qualificado no formato: machine. domain. Os nomes de servidor e máquina nos arquivos hosts. rev e named. local também precisam ser totalmente qualificados com nomes de domínio. Mas isso é verdade independentemente de a zona ter ou não mais de um domínio. Configurando Subdomínios - Zonas Diferentes A configuração de subdomínios que estão em zonas diferentes é mais complicada do que incluir vários domínios em uma única zona, porque você precisa especificar como os clientes em diferentes zonas obtêm informações de DNS das outras zonas. Para dividir uma rede em vários domínios, crie uma hierarquia de domínio. Ou seja, um domínio se torna o principal domínio. Abaixo do domínio principal, você cria um ou mais subdomínios. Se você quiser, você pode criar subdomínios de subdomínios. Mas cada subdomínio tem um local definido em relação ao domínio principal na hierarquia de domínios. Quando lidos da esquerda para a direita, os nomes de domínio identificam o local dos domínios na hierarquia. Por exemplo, o domínio doc está acima do domínio sales. doc, enquanto o domínio west. sales. doc está abaixo do domínio sales. doc. As zonas DNS adquirem uma hierarquia dos domínios que elas contêm. A zona que contém um domínio superior de redes é a zona superior. Uma zona que contém um ou mais subdomínios abaixo do domínio superior está abaixo da zona superior na hierarquia da zona. Quando as informações do DNS são passadas de uma zona para outra, elas são passadas para cima e para baixo na hierarquia da zona. Isso significa que cada zona requer registros em seus arquivos de dados que especificam como passar as informações até a zona imediatamente acima e até as zonas imediatamente abaixo dela. Para transferir corretamente as informações de DNS de uma zona para outra em uma rede multizona: arquivo hosts. rev. Deve haver um registro PTR em cada arquivo hosts. rev apontando para o nome de um ou mais servidores principais na zona imediatamente acima. Esse tipo de registro PTR é exatamente igual a qualquer outro registro PTR no arquivo, exceto pelo fato de identificar um servidor na zona acima. hosts registram registros NS. Deve haver um registro NS da zona em cada arquivo hosts identificando cada servidor de nomes em cada zona imediatamente abaixo. Este tipo de registro NS requer o nome da zona abaixo como o primeiro campo no registro NS. (O nome da região é especificado no registro SOA do arquivo host da zona.) Hospeda registros do arquivo A. Deve haver um registro A em cada arquivo de hosts, identificando o endereço IP de cada servidor de nomes em cada zona imediatamente abaixo. This type of A record has to have the name of the zone below as the first field in the A record. (The name of the zone is specified in the SOA record of the zones host file.) The example files in Table 13-4 illustrate a network with two zones. Setting Up a Non-Internet Root Master If your network is connected to the Internet, your root domain server exists at the root domain Internet site all you need to do is provide that sites Internet IP addresses in your cache file, as explained in Internet named. ca File . If your network is not connected to the Internet, you must set up primary and secondary name servers in the root-level domain on your local network. This enables all domains in your network to have a consistent authoritative server to which to refer otherwise, machines might not be able to resolve queries. For example, suppose your non-Internet domain is named private and you designate the machine ourroot as your root server. The ourroot machine has an IP address of 192.1.1.10 . You would then perform the following steps: Create named. ca files on your primary master servers that point to your own root server. A named. ca file must also contain NS records for each internal domain and subdomain and A records for each server as described in Setting Up a Non-Internet Root Master . Add a cache resource record for the root domain to the boot files of all DNS name servers on your network. Remove the root domain cache resource record from the boot file of your root server. In other words, delete the cache. named. ca line from ourroot s boot file. Insert a primary line for the root domain in the root servers boot file. For example, in ourroot s boot file you would add the line: If you later decide to connect your network to the Internet, you must replace all the named. ca files on all of your servers with the current Internet files and replace the primary . rootserver line with a cache. named. ca line in the former root servers boot file. A Practical Example This section shows the files you need to implement DNS for a sample Internet-connected network, based on the examples used in this chapter. The IP addresses and network numbers used in examples and code samples in this manual are for illustration purposes only. Do not use them as shown because they may have been assigned to an actual network or host. This practical example assumes: An environment connected to the Internet Two networks, each with its own domain ( doc and sales. doc ) and its own DNS zone The doc domain and zone is the top zone over the sales. doc subdomain and zone. Each network has its own network number Table 13-4 Example Network Domain and Zone ConfigurationLinux / UNIX set the DNS from the command line Q. I just got Linux installed on my system. I8217m able to connect to internet via IP address only. I8217m not able to find out information about setting up new DNS sever ip under Linux. How do I configure primary and secondary DNS via terminal / shell prompt A. Under Linux / UNIX / BSD operating system, you need to edit the /etc/resolv. conf file and add the line: Login as the root, enter: vi /etc/resolv. conf OR sudo vi /etc/resolv. conf Modify or enter nameserver as follows: nameserver 208.67.222.222 nameserver 208.67.220.220 Save and close the file. To test DNS configuration type any one of the following command: host google dig google ping google nslookup your-domain Output: If you see valid output such as actual IP address or able to ping to remote server via hostname, it means that the dns is working for you. Also make sure you have valid default gateway setup. if you see the time out error. Share this tutorial on: About the author: Vivek Gite is a seasoned sysadmin and a trainer for the Linux/Unix amp shell scripting. Follow him on Twitter . OR read more like this : Linux / UNIX Command To Find Out Who Owns a Domain Name How do I find out my mail server blacklisted Ubuntu Linux Configure DNS Name Server IP Address ( DNS Client ) Google Apps Domain Create SPF Records For BIND or Djbdns How To Look Up DNS on a Linux and Unix Systems How To Install Google Chrome 52 On a RHEL/CentOS 7 and Fedora Linux 24hellip Linux Share a Dial Up Internet Connection How To Find My Public IP Address From Command Line On a Linux Linux Install Google Chrome Browser Ubuntu, Suse, Debian, Fedora tspc: Debian / Ubuntu Linux Configure IPv6 Tunnel