À quoi servent 0.in-addr.arpa et 255.in-addr.arpa dans la configuration par défaut de bind?

J'ai Ubuntu 16 LTS

À quoi servent les zones 0.in-addr.arpa et 255.in-addr.arpa dans la configuration par défaut de bind? ( named.conf.default-zones)

Je pose la question ici car je pense que ces fichiers de zone sont communs à tous les packages de bind sur diverses distributions GNU / Linux, et non spécifiques à Ubuntu.

linux networking dns bind Bulat M.
la source

Ils sont communs aux packages BIND pour tous les systèmes d'exploitation, pas seulement Linux.

Alnitak

Réponses:

Le but des zones locales par défaut dans BIND est d'empêcher les requêtes pour ces plages IP de fuir sur Internet global et de réduire la charge sur les serveurs de noms racine, conformément à la RFC 6303 "Zones DNS desservies localement" .

De l'introduction à ce RFC:

Cette recommandation est faite parce que les données ont montré qu'une fuite importante de requêtes pour ces espaces de noms se produit, malgré les instructions pour les restreindre, et parce qu'il est donc devenu nécessaire de déployer des serveurs de noms sacrificiels pour protéger les
serveurs de noms parents immédiats de ces zones contre les requêtes excessives et involontaires. charger [AS112] [RFC6304] [RFC6305]. On s'attend à ce que la charge des requêtes continue d'augmenter à moins que les étapes ne soient prises comme indiqué ici.

De plus, les requêtes des clients derrière des pare-feu mal configurés qui autorisent les requêtes sortantes pour ces espaces de noms, mais suppriment les réponses, mettent une charge importante sur les serveurs racine (les zones directes mais pas les zones inverses sont configurées). Ils provoquent également une charge opérationnelle pour les opérateurs de serveur racine, car ils doivent répondre aux demandes de renseignements sur les raisons pour lesquelles les serveurs racine «attaquent» ces clients.

Cela devrait être considéré comme la référence définitive, notamment parce que le RFC a été écrit par Mark Andrews, l'un des principaux développeurs travaillant sur BIND.

Voir également le registre IANA des zones desservies localement , qui contient la liste de toutes les zones (inversées) qui devraient être desservies comme ceci.

Depuis la sortie de BIND 9.9 en 2011, BIND9 crée automatiquement les zones locales par défaut au démarrage, sauf s'il est explicitement désactivé avec l' empty-zones-enableindicateur dans le named.conffichier.

Le registre IANA est suivi par ISC et de nouvelles entrées ajoutées aux sources BIND actuelles au fur et à mesure qu'elles apparaissent.

Alnitak
la source

Vous avez donc dit la même chose que ma réponse mais d'une manière différente, mais ma réponse est "obsolète"?

Darren

@Alnitak, donc on devrait inclure ces zones dans BIND, afin qu'il puisse gérer de telles requêtes sans les transférer aux serveurs racine?

Bulat M.

@BulatM. avec les versions modernes de BIND, cela ne devrait pas être nécessaire - elles seront activées automatiquement au démarrage, sauf si elles ont été désactivées par votre package de distribution avec le empty-zones-enableparamètre in named.conf. La liste des zones vides devrait apparaître dans votre sortie syslog au démarrage de BIND.

Alnitak

@BulatM. la création automatique de zones locales par défaut était introduite dans BIND 9.9, en 2011, BTW.

Alnitak

@BulatM. dépend de la version de BIND - si c'est 9.9 ou une version ultérieure, cela n'est pas nécessaire include.

Alnitak

Ceci à partir d' ici (une page MS, mais toujours pertinente):

Les zones de recherche inversée permettent au serveur DNS de faire autorité, c'est-à-dire de connaître la réponse à l'avance et de répondre immédiatement aux requêtes de noms les plus courantes, éliminant ainsi les requêtes récursives inutiles. Conformément aux demandes de commentaires (RFC) pertinentes, par défaut, le serveur DNS fait autorité pour trois zones de recherche inversée:
0.in-addr.arpa (0.0.0.0)

127.in-addr.arpa (127.0.0.1 - loopback)

255.in-addr.arpa (255. 255. 255. 255 - broadcast)

En d'autres termes; le serveur DNS n'interrogera pas un serveur DNS basé sur Internet pour ces adresses (car ce sont toutes des adresses locales).

Darren
la source

@BulatM .: Je ne pense pas que quiconque le ferait délibérément, mais de telles adresses peuvent être capturées dans un outil à usage plus général, ou cela peut arriver par accident. Quand c'est le cas, vous voulez les résultats corrects. Alors pourquoi ne pas implémenter cela?

Courses de légèreté en orbite le

@BulatM .: Je pense que vous regardez cela à l'envers. Vous essayez de trouver un cas d'utilisation. Au lieu de cela, nous faisons les choses correctement par spécification, puis tous les cas d'utilisation imaginables et inconcevables sont couverts par défaut.

Courses de légèreté en orbite du

Mais il est parfaitement raisonnable d'avoir par exemple un outil qui vous montre tous les processus d'écoute sur votre PC et les ports, les adresses IP auxquelles ils sont liés et le nom d'hôte rDNS correspondant . Un tel outil essaiera très souvent de trouver le nom d'hôte pour "127.0.0.1", "0.0.0.0" etc. Et ce n'est que le premier exemple que j'ai trouvé.

Josef dit Réintégrer Monica le

"assez souvent" est un peu un euphémisme. Jusqu'à 7% du trafic total arrivant sur certains serveurs racine consiste en des requêtes inverses pour des adresses IP privées, et une infrastructure de routage complète (AS112) a été construite juste pour gérer ce problème

Calimo

@Darren il est obsolète car la liste des zones recommandées par l'IETF et maintenue par l'IANA contient environ 30 entrées, pas seulement les 3 mentionnées par Microsoft. Ce sujet particulier a beaucoup changé récemment, et les liens que j'ai inclus dans ma réponse sont les références définitives. Je ne peux pas répondre pour les autres résolveurs populaires, mais BIND le fait par défaut pour toute la liste IANA.

Alnitak