• Nenhum resultado encontrado

REESTRUTURAÇÃO DA ARQUITECTURA DE DNS

N/A
N/A
Protected

Academic year: 2021

Share "REESTRUTURAÇÃO DA ARQUITECTURA DE DNS"

Copied!
9
0
0

Texto

(1)

Universidade do Porto

Março 2009

(2)

I

NTRODUÇÃO

A arquitectura de DNS da Universidade do Porto foi reestruturada, e com este documento pretende-se, de uma forma breve, apresentar as alterações em relação à arquitectura anterior, bem como fornecer alguns exemplos de configuração que permitem tirar partido das novas funcionalidades que estão já disponíveis.

(3)

A

RQUITECTURA ANTERIOR

Este modelo é baseado em 2 Servidores (dns1.up.pt e dns2.up.pt) e num balanceador de carga (dns.up.pt) que garante redundância activa entre os dois servidores, encontrando-se todo o equipamento localizado no Pólo 2. As sincronizações dos diversos domínios são efectuadas tendo por base uma arquitectura “master-master”, recorrendo-se a sincronizações de forma programada através de transferências de zona “named-xfer”. Neste modelo não existe delegação das zonas “reverse”. O IPv4 é o único protocolo IP que é suportado.

Arquitectura Actual

(4)

Com este novo modelo, para além da arquitectura existente no Pólo 2 foram colocados dois novos servidores, um no Pólo 1 e outro no Pólo 3, o que traz como vantagem o facto da redundância do serviço não depender de uma única localização. No que diz respeito à sincronização da informação dos vários sub-domínios passou a ser possível uma configuração do tipo “master-slave”, em que as sincronizações são efectuadas de forma automática em vez da sincronização periódica (programada) existente. A delegação das zonas “reverse” é permitida. Outra novidade é o facto de serem suportados os protocolos IPv4 e IPv6.

(5)

A

CTUALIZAÇÃO DE ARQUITECTURA

Com a disponibilização da nova arquitectura tornam-se necessárias algumas alterações de configuração, que permitam tirar partido das novas funcionalidades.

R

EDUNDÂNCIA

Para além do endereço que era utilizado e que continua disponível no Pólo 2 através do conhecido “193.137.55.10” e do novo endereço IPv6 “2001:690:2200:a10::10” devemos passar a utilizar também os endereços dos restantes Pólos. Deste modo, se, por exemplo, nas configurações de um servidor de DNS estivéssemos a usar como “forward” o endereço do serviço de DNS existente no Pólo 2, deveremos agora acrescentar também pelo menos mais um dos novos endereços disponíveis nos outros pólos. O mesmo é válido para as configurações em que se faça consulta directa (Ex: “resolv.conf”) ao serviço de DNS da UP.

IPv4 IPv6

Pólo 1 193.136.37.10 2001:690:2200:910::10 Pólo 2 193.137.55.10 2001:690:2200:a10::10 Pólo 3 193.137.35.100 2001:690:2200:b10::100

No Pólo 2 continua a existir o balanceador de carga, que oferece uma maior garantia de disponibilidade de serviço. No entanto, note-se que existe sempre vantagem em incluir os endereços dos restantes Pólos, pela razão já mencionada de redundância na localização física do serviço.

S

INCRONIZAÇÕES

Para se usufruir da possibilidade de sincronização “master-slave” é necessário alterar ligeiramente as configurações de cada zona. No modelo anterior, o servidor dns1.up.pt efectuava uma transferência de zona

(6)

xfer), de forma periódica, replicando a informação obtida para o servidor dns2.up.pt. Com a introdução dos novos servidores, dns3.up.pt (Pólo 3) e dns4.up.pt (Pólo 1) aproveitou-se o sistema existente para se poder replicar a informação obtida pelo dns1.up.pt nos novos servidores, à semelhança do que acontecia para o dns2.up.pt. Este sistema está em funcionamento por necessidade de compatibilidade no período de transição. Contudo, a nova configuração tem vantagens ao nível da rapidez de propagação de uma actualização, pelo que é importante que se actualize para a nova configuração.

Exemplo de configuração

Neste exemplo de configuração é gerada uma “chave” para ser utilizada  na   transferência   encriptada   das   actualizações   (DNSSEC).  Paralelamente a esta protecção, devem ser também validados ao nível  da   firewall   os   endereços   autorizados   a   efectuar   sincronizações   de  zona (porto 53/TCP).

1º Gerar uma chave de encriptação, para que a transferência de dados 

entre os servidores possa ser mais segura.

# dnssec­keygen ­a HMAC­MD5 ­b 128 ­n HOST <uo>­up.

2º Assumindo que o Bind está a correr em “chroot”, criar um ficheiro 

no   directório   “/var/named/chroot/etc”   para   guardarmos   a   “chave”   de  encriptação. Na linha do “secret” deveremos colocar a “chave” que foi  gerada   no   1º   passo,   bastando   consultar   o   ficheiro   “K<uo>­up.

+157+25890.private” que foi gerado (o nome do ficheiro varia em cada  nova geração). # cd /var/named/chroot/etc # vi <uo>­up.key key "<uo>­up." { algorithm hmac­md5; secret "wu1Qc+8ZxFoiB8Rvm8IWdg==";   }; Alterar as permissões do ficheiro # chmod 640 <uo>­up.key # chown root.named <uo>­up.key

3º  Incluir   a   “chave”   no   início   do   ficheiro   de   configuração 

“named.conf”. # vi named.conf

(7)

4º Associar a “chave” ao respectivo servidor. Esta informação deverá 

constar   no   ficheiro   “named.conf”   antes   da   configuração   das   zonas.  Deste modo, a chave será usada para encriptação nas actualizações das  zonas   (sincronização).   Cada   chave   terá   de   constar   também   nos  servidores de destino (chave simétrica).

De   lembrar   que   no   Pólo   2   existem   2   servidores   (dns1.up.pt   e   dns2.up.pt) e um “balanceador de carga” (dns.up.pt). Para consultas  ao   serviço   DNS   deste   pólo,   tal   como   foi   mencionado   anteriormente  neste   documento,   deve   ser   utilizado   o   endereço   do   balanceador   de   carga  (dns.up.pt) 193.137.55.10  ou 2001:690:2200:a10::10. No  entanto,  as   actualizações   de   zona   (sincronizações)   deverão   ser   efectuadas  directamente nos servidores dns1.up.pt e dns2.up.pt.

Nota:   A   sigla   “<uo>”,   neste   exemplo,   deverá   ser   substituída   pela  sigla da respectiva Unidade Orgânica, bem como o nome dos ficheiros  de cada zona... # vi named.conf // dns1.up.pt (Pólo 2) server 193.137.55.20 { keys { <uo>­up.; }; }; server 2001:690:2200:a10::20 { keys { <uo>­up.; }; }; // dns2.up.pt (Pólo 2) server 193.137.55.21 { keys { <uo>­up.; }; }; server 2001:690:2200:a10::21 { keys { <uo>­up.; }; }; // dns3.up.pt (Novo servidor no Pólo 3) server 193.137.35.100 { keys { <uo>­up.; }; }; server 2001:690:2200:b10::100 { keys { <uo>­up.; }; }; // dns4.up.pt (Novo servidor no Pólo 1) server 193.136.37.10 { keys { <uo>­up.; }; IRICUP 7 2008

(8)

}; server 2001:690:2200:910::10 { keys { <uo>­up.; }; }; 5º Permitir transferências de zona. # vi named.conf         zone "<uo>.up.pt" IN {       type master;       zone­statistics yes;       file "externa/<uo>.forward";            allow­transfer { key "<uo>­up.key."; };       notify yes;       allow­update { none; };         };    // Substituir “54.137.193” pelo correspondente na UO, em cada  caso...         zone "54.137.193.in­addr.arpa" IN {        type master;       zone­statistics yes;       file "externa/<uo>.reverse";            allow­transfer { key "<uo>­up.key."; };       notify yes;       allow­update { none; };         };     //   Substituir   “0.1.2.4.0.0.2.2.0.9.6.0.1.0.0.2”   pelo  correspondente na UO, em cada caso...         zone "0.1.2.4.0.0.2.2.0.9.6.0.1.0.0.2.ip6.arpa" {       type master;       zone­statistics yes;       file "externa/<uo.v6.10>.reverse";            allow­transfer { key "<uo>­up.key."; };       notify yes;       allow­update { none; };         };

(9)

IP

V

6

A configuração do protocolo IPv6 no serviço DNS é um tema tratado no documento “Serviços de Rede IPv6” de Março de 2009, pelo que remete-se este assunto para o referido documento.

Referências

Documentos relacionados

Anderson (2003) reduz a importância da interação aluno-aluno se o planejamento do curso é baseado em abordagens pedagógicas cognitivistas ou behavioristas, ao

Jsou radiostanice, které už mají SV vestavěnou (Zirkon 1), dále jsou pak SV externí (Smart 1, Slavík), v prove- dení jako krabička, která se připojí k ra- diostanici

A pouca atenção dada aos princípios de uma boa incisão leva, como no caso clínico descrito anteriormente (onde a incisão foi feita sobre a fístula presente durante a

imii lorlc demais para ser influenciado por uma pessoa indecisa. Deu-lhe inil.i i sua atenção. Com sua personalidade vibrante, com sua càpacidade de i i.ii sempre no meio do

A inscrição do imóvel rural após este prazo implica na perda do direito de manter atividades agropecuárias em áreas rurais consolidadas em APP e Reserva Legal, obrigando

Many positive impacts are documented in sectors well beyond the sugarcane mills and farms: boosts in other crops, decrease in deforestation, growth of labor market, and improved

Os trabalhadores petroquímicos gaúchos, diante da ameaça, em 2005/2006, de entrega do pólo petroquímico do RS ao grupo Odebrecht/Braskem, desenvolveram em nível nacional,

[r]