User Tools

Site Tools


doc:appunti:linux:sa:bind_named

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
doc:appunti:linux:sa:bind_named [2011/02/04 15:30]
niccolo [Dynamic DNS zones]
doc:appunti:linux:sa:bind_named [2019/03/07 11:01] (current)
niccolo [Record TXT multipli e TTL]
Line 100: Line 100:
 Nell'esempio sopra il file **''/etc/bind/zones.local.any''** contiene le zone che devono valere in ogni vista e quindi deve includere anche quelle zone che Debian mette originariamente in ''/etc/bind/named.conf'' (oppure in  ''named.conf.default-zones'' con Debian Squeeze). Nell'esempio sopra il file **''/etc/bind/zones.local.any''** contiene le zone che devono valere in ogni vista e quindi deve includere anche quelle zone che Debian mette originariamente in ''/etc/bind/named.conf'' (oppure in  ''named.conf.default-zones'' con Debian Squeeze).
  
 +Una zona privata contenuta in **''/etc/bind/zones.local.private''** deve consentire il trasferimento di zona allo slave:
 +
 +<file>
 +zone "rigacci.net" {
 +    type master;
 +    file "rigacci.net.private";
 +    allow-transfer { 192.168.3.1; };
 +};
 +</file>
 ==== Configurazione dello slave 192.168.3.1 ==== ==== Configurazione dello slave 192.168.3.1 ====
  
Line 123: Line 132:
  
 **NOTA:** Se master e slave sono collegati da una **VPN con indirizzi IP point-to-point**, può essere necessario utilizzare il masquerading in modo che il master si presenti allo slave con l'indirizzo dichiarato nella configurazione, piuttosto che con l'indirizzo della punto-punto. Altrimenti si rischia un errore dir **notify Refused**. **NOTA:** Se master e slave sono collegati da una **VPN con indirizzi IP point-to-point**, può essere necessario utilizzare il masquerading in modo che il master si presenti allo slave con l'indirizzo dichiarato nella configurazione, piuttosto che con l'indirizzo della punto-punto. Altrimenti si rischia un errore dir **notify Refused**.
 +
 +===== Record TXT multipli e TTL =====
 +
 +È diventata una necessità frequente quella di avere diversi record TXT associati alla radice della zona, ad esempio per indicare le informazioni SPF e per certificare il possesso del dominio rispetto a fornitori terzi (es. Microsoft o Google).
 +
 +È del tutto legittimo inserire due o più righe con record di tipo TXT nella //zone origin// rappresentata dal carattere **@**:
 +
 +<file>
 +@    IN    TXT  "v=spf1 a:mail.rigacci.org a:relay.rigacci.org -all"
 +@    IN    TXT  "MS=D2583632ADEB1D213E1E997767A33E70D2583632"
 +</file>
 +
 +Diventa complicato invece indicare un **TTL specifico per ciascun record**. Sembra infatti che la direttiva specificata sulla singola riga **NON VIENE RISPETTATA**:
 +
 +<file>
 +; The 3600 TTL specification does not work!
 +@    3600    IN    TXT  "MS=D2583632ADEB1D213E1E997767A33E70D2583632"
 +</file>
 +
 +Verificando con **dig**
 +
 +<code>
 +dig @localhost -t TXT rigacci.org
 +</code>
 +
 +si scopre che il **TTL vale 43200**:
 +
 +<code>
 +;; ANSWER SECTION:
 +rigacci.org.    43200   IN    TXT    "MS=D2583632ADEB1D213E1E997767A33E70D2583632"
 +rigacci.org.    43200   IN    TXT    "v=spf1 a:mail.rigacci.org a:relay.rigacci.org -all"
 +</code>
 +
 +Il motivo è che esiste una dichiarazione **$TTL** al top level del file di zona:
 +
 +<file>
 +$TTL 43200
 +@    IN    SOA    ns1.rigacci.org.  postmaster.rigacci.org. (
 +     2019030701 ; Serial
 +          43200 ; Refresh
 +           7200 ; Retry
 +        2419200 ; Expire
 +          43200 ; Default TTL
 +)
 +</file>
 +
 +Purtroppo eventuali dichiarazioni $TTL multiple al top level non vengono processate ordinatamente con i record presenti allo stesso livello, ma l'ultima dichiarazione prevale sulle altre. Quindi sembra proprio che **tutti i record TXT presenti nella //zone origin// devono condividere il medesimo $TTL**.
doc/appunti/linux/sa/bind_named.1296829842.txt.gz · Last modified: 2011/02/04 15:30 by niccolo