Voici le rapide et le sale: sur BIND9 avec une zone dynamique partagée entre les vues , faire une mise à jour, la mise à jour / création / suppression d'un enregistrement fonctionnera bien si je demande cet enregistrement à un client qui tombe dans la même vue que j'ai fait la nsupdate de.
L'interrogation à partir d'une vue qui n'est pas la même que celle que j'ai utilisée pour nsupdate lancera NXDOMAIN (si vous ajoutez un nouvel enregistrement) ou affichera les anciennes informations d'enregistrement en cas de changement / mise à jour jusqu'à une durée arbitraire (disons 15 minutes) passe, ou je le fais de force $ rndc freeze && rndc thaw
. $ rndc sync
ne semble rien faire du tout pour résoudre le problème - j'espérais que ce n'était qu'un problème de fichier journal car les vidages de journal sont documentés pour vider environ 15 minutes.
Si ce n'est pas clair, voici un pseudo-code pour commencer:
Lier les vues
view "cdn-redir" {
match-clients { 10.1.1.0/24; 10.1.2.0/24; };
include "cdn-zone.db";
include "dynamic-zone.db";
};
view "default" {
match-clients { any; };
include "dynamic-zone.db";
};
Exemple de ligne de commande
user@ns:~$ nsupdate -k rndc.key
> server localhost
> zone example.com.
> update add foohost.example.com. 600 A 10.5.6.7
> send
> quit
user@ns:~$ dig foohost.example.com (resolv.conf points to 127.0.0.1)
[ responds with correct answer 10.5.6.7 ]
Ailleurs, un hôte tombant dans la même vue que le nsupdate
user@10.11.12.50:~$ foohost.example.com (resolv.conf points to above nameserver)
[ responds with correct answer 10.5.6.7 ]
Ailleurs, l'hôte tombe dans une vue différente en tant que nsupdate
user@10.1.1.50:~$ dig foohost.example.com (resolv.conf points to above nameserver)
[ responds with NXDOMAIN even though I'm asking the same server ]
À ce stade, si je suis patient, le problème finira par se résoudre lui-même (peut-être 15 minutes), mais je n'ai souvent pas le luxe de la patience, donc je suis obligé de $ rndc freeze && rndc thaw
sur le serveur de noms pour résoudre le problème de force.
D'un autre côté
Du côté parfaitement inversé des choses, si je fais la mise à jour contre le serveur à partir d'une adresse qui tombe dans la vue "cdn-redir", le problème s'inverse. Les requêtes ultérieures des clients correspondant à "cdn-redir" obtiennent l'enregistrement correct immédiatement après nsupdate sans jouer avec "rndc freeze / thaw", mais les requêtes provenant d'adresses qui ne sont pas dans la vue de "cdn-redir" ont désormais la silliness delay / rndc.
Ma question ultime
Si c'était aussi simple que 42, je le prendrais à bras ouverts ...
Je voudrais éviter d'avoir à "geler rndc & & décongeler rndc" de peur de manquer une mise à jour dynamique du serveur DHCP. Quelqu'un sait-il comment synchroniser les enregistrements mis à jour entre les vues de manière plus efficace / efficiente, ou peut-il éclairer où je peux me tromper?
Edit: BIND 9.9.5 / Ubuntu 14.04 mais cela s'est produit sur les versions précédentes d'Ubuntu et de BIND.
Merci a tous!
Comme l'a demandé Andrew B , voici la zone expurgée (et partielle):
$ORIGIN .
$TTL 3600
example.com IN SOA ns1.example.com. HOSTMASTER.example.com. (
2009025039 ; serial
900 ; refresh 15
600 ; retry 10
86400 ; expire 1 day
900 ; minimum 15 min
)
NS ns1.example.com.
$ORIGIN example.com.
$TTL 30
AEGIS A 10.2.1.60
TXT "31bdb9b3dec929e051f778dda5abd0dfc7"
$TTL 86400
ts-router A 10.1.1.1
A 10.1.2.1
A 10.1.3.1
A 10.1.4.1
A 10.1.5.1
A 10.1.6.1
A 10.1.7.1
A 10.1.8.1
A 10.2.1.1
A 10.2.2.1
A 10.2.3.1
ts-server A 10.2.1.20
ts-squid0 A 10.2.2.20
ts-squid1 A 10.2.2.21
$TTL 600
tssw4 A 10.2.3.4
tssw5 A 10.2.3.5
tssw6 A 10.2.3.6
tssw7 A 10.2.3.7
; wash rinse repeat for more hosts
$TTL 30
wintermute A 10.2.1.61
TXT "003f141e5bcd3fc86954ac559e8a55700"
zone
déclaration parce que mes pensées allaient dans une direction similaire à celle de Håkan.
server
au lieu de local external-ip-address
consulterait le MNAME de la zone (dans le SOA de la zone) et pourrait vous emmener ailleurs vers un autre serveur de noms pour faire votre mise à jour DNS (en particulier si vous êtes caché-maître / public-esclave ou topologie de réseau maître furtif).