Differences

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

--- doc:appunti:linux:sa:bind_named [2007/10/03 12:49] – external edit 127.0.0.1
+++ doc:appunti:linux:sa:bind_named [2022/02/14 16:26] (current) – [Dynamic DNS zones] niccolo
@@ Line 41: / Line 41: @@
 </file>
-A journal file will be created: **dyn.rigacci.org.jnl**, this file will grow untill it reaches the ''max-journal-size''. You can //freeze// the dynamic updates when you have to manually edit the zone file, this will also remove the journal file. After that, the //thaw// command is required:
+A journal file will be created: **dyn.rigacci.org.jnl**, this file will grow untill it reaches the ''max-journal-size''. You can //freeze// the dynamic updates when you have to manually edit the zone file. After that, the //thaw// command is required (this will also remove the journal file):
 <code>
@@ Line 75: / Line 75: @@
 </code>
+===== Viste private e notify =====
+Come configurare un server DNS con una **vista privata** e inoltrare le **notify ad uno slave**.
+==== Configurazione del master 192.168.2.2 ====
+Purtroppo se si vuole utilizzare le view, tutte le zone devono essere inserite in una view. Quindi la configurazione predefinita Debian che carica le zone //hint//, //localhost//, //127.in-addr.arpa//, ecc. da **''/etc/bind/named.conf''** (al di fuori di qualunque view) non va bene.
+Le zone si possono caricare dal file **''/etc/bind/named.conf.local''** mettendole nelle varie view:
+<file>
+view "private" {
+    match-clients { 127.0.0.1; 192.168.2.0/24; 192.168.3.0/24; };
+    include "/etc/bind/zones.local.any";
+    include "/etc/bind/zones.local.private";
+};
+view "public" {
+    match-clients {"any"; };
+    include "/etc/bind/zones.local.any";
+    include "/etc/bind/zones.local.public";
+};
+</file>
+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 ====
+Quando il master notifica lo slave di un aggiornamento, questo deve presentarsi con l'indirizzo IP master e trattandosi di vista privata, tale indirizzo deve essere incluso nei match-clients autorizzati alla view. Ecco quindi la configurazione dello slave in **''/etc/bind/named.conf.local''**:
+<file>
+view "private" {
+    match-clients { 127.0.0.1; 192.168.2.0/24; 192.168.3.0/24; };
+    include "/etc/bind/zones.local.any";
+    include "/etc/bind/zones.local.private";
+};
+</file>
+Mentre nel file **''/etc/bind/zones.local.private''** si definisce la zona e il master autorizzato alle notify:
+<file>
+zone "rigacci.net" {
+    type slave;
+    masters { 192.168.2.2; };
+    file "slave/rigacci.net.private";
+};
+</file>
+**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
+; Refresh
+; Retry
+        2419200 ; Expire
+; 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**.