DNS interno e externo de servidores diferentes, mesma zona

4

Estou tendo problemas para entender como o DNS funciona ou estou com problemas para configurar meu DNS corretamente (um não é bom). No momento, estou trabalhando com um domínio, chamarei de webdomain.com , e preciso permitir que todos os usuários internos recebam pontos para obter nossas entradas de DNS públicas, assim como o restante de o mundo. Então, além disso, desejo fornecer apenas algumas entradas de DNS de substituição para testar servidores e equipamentos que não estão disponíveis publicamente. Como exemplo:

  • public.webdomain.com - deve receber isso do dotster
  • outside.webdomain.com - deve receber isso também do dotster

  • testing.webdomain.com - deve obter isso do meu controlador de DNS interno

O problema que pareço ter em cada etapa é que, se eu tiver um controlador de DNS interno que contenha uma zona para webdomain.com, então posso obter minhas entradas internas especificadas, mas nunca obtém nada do servidor DNS público. Isso é válido independentemente do tipo de servidor DNS que eu uso também - tentei um Linux Bind9 e um controlador de domínio do Windows 2008.

Acho que minha grande pergunta é: estou sendo razoável pensar que um sistema deve ser capaz de verificar meu DNS interno especificado e, no caso de não existir uma entrada solicitada, ele deve fazer o failover para o servidor de DNS público especificado? -OU- isso não é apenas o modo como o DNS funciona e estou perdido no molho?

Parece que deve ser tão simples quanto dizer ao meu servidor DNS interno para encaminhar quaisquer solicitações que ele não consiga preencher com o dotster, mas isso não parece funcionar. Isso poderia ser um problema de firewall?

Obrigado antecipadamente

ESTENDIDO

OK, então eu fiz um monte de pesquisas e tenho trabalhado nisso por algumas horas. Eu tenho isso no meu named.conf e ainda estou vendo o mesmo resultado. Chamadas internas são alimentadas, mas qualquer coisa externa (no domínio controlado por zona) é apenas descartada. Qualquer apoio seria bom! Além disso, este é um sistema operacional Ubuntu 9.04 com o qual estou trabalhando.

Code removed because it was wrong.

O caminho correto - adicionado após a pergunta encerrada

Bem, graças ao pessoal aqui no serverfault, eu agora tenho isso funcionando perfeitamente no meu servidor e de uma forma muito mais sucinta. Aqui está como você faz isso. A partir de uma instalação básica do bind9, edite seu arquivo named.conf.local e adicione uma zona para cada subdomínio que você deseja redirecionar:

/etc/bind/named.conf

// WEBDOMAIN.COM ENTRIES
    zone "test.webdomain.com" {
            type master;
            file "/etc/bind/zones/test.webdomain.com";
    };

    zone "alpha.webdomain.com" {
            type master;
            file "/etc/bind/zones/alpha.webdomain.com";
    };

    zone "beta.webdomain.com" {
            type master;
            file "/etc/bind/zones/beta.webdomain.com";
    };

// INTERNETSITE.COM ENTRIES
    zone "internal.internetsite.com" {
            type master;
            file "/etc/bind/zones/internal.internetsite.com";
    };

    zone "dev.internetsite.com" {
            type master;
            file "/etc/bind/zones/dev.internetsite.com";
    };

Edite seu arquivo /etc/bind/named.conf.options e adicione todos os encaminhadores que você deseja usar no local correto:

/etc/bind/named.conf.options

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

        forwarders {
                208.67.222.222;
                208.67.220.220;
                8.8.8.8;
                8.8.4.4;
        };

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Crie uma nova pasta chamada zones em / etc / bind / zones / e adicione um novo arquivo para EACH das zonas criadas acima que correspondam ao atributo 'file' acima. Usando test.webdomain.com como um exemplo:

/etc/bind/zones/test.webdomain.com

$TTL    604800
@       IN      SOA     test.webdomain.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@                       IN      NS      test.webdomain.com.
test.webdomain.com.    IN      A       10.0.1.20

Onde 10.0.1.20 é o endereço IP do registro A para o qual você deseja que este (sub) domínio seja encaminhado. Ao fazer isso, o registro de test.webdomain.com é autoritativo apenas para o subdomínio e o DNS global fornecerá outros subdomínios ou domínios raiz, como de costume.

    
por Shane 06.01.2011 / 20:09

4 respostas

7

O que você precisa fazer é criar uma zona DNS para testing.webdomain.com no seu servidor DNS interno. Desta forma, o DNS webdomain.com não é hospedado pelo seu servidor interno, mas é hospedado pelo dotster.

Quando alguém perguntar por www.webdomain.com, a solicitação será encaminhada para o ponto de vista da pesquisa (já que seu servidor DNS local não é autoritativo para essa zona), enquanto as solicitações de teste.webdomain.com serão tratadas pelo seu servidor DNS interno.

    
por 06.01.2011 / 20:14
5

Você precisa de DNS com visualização dividida . Para suas máquinas de borda, use um resolvedor externo . Para o seu ambiente de teste, use um resolvedor separado, interno . O resolvedor interno terá sua entrada de teste no DNS e responde a partir de uma visualização; mas o mundo exterior verá uma "visão" diferente da sua zona, que omite o ambiente de teste.

Outras entradas de SF que podem ser de interesse:

Eu só tenho tempo hoje para vasculhar sua postagem estendida, então aqui está um primeiro olhar:

options {                                       
    directory "/etc/bind";                   
    listen-on {          // why are these lines needed?
            10.0.1.5;    // the way it is set up, only your loopback
            127.0.0.1;   // and your LAN clients will be able to
                         // get answers; the outside world can't see boo
                         // because there's no interface/port pair
                         // to contact. I would just get rid of this and
              };         // not worry about what interfaces are being bound to
    // BTW, that listen-on line is why your outside queries are failing.
    auth-nxdomain no;                      
    allow-query { any; };                   
    recursion no;                          
    version "0";                           
};

Além disso, a declaração externa de correspondência de clientes

view "external" {
    match-clients { !localnets; any; };

pode ser feito em

view "external" {
    match-clients { any; };

porque quando você adiciona aos clientes de correspondência, já está assumindo que não há nada para combinar para começar; negar uma ACL realmente não adicionará muito (porque nunca "existiu" nessa visualização, portanto não há motivo para cancelá-la).

Tenho certeza de que provavelmente perdi algumas coisas, mas esses são os culpados mais óbvios.

    
por 06.01.2011 / 20:15
2

Parece que sua definição de zona não está correta. Ele perde o endereço IP do servidor de nomes declarado como "webdomain.com".

Sugiro que você altere a definição da zona como

$TTL    604800
@       IN      SOA     webdomain.com. email.webdomain.com. (
                              4         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      webdomain.com.
webdomain.com.  IN A 10.0.1.5
test    IN      A       10.0.1.20

, reinicie o servidor (por exemplo, /etc/init.d/bind9 restart ).

Como a zona não pôde ser carregada, devido ao erro, o domínio não pôde ser resolvido.

    
por 14.01.2011 / 19:18
1

Em seu servidor DNS do Windows, configure uma nova ZONA para testing.webdomain.com. Quando você adicionar o primeiro host, deixe o campo de nome em branco e insira o endereço IP desejado para os usuários internos.

Este servidor será autoritativo para essa zona, portanto, todas as solicitações serão direcionadas para esse IP, de modo que não entrará em conflito com sua resolução externa.

Eu uso isso em todos os meus sites para mail.corpdns.com (porque os usuários nunca se lembram de usar o nome do servidor interno ao tentar acessar o webmail, etc.).

Eu suspeito que isso pode ser feito no Linux / Bind, mas eu não sei os passos.

    
por 14.01.2011 / 18:58