Struttura nazionale di Nameserver per i servizi ad alta affidabilità Riccardo Veraldi - CNAF

Architettura DNS INFN infn.it Riccardo Veraldi - CNAF - CCRWS1118 Maggio

DNS ha.infn.it multimaster Riccardo Veraldi – CNAF – CCRWS11 infn.it ns1.ha.infn.it host IN CNAME host.ha.infn.it. probe Istanza master sez. INFN Istanza master CNAF ns2.ha.infn.it host 60 IN A y.z host 60 IN A a.b In sede roma1 Db update 3 In sede roma1 18 Maggio

Come funziona I servizi (host.infn.it) vengono ridondati geograficamente in 2 sedi (ad es: CNAF e altra sede INFN) Il sottodominio ha.infn.it viene implementato con architettura Multi Master in due sedi INFN (ad es. CNAF e ROMA1) Viene impostata la delega per ha.infn.it su server2.infn.it verso ns1.ha.infn.it e ns2.ha.infn.it e gli host name dei servizi HA vengono definiti su server2.infn.it come CNAME che puntano a hostname sul dominio ha.infn.it Gli hostname definiti su ns1.ha.infn.it e ns2.ha.infn.it puntano all’IP di un'istanza del servizio con TTL 60 in una delle due sedi in cui è installato Nella sede di ROMA1 è presente un nagios server che fa probe verso i server su cui è implementato un determinato servizio ridondato geograficamente Se il server principale tra i due non risponde nagios fa partire un'opportuna procedura (db update) che modifica l’IP del servizio su ns1.ha.infn.it oppure su ns2.cnaf.infn.it se il primo non è raggiungibile Lo script di aggiornamento dei record DNS automaticamente contatta il nameserver che risponde per primo Attraverso il CNAME definito su server2.infn.it il servizio sarà sempre raggiungibile nella sede in cui è UP and running Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Vantaggi architettura multimaster Tutti i nameserver sono autoritativi e paritetici per la zona ha.infn.it ns1.ha.infn.it ns2.ha.infn.it La modifica su un nameserver viene propagata automaticamente sull’altro Se uno dei due nameserver non e’ raggiungibile si possono continuare a operare modifiche su quello disponibile e quando il secondo tornera’ UP automaticamente si sincronizzera’ con il suo peer Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Come si realizza un DNS multimaster Utilizzare un dominio windows2k3 OPPURE Modificare e configurare bind in modo opportuno Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Configurazione bind multimaster Bind versione Supporto per DLZ Supporto per MySQL Configurazione di named-DLZ (named.conf) Creazione schema DB per i record DNS Configurazione del secondo DB sul secondo NS Configurazione dei due DB in modalita’ multimaster Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Bind version Bind versione di RHEL supporta DLZ rpm RHEL 5.6 bind97 non ha il supporto per DLZ rpm RHEL 6.0 bind P2.1 ha suppoto per DLZ Ricompilazione di bind P2.el6_0.1.src.rpm con supporto DLZ abilitato %{?!SDB: %define SDB 1} Supporto per MySQL %if %{SDB} --with-dlz-ldap=yes \ --with-dlz-postgres=yes \ --with-dlz-mysql=yes \ --with-dlz-filesystem=yes \ %endif Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Cos’e’ DLZ ? DLZ (Dynamically Loadable Zones) e’ una patch per bind 9 che consente di caricare le zone in modo dinamico all’occorrenza e permete l’utilizzo di backend altrimenti non supportate nativamente da bind PostgresSQL MySQL ODBC LDAP La patch e’ disponibile di default in bind di RHEL 6.0 come pachetto bind-sdb P2.1 Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Configurazione DLZ in named.conf dlz "Mysql zone" { database "mysql {host= dbname=named user=named pass=****} {select zone from dns_records where zone = '%zone%'} {select ttl, type, mx_priority, case when lower(type)='txt' then concat('\"', data, '\"') else data end from dns_records where zone = '%zone%' and host = '%record%' and not (type = 'SOA' or type = 'NS')} {select ttl, type, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum from dns_records where zone = '%zone%' and (type = 'SOA' or type='NS')} {select ttl, type, host, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum from dns_records where zone = '%zone%' and not (type = 'SOA' or type = 'NS')} {select zone from xfr_table where zone = '%zone%' and client = '%client%'}"; }; Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Configurazione schema DB | dns_records | CREATE TABLE `dns_records` ( `zone` varchar(255) NOT NULL, `host` varchar(255) NOT NULL, `type` enum('SOA','NS','MX','A','CNAME','PTR') NOT NULL, `data` varchar(255) default NULL, `ttl` int(11) NOT NULL, `mx_priority` varchar(10) default NULL, `refresh` int(11) default NULL, `retry` int(11) default NULL, `expire` int(11) default NULL, `minimum` int(11) default NULL, `serial` bigint(20) default NULL, `resp_person` varchar(255) default NULL, `primary_ns` varchar(255) default NULL, KEY `host_index` (`host`(20)), KEY `zone_index` (`zone`(30)), KEY `type_index` (`type`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Configurazione DB sul secondo NS Dump del DB su ns1 e import su ns2 mysqldump --add-drop-table -u named -p ***** named > named.mysql mysql -u named –p ***** < named.mysql Settare i grant dell’utente named sul nuovo DB Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Configurazione MM - my.cnf NS1 # master server-id = 1 # auto_increment_increment = 2 auto_increment_offset = 1 # log-bin=mysql-bin binlog-do-db=named binlog-ignore-db=mysql binlog-ignore-db=test # slave master-host = a.b master-user = replication master-password = **** master-port = 3306 # Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Configurazione MM - my.cnf NS2 # slave server-id = 2 master-host = master-user = replication master-password = **** master-port = 3306 # master log-bin=mysql-bin binlog-do-db=named # auto_increment_increment = 2 auto_increment_offset = 2 # Riccardo Veraldi - CNAF - CCRWS1118 Maggio

Conclusioni Utilizzando un dominio dedicato ha.infn.it e’ possibile a livello TLD infn.it definire dei CNAME predefiniti per i servizi importanti ridondati geograficamente L’architettura MultiMaster di ha.infn.it consente di avere sempre un server DNS disponibile per gli aggiornamenti dei record relativi a servizi nazionali ridonadati geograficamente Tramite nagios si monitora lo stato dei servizi e si lanciano gli aggiornamenti (dbupdate) per i record DNS relativi ai servizi che in un determinato momento non dovessero essere raggiungibili Riccardo Veraldi - CNAF - CCRWS1118 Maggio