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 revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
doc:appunti:linux:sa:bind_named [2011/02/04 15:30] – [Dynamic DNS zones] niccolodoc:appunti:linux:sa:bind_named [2019/03/07 11:00] – [Record TXT multipli e TTL] niccolo
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 le dichiarazioni $TTL al top level non vengono processate in ordine sequenziale al pari dei record top level, 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.txt · Last modified: 2022/02/14 16:26 by niccolo