Bonjour @Zargos
Oui, tu me taquines. Oui je me suis mal exprimé. J’ai un DNS SEC, là où il y a / pour mes zones « type master » et donc, j’ai plusieurs autres serveurs DNS qui récupérent les zones « masters » qui sont déjà « encodées ».
Mais quand je n’ai plus d’internet (chez moi), mon serveur DNS LAN qui récupére les zones qui (elles) sont à jour (de la « journée »), mon serveur ne retourne « rien » et cela même en local (depuis la même machine).
Et bien non, il est configuré vers les « dns.google » comme forwardeur.
Peut-être que tu me parlais @Zargos de ce type de configuration (que je ne connaissais pas) :
Sécuriser un serveur de nom
Certains services proposés par les ISP ne sont accessibles que par l’utilisation de leur DNS. Ainsi, pour accéder aux news ou lire son mail par l’interface webmail de Wanadoo, il faut utiliser le DNS spécifié sur la feuille indiquant le login/password ou donné par le serveur DHCP.
zone "wanadoo.fr"
{
type forward;
forwarders { 193.252.19.3; };
};
NB: Wanadoo filtre les IP accédant aux DNS, serveurs web,… réservés aux abonnés…
Ma configuration DNS est celle-ci – exactement – sans la configuration des zones DNSSEC.
Fichier /etc/bind/name.conf.options du « master/autoritaire » et des « slaves/secondaires ».
options {
[...]
dnssec-enable yes; // yes | no | auto
dnssec-validation yes; // yes | no | auto
dnssec-lookaside . trust-anchor dlv.isc.org.; // yes | no | auto
[...]
forwarders {
2001:4860:4860::8888;
8.8.8.8;
2001:4860:4860::8844;
8.4.8.4;
};
[...]
};
Fichier /etc/bind/name.conf.local du « master/authoritaire ».
zone "domain.tld" {
type master;
file "/etc/bind/masters/domain.tld.hosts.signed";
allow-transfer { key "ns-dns"; }; # la clef pour les transferts entre serveurs
allow-update { key "ns-dns"; }; # la clef pour les nsupdate entre serveurs
notify yes;
};
Fichier /etc/bind/name.conf.local du « slave/non autoritaire ».
zone "domain.tld" {
type slave;
file "/etc/bind/slaves/domain.tld.hosts";
masterfile-format text;
masters { 2607:5300:60:9389:15:1:a:1000; };
notify master-only;
// notify yes;
};
Et le(s) fichier(s) « /etc/bind/slaves/domain.tld.hosts » sur le « slaves/secondaire » est bien encrypté.
Donc, je me suis dis que cela devait être lié aux variables/valeurs de dnssec-validation/lookaside mais sans succès (en configurant dnssec-enable no; par exemple).
Je me suis dis, après, que, vu que les fichiers sur les secondaires sont « encodés/cryptés » que cela était logique/normal puisque que le serveur DNS ne pouvait pas vérifier par rapport à la « Delegation Signer (DS) » → si les clefs → ZSK (Zone Signing Key) et KSK (Key Signing Key) seraient oui ou non valident.
RienÀVoir : zw3b.eu | DNSViz 
PS : Il faut que j’ajoute (sur mon tuto), la partie DANE (DNS - based Authentication of Named Entities) sur champs TLSA Transport Layer Security Authentication) 
Et ce sera bien mieux 
La validation par PKIX (Public-Key Infrastructure X.509) je ne connais pas - comme par exemple sur l’entité « www » du domaine « bortzmeyer.org »
Visible depuis son « explorateur HTTP » grâce au plugin FireFox DNSSEC/DANE Validator.
Salutations,
Romain
