DNS "vues" et contrôle des transferts de zone avec TSIG

Running Bind 9.8.2. J'ai réussi à configurer les keys TSIG pour "vues" à l'aide d'une paire maître / server DNS. Les transferts de zones fonctionnent comme prévu entre les 2 servers pour chaque vue. Avant d'entrer en production avec cela, j'ai besoin de quelques éclaircissements sur quelques choses. Nos servers prod permettent également des transferts de zones à quelques autres servers en plus du server esclave. Nous avons une configuration acl qui ressemble à ceci:

other_xfer_allowed { xxxx; // This is our Secondary DNS server 127.0.0.1; // localhost can make zone transfers xxxx/24; // Corporate server farm range is allowed to make zone-transfers xxxx/24; // NAT pool for internal DNS server Zone Transfers }; // end of "other_xfer_allowed" ACL 

Et dans la déclaration "allow transfer", nous avons inclus cette ACL. Ma question est:

Maintenant que nous utilisons TSIG, dois-je get avec les administrateurs de tous ces autres servers et leur fournir ma key TSIG afin qu'ils puissent requestr des transferts de zone? Je penserais que quelque chose comme ça doit être fait car il fallait configurer sur un server esclave, mais je ne suis pas sûr.

Prochain,

J'ai configuré les vues afin que les clients sur le réseau "interne" lors de la request d'un logging soient présentés avec des loggings différents que les clients à l'extérieur. Et pour le moment, il n'y a qu'une seule zone qui requirejs des loggings différents. Cependant, je crois comprendre que, étant donné que les vues sont basées sur les sources d'adresses IP, si j'avais seulement inclus cette zone dans ma vue "interne", si un logging avait été demandé pour une autre zone à partir de cette même adresse IP, ils obtiendraient probablement un ndomaine réponse puisque cette adresse IP est limitée à cette seule vue.

Donc, ma question est, dois-je inclure toutes les zones dans les deux vues afin que tous les clients puissent get des résultats, même si je n'aurais (une) actuellement qu'une zone qui pointe vers deux files de zone différents? Tous les autres dans les deux points indiquent le même file de zone, à less bien sûr, il existe une autre zone dont nous devons présenter une vue différente pour les clients internes.

Maintenant, dernière question.

Je me préoccupe de l'instruction allow-query. Sur notre server de production, nous avons une list ACL, nous l'appelons «autorisé». Nous avons une instruction de requête autorisée dans les options globales pour autoriser uniquement les requêtes des IP dans la LCA autorisée. Cependant, toutes les inputs de notre zone dans le file Conf ont également une déclaration "allow-query {any;};." Cette règle ne conteste-t-elle pas le but d'avoir une ACL "autorisée" pour les requêtes? Est-ce que cette mauvaise design? la déclaration de zone a-t-elle l'importance de la déclaration globale?

Maintenant que nous utilisons TSIG, dois-je get avec les administrateurs de tous ces autres servers et leur fournir ma key TSIG afin qu'ils puissent requestr des transferts de zone? Je penserais que quelque chose comme ça doit être fait car il fallait configurer sur un server esclave, mais je ne suis pas sûr.

Tout d'abord, en ce qui concerne "leur fournir ma key TSIG": Non, il n'a pas beaucoup de sens de générer une seule key et de la partager avec toutes les personnes impliquées dans votre configuration.
Je dirais que créer une key par partie, vous pouvez avoir autant de keys que vous voulez après tout. De cette façon, vous pouvez donner un access différent aux différentes parties et révoquer l'access d'une partie sans révoquer l'access de tous.

En outre, l'utilisation de TSIG pour certaines choses n'implique pas nécessairement l'utilisation de TSIG pour toutes les choses (bien qu'il soit souvent préférable), il est possible de combiner le contrôle d'access basé sur IP et basé sur les keys si cela fonctionne pour votre scénario.

Donc, ma question est, dois-je inclure toutes les zones dans les deux vues afin que tous les clients puissent get des résultats, même si je n'aurais (une) actuellement qu'une zone qui pointe vers deux files de zone différents? Tous les autres dans les deux points indiquent le même file de zone, à less bien sûr, il existe une autre zone dont nous devons présenter une vue différente pour les clients internes.

Chaque requête n'atteindra qu'une seule vue (la première vue qui correspond).
L'implication est que si datatables ne sont pas disponibles dans la vue qu'un client accède à leurs requêtes, soit dans une zone dans cette vue, soit par une récursivité (si la récursivité est disponible pour le client et elle le request), ils ne peuvent pas y parvenir Les données.

Il est tout à fait possible que vous ayez besoin de plus de zones doublées entre les vues.

Je me préoccupe de l'instruction allow-query. Sur notre server de production, nous avons une list ACL, nous l'appelons «autorisé». Nous avons une instruction de requête autorisée dans les options globales pour autoriser uniquement les requêtes des IP dans la LCA autorisée. Cependant, toutes les inputs de notre zone dans le file Conf ont également une déclaration "allow-query {any;};." Cette règle ne conteste-t-elle pas le but d'avoir une ACL "autorisée" pour les requêtes? Est-ce que cette mauvaise design? la déclaration de zone a-t-elle l'importance de la déclaration globale?

Oui, une allow-query spécifiée dans une zone annulera la valeur globale allow-query permise. Pour les requêtes qui correspondent à vos zones, cela signifie que le paramètre global n'est pas utilisé, mais si la récursivité est activée, vous rencontrez également des requêtes qui ne correspondent à aucune de vos zones.

Voir les parameters allow-* dans le manuel pour savoir comment ces parameters interagissent.