Bonjour,
dans les versions un peu anciennes de Debian, on pouvait spécifier des DNS différents en utilisant le paramètre dns-nameservers pour chaque interface dans /etc/network/interfaces
Mais avec les Debian plus récentes, j'ai comme l'impression que ça ne fonctionne plus.
En pratique:
- il ne tient pas compte de ce paramètre
- si je ne spécifie rien dans /etc/resolv.conf, la résolution de nom, il essaye sur localhost en ipv4 puis ipv6 puis timeout.
- le paramètre n'est pas mentionné dans la page de man
Ça n'existe plus ?
# network-manager / wicd / connman
Posté par NeoX . Évalué à 1.
[^] # Re: network-manager / wicd / connman
Posté par defmonkey . Évalué à 3.
- je suis sur un serveur avec des ip fixes et je fuis les interfaces graphiques (le X11 forwarding à travers ssh sur une connection 1Mo, non merci)
- par pitié, pas de NM sur un serveur, c'est déjà assez compliqué comme ça
Donc comme je n'utilise pas network-manager/wicd/connman, je ne sais toujours pas comment je fais ;)
[^] # Re: network-manager / wicd / connman
Posté par NeoX . Évalué à 2.
2°) configure tes IP fixes sur tes interfaces
etrangement je ne sais pas d'ou tu sors ton dns-nameserver dans le fichier interface, mais d'apres le wiki debian
http://wiki.debian.org/NetworkConfiguration
ca n'existe pas
là ou ca existe c'est sur un serveur DHCP, dans la configuration des pools d'adresses pour fournir un DNS different selon les plages IPs delivrées.
[^] # Re: network-manager / wicd / connman
Posté par defmonkey . Évalué à 1.
Et je n'ai pas de DHCP, que des IP fixes
# resolvconf
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
# aptitude install resolvconf
Ce paquet gère /etc/resolv.conf en s'interfaçant avec plein de trucs qui voudraient le manipuler. Il n'est pas installé par défaut : sans lui, ton /etc/resolv.conf ne bougera pas, en tout cas pas sur demande de ifup d'après les options que tu mets dans /etc/network/interfaces.
Concrètement, concernant /etc/network/interfaces, resolvconf s'accroche dans /etc/network/if-{up,down}.d et interprète les clauses dns-* que tu mets dans /etc/network/interfaces. Sans resolvconf, ces clauses sont lettre morte.
# Berlue
Posté par Kerro . Évalué à 4.
Tu peux soit modifier le script d'initialisation (en repiquant le code d'Etch par exemple) ou ajouter une ligne "up" ou encore, comme indiqué plus haut, utiliser le fichiers if-up.
Attribuer un dns à une carte réseau, ça n'a pas de sens. Lorsque la machine souhaite résoudre un nom, selon quel critère pourrait-elle choisir la carte réseau ?
Par contre cela pourrait être utile avec des interfaces volatiles. Par exemple une connexion PPP provoque un changement de dns (changement, pas ajout). Ca se fait depuis longtemps d'ailleurs.
[^] # Re: Berlue
Posté par defmonkey . Évalué à 0.
On peut vouloir choisir son adresse source pour une résolution (par exemple avec l'option -b de dig ), pourquoi ne pas vouloir utiliser des DNS différents selon l'interface ? Autant ça n'a généralement pas de sens pour les applications desktop, autant pour une machine avec plusieurs interfaces qui fait du routage entre différents réseaux ça peut en avoir.
[^] # Re: Berlue
Posté par Kerro . Évalué à 3.
Le seul critère qui tienne à ce niveau, c'est que tu souhaites interroger un DNS spécifique en fonction du nom de domaine. Ca ne se règle pas au niveau de l'interface car c'est simplement du routage. Ca fonctionne même avec une seule interface.
[^] # Re: Berlue
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Disons que ça en a rarement. En revanche, associer l'utilisation de serveurs de résolution DNS donnés à une interface donnée, ça en a, dans la mesure où ils sont considérés comme fournis avec la connexion.
[^] # Re: Berlue
Posté par netsurfeur . Évalué à 2.
Par contre, imaginer, comme le suggère defmonkey, qu'on peut puisse avoir simultanément plusieurs DNS actifs simultanément et liés à des cartes réseau n'a pas de sens. Si la machine doit résoudre www.example.com, sur quel critère choisit-elle le DNS (et l'interface réseau) à interroger ?
[^] # Re: Berlue
Posté par Kerro . Évalué à 2.
Ca ne fait que la troisième fois que la question est posée :-)
Sans réponse à cette question, il est juste impossible d'avoir un DNS par carte réseau (ce qui d'ailleurs je _suppose_ n'existe pas).
Ca pourrait être utilisé dans des cas tordus. Par exemple on sait d'avance que l'extension .private sera résolue par le DNS situé sur un réseau relié à l'interface eth3. Mais même dans ce cas, le routage de base se charge d'envoyer les paquets au bon endroit. Pas besoin de bricoler.
Après on peut compliquer, mais ça devient une configuration vraiment particulière, et il est probable qu'iptable soit de la partie.
[^] # Re: Berlue
Posté par netsurfeur . Évalué à 1.
Sans réponse à cette question, il est juste impossible d'avoir un DNS par carte réseau (ce qui d'ailleurs je _suppose_ n'existe pas).
Tout à fait d'accord. C'est bien sur ce point que je voulais insister.
Ca pourrait être utilisé dans des cas tordus. Par exemple on sait d'avance que l'extension .private sera résolue par le DNS situé sur un réseau relié à l'interface eth3.
Ça dépasse largement les possibilités du résolveur DNS de la libc.
Pour faire ce genre de chose, on aurait plutôt un serveur DNS local qui, en fonction du domaine, contacterait un serveur DNS différent (serveur DNS interne pour .private, externe pour les autres domaines).
Mais dans ce cas, plus besoin de définir des DNS par interface puisque le "nameserver" est toujours 127.0.0.1.
[^] # Re: Berlue
Posté par Kerro . Évalué à 2.
En cas de DNS local à la machine, il est courant qu'il contacte certains DNS précis en fonction du domaine. Le cas courant est le DNS dynamique interne à l'entreprise, bien souvent un contrôleur de domaine Microsoft.
Mais encore une fois, c'est la couche de routage qui fait le travail. Si le DNS en question est sur le réseau interne, les paquets seront envoyés via la carte réseau correspondante.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.