rigacci.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Bind DNS server ======

===== lame server resolving =====

//I have been getting a lot of these "lame server resolving" floods. From my research these are when soemone is trying to do dns lookups on ips etc that are not setup corretly with DNS. Is there a way to restrict DNS lookups to the IPs on my box only so these type of floods do not occur?//

The error messages you're seeing are harmless and not the result of an attack or anything like that. if you don't want to see them, add the following to your named.conf:

<file>
logging {
    category lame-servers {null;};
};
</file>

the problem is that your name server is trying to resolve a domain which has incorrectly configured name servers. restricting your name server in the way you mentioned would prevent you from using your server to look up remote IP addresses. unless your machine is configured (/etc/resolv.conf) to use an additional name server, you don't want to do this. you can however restrict outside machines from using your server to resolve domains for which your server is not authoritative.

to do this, add the following to your ''**named.conf**'':

<file>
acl localip { 127.0.0.1; aaa.bbb.ccc.ddd; };
// replace aaa.bbb.ccc.ddd with your server's IP address.
// if you have multiple IP addresses, you should add them all, separated by semi-colons
options {
    allow-transfer {localip;};
    allow-recursion {localip;};
}
</file>

===== Dynamic DNS zones =====

How to set a dynamic zone in your DNS server; in your **''/etc/bind/named.conf.local''** declare the zone, who is allowed to update, who is allowed to do a zone transfer and the name of the zone file:

<file>
zone "dyn.rigacci.org" {
    type master;
    allow-update { 127.0.0.1; };
    allow-transfer { 127.0.0.1; 217.19.150.6; 217.19.150.16; };
    file "dyn.rigacci.org";
    max-journal-size 150k;
};
</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. After that, the //thaw// command is required (this will also remove the journal file):

<code>
rndc freeze dyn.rigacci.org
rndc thaw dyn.rigacci.org
</code>

This is my script to remove all the journal files:

<code bash>
#!/bin/sh
# Purge the journal of dynamic DNS zones.

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
find /var/cache/bind/ -type f -name "*.jnl" | while read LINE; do
    DOMAIN="$(basename $LINE | sed 's/\.jnl$//')"
    rndc freeze "$DOMAIN"
    rndc thaw "$DOMAIN"
done
</code>

The journal file will grow on the slave DNS server too; the freeze command cannot be used because the zone is not on this server:

<code>
rndc freeze dyn.rigacci.org
rndc: 'freeze' failed: not found
</code>

On the slave server we must use the **retransfer** command:

<code>
rndc retransfer dyn.rigacci.org
</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
          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**.