DNS: error (FORMERR) resolving '$SOMETHING': xx.xx.xx.xx#53

Nel log /var/log/daemon.log apparivano diverse segnalazioni simili a questa:

Jul 31 09:01:27 server named[29883]: error (FORMERR) resolving '$SOMETHING': xx.xx.xx.xx#53

Qualche DNS risponde in maniera errata ad una interrogazione.

Il log puo' essere ignorato ed eventualmente disabilitato inserendo quanto segue nel file named.conf.local:

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

DNS: generazione chiave rndc per aggiornamenti dinamici

Lanciare il comando:

rndc-confgen -a -c /etc/bind/rndc.key

se il comando precedente si dovesse bloccare (normalmente termina quasi istantaneamente) lanciate il comando seguente:

rndc-confgen -r /dev/urandom -a  -c /etc/bind/rndc.key

Bind9 Error : named[....]: network unreachable resolving ...

named[8660]: network unreachable resolving 'zd.somedomain.org/AAAA/IN': 2001:500:f::1#53

Questo errore ripetuto nei log di sistema e' dovuto al fatto che per default, bind utilizza anche IPv6.

Per disabilitare questa caratteristica bisogna editare il file

/etc/default/bind9

e aggiungere

-4

alle opzioni, ottenendo:

OPTIONS="-4 -u named"

Completare la procedura facendo ripartire il servizio bind.

BIND+DHCP: gli aggiornamenti dinamici del DNS non funzionano

Se gli aggiornamenti dinamici del DNS non funzionano, controllate se nel file /var/log/daemon.log trovate qualcosa di simile a quanto segue:

Jun 27 22:27:26 milhouse named[3278]: /etc/bind/zones/db.simpson.jnl: open: permission denied
Jun 27 22:27:26 milhouse named[3278]: client 192.168.2.130#40535: updating zone 'corimtec.mylan/IN': error: journal open failed: unexpected error
Jun 27 22:27:26 milhouse dhcpd: Forward map from bart.simpson.local. to 192.168.2.162 FAILED: SERVFAIL

Per risolvere questo problema occorre verificare i permessi del file .jnl (nell'esempio /etc/bind/zones/db.simpson.jnl).

Nel nostro caso l'utente bind non aveva accesso in scrittura sul file .jnl

-rw-r--r-- 1 root bind 5951774 Jun 27 22:42 /etc/bind/zones/db.simpson.jnl

Basta assegnare l'apposito permesso con il comando

chmod 664 /etc/bind/zones/db.simpson.jnl

Ottenendo quindi:

-rw-rw-r-- 1 root bind 5951774 Jun 27 22:42 /etc/bind/zones/db.simpson.jnl

DNS: too many timeouts resolving '$OUTER_DOMAIN/A' (in '$URL'?): reducing the advertised EDNS UDP packet size to 512 octets

Se ricevete nei log tonnellate di messaggi simile al seguente:

Jun 13 12:10:31 $SERVER_NAME named[2604]: too many timeouts resolving '$OUTER_DOMAIN/A' (in '$URL'?): reducing the advertised EDNS UDP packet size to 512 octets

potete disabilitare il logging di EDNS inserendo nel vostro named.conf:

logging {

            category edns-disabled { null; };

        };

named[...]: network unreachable resolving

Se sul log vedete delle righe del genere (logwatch me le manda tutti i giorni all'alba):

named[9217]: network unreachable resolving 'www.google.com/A/IN': 2001:500:2f::f#53
named[9217]: network unreachable resolving 'www.google.com.localdomain.net/AAAA/IN': 001:dc3::35#53

il problema sta nel protocollo IPv6, se non lo usate potete modificare i parametri di lancio del vostro server DNS. Su debian la modifica va fatta nel file

/etc/default/bind9

sostituendo la riga:

OPTIONS="-u bind"

con la riga

OPTIONS="-4 -u bind"

Fate ripartire il vostro server DNS e i vostri log (ma soprattutto l'addetto al loro monitoraggio) ve ne saranno grati.

Pulire la cache del DNS

Voi sapete che l'IP address di un server e' x.x.x.x ma la vostra macchina sostiene che sia y.y.y.y?
Potete farla ragionare eseguendo un flush della cache del DNS:

Windows:

ipconfig /flushdns

Linux con bind:

rndc flush

Linux con ncsd:

/etc/init.d/nscd restart

e se non funzionasse

/etc/init.d/nscd reload

Linux con dnsmasq:

/etc/init.d/dnsmasq restart

Errore: Has an A record but no DHCID, not mine.

Lo scenario e' costituito da una subnet con DHCP che aggiorna dinamicamente il DNS ad ogni rinnovo di indirizzo IP.

Il meccanismo funzionava perfettamente per tutti gli host della subnet tranne uno: riceveva correttamente un indirizzo IP, pero' il DNS non veniva aggiornato. Il file /var/log/daemon.log conteneva questo errore:
Mar 16 20:29:05 server dhcpd: Forward map from hostname.domain.local. to 10.1.1.123 FAILED: Has an A record but no DHCID, not mine.
Ho trovato diverse soluzioni proposte, ma non la piu' ovvia (almeno in questo caso): esisteva infatti una definizione statica di hostname.domain.local nelle zone forward e reverse del DNS.

Soluzione:

SUL SERVER DNS

rndc freeze domain.local
rndc freeze 1.1.10.in-addr.arpa
vi /etc/bind/zones/db.domain.local (e rimuovere la linea contenente hostname.domain.local)
vi /etc/bind/zones/db.10.1.1 (e rimuovere la linea contenente hostname.domain.local)
rndc unfreeze domain.local
rndc unfreeze 1.1.10.in-addr.arpa

SUL CLIENT HOSTNAME.DOMAIN.LOCAL

dhclient
nslookup hostname.domain.local (se e' tutto ok, dovrebbe risultare l'indirizzo IP assegnato dal comando dhclient)

bind9: dumping master file:...open: permission denied

Scenario:

1 server DNS primario e 1 server DNS secondario (entrambi basati su bind9)
Il master parte correttamente.
lo slave non parte e i log evidenziano un errore del genere:

Jan 31 17:42:41.799 dumping master file: /etc/named/tmp-XXXX2RSNyT: open: permission denied
Jan 31 17:42:41.799 transfer of 'mydomain.com/IN' from 192.168.3.1#53: failed while receiving responses: permission denied

Significa che lo slave ha iniziato il trasferimento delle zone dal master, pero' non riesce a scrivere i relativi file.

Soluzione:

Probabilmente avete configurato named.conf (o named.conf.local) tenendo le zone per cui il server e' slave nella stessa directory in cui tenete le zone statiche (127, ecc). Ebbene cio' e' male.
Meglio creare una directory apposita e darle i permessi giusti. Ad esempio:

mkdir /etc/bind/zones
chown bind.bind /etc/bind/zones

Ricordatevi di correggere il path dei file delle zone dinamiche per farli puntare alla nuova directory.
Rilanciate il servizio:

/etc/init.d/bind9 start

L'errore dovrebbe essere sparito.