l'illustre Daniel Cordey a dit un jour,
> On Friday 10 September 2004 13:43, Magnus wrote:
>
>> De toute fa�on ce service doit �tre atteignable, la
>> limitation en fonction du port source a-t-elle vraiment
>> un
>> sens?
>
> Non, pas a mes yeux...
>
>> Le serveur doit de toute fa�on �tre d�mar� en root pour
>> "binder" le port 53, mais il doit le rester s'il veut
>> envoyer des donn�es avec un port source privil�gi� (ma
>> premi�re question reste). Sinon il peut changer
>> d'utilisateur).
>
> Oups, j'ai oublie... le serveur demarre en root, "bind" le
> port 53, puis
> change son UID (real !). De plus, on peut le tourner en
> "chroot". Le nom de
> l'utilisateur sous lequel il tourne se configure dans le
> named.conf. Par
> contre, les adresses IP et les ports se configure dans les
> fichiers de zones.
> Par exemple, l'un des fichier "externe" chez MJT est :
>
> acl slave-servers {
> 212.74.77.22;
> 194.88.9.21;
> };
>
>
> view "external" {
>
> allow-transfer { slave-servers; };
> notify-source 194.88.9.23 port 53;
>
> recursion no;
>
> zone "mjt.ch" {
> type master;
> file "/master/mjt.external.zone";
> };
>
> zone "mjtsa.com" {
> type master;
> file "/master/mjtsa.external.zone";
> };
>
> zone "9.88.194.in-addr.arpa" {
> type master;
> file "/master/194.88.9.external.rev";
> };
> };
>
> On voit donc que l'on peut "binder" le serveur sur une
> adresse IP qui est en
> fait un alias et que l'on peut mettre ce que l'on veut
> comme port.
>
>> En r�fl�chissant un peu, on peut se dire que les clients
>> "normaux" utiliseront un port non-privil�gi� comme
>> source
>> et un autre bind, pour par exemple effectuer un
>> transfer,
>> utiliserait le port 53 en source... D'une fa�on
>> g�n�rale,
>> c'est au d�mon bind de d�finir qui a le droit � un
>> service
>> diff�rent.
>
> Il faut que tous les autres systemes sachent qu'ils
> doivent effectuer leurs
> requetes sur ce port... donc valable seulement pour des
> systemes configures
> comme tel.
ben il y a juste � choisir entre udp et tcp: un
utilisateur (sauf root) n'a pas le droit de faire des
paquets avec comme port source un port privil�gi�.
>
>> Il me semble que UDP est utilis� pour les
>> requ�tes normale et tcp est plut�t utilis� pour les
>> autres
>> fonctions dns (zone tranfer par exemple.) mais je n'en
>> suis pas s�r.
>
> Absolument, les requetes sont UDP, sauf pour celles qui
> sont trop grosses pour
> tenir dans un seul paquet UDP... Ce sont des cas
> particuliers qui ne
> concernent pas la tres grande majorite des requetes, a
> moins d'avoir
> configurer le "groupage" de groupage des requetes (je
> resume...).
>
>> l'illustre Daniel Cordey a dit un jour,
>
> Deconne pas... je me donne un mal de chien pour qu'un
> minimum de mes erreurs
> ne deborde sur la liste :-)
>
> A part ca, je mes suis un peu ecorche les doigts avec DNS
> il y a quelques
> temps. A partir du moment ou l'on utilise les zones
> (concept genial), on bute
> tres vite sur un probleme de gestion des fichiers zone et
> la configuration
> "fine" du serveur DNS. Ceci a mis a jour la necessite de
> disposer d'un outil
> permettant de configurer ces fichiers de maniere claire,
> non-ambigue et
> exempt d'erreurs de syntaxe. Sachant que le moindre petit
> "glitch" dans un de
> ces fichiers peut rendre vos donnees "invisibles". En
> plus, losrque vous avez
> la necessite de configurer le "reverse-IP mapping", les
> probabilites
> d'erreurs deviennent tres grandes. Ajoutez a ceci la TRES
> grosse difficulte a
> "debugguer" les problemes de DNS... J'ai donc l'obligation
> d'ecrire un outil
> pour notre infrastructure. Dans la foulee, j'essaierai de
> le rendre le plus
> souple possible et je le mettrai a disposition (GPL). Ce
> sera du code Python
> a tourner sur un serveur web.
>
> Daniel
>
> _______________________________________________
> gull mailing list
> [EMAIL PROTECTED]
> http://lists.alphanet.ch/mailman/listinfo/gull
>
_______________________________________________
gull mailing list
[EMAIL PROTECTED]
http://lists.alphanet.ch/mailman/listinfo/gull
