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:

logging {
    category lame-servers {null;};
};

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:

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;};
}

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:

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;
};

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):

rndc freeze dyn.rigacci.org
rndc thaw dyn.rigacci.org

This is my script to remove all the journal files:

#!/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

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:

rndc freeze dyn.rigacci.org
rndc: 'freeze' failed: not found

On the slave server we must use the retransfer command:

rndc retransfer dyn.rigacci.org

Come configurare un server DNS con una vista privata e inoltrare le notify ad uno slave.

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:

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";
};

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:

zone "rigacci.net" {
    type master;
    file "rigacci.net.private";
    allow-transfer { 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:

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";
};

Mentre nel file /etc/bind/zones.local.private si definisce la zona e il master autorizzato alle notify:

zone "rigacci.net" {
    type slave;
    masters { 192.168.2.2; };
    file "slave/rigacci.net.private";
};

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.

È 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 @:

@    IN    TXT  "v=spf1 a:mail.rigacci.org a:relay.rigacci.org -all"
@    IN    TXT  "MS=D2583632ADEB1D213E1E997767A33E70D2583632"

Diventa complicato invece indicare un TTL specifico per ciascun record. Sembra infatti che la direttiva specificata sulla singola riga NON VIENE RISPETTATA:

; The 3600 TTL specification does not work!
@    3600    IN    TXT  "MS=D2583632ADEB1D213E1E997767A33E70D2583632"

Verificando con dig

dig @localhost -t TXT rigacci.org

si scopre che il TTL vale 43200:

;; 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"

Il motivo è che esiste una dichiarazione $TTL al top level del file di zona:

$TTL 43200
@    IN    SOA    ns1.rigacci.org.  postmaster.rigacci.org. (
     2019030701 ; Serial
          43200 ; Refresh
           7200 ; Retry
        2419200 ; Expire
          43200 ; Default TTL
)

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.