Yop

Aller au contenu | Aller au menu | Aller à la recherche

lundi, 29 mars 2010

Déléguation de zone inverse pour réseaux inférieurs à /24

Je viens de faire la manip... donc voici un petit résumé.


  • Introduction

Disons qu'on nous a alloué lé réseau 1.2.3.192/27.
Ceci nous donne la plage utilisable de 1.2.3.193 à 1.2.3.222.

Vérifions quels sont les PTR actuels pour ce range:

$ for i in `seq 193 222`; do echo $i && dig -x 1.2.3.$i +short && echo "---"; done

Vérifions les serveurs DNS en charge d'une IP du range (prenons la .202):

$ dig ptr 202.3.2.1.in-addr.arpa
[...]
;; AUTHORITY SECTION:
3.2.1.in-addr.arpa. 170940 IN NS ns1.provider.test.
3.2.1.in-addr.arpa. 170940 IN NS ns0.provider.test.

Vérifions les serveurs DNS en charge de la zone (le /24):

$ dig ns 3.2.1.in-addr.arpa. +short
ns1.provider.test.
ns0.provider.test.
$

Donc les noms associés à nos IPs sont gérés dans les DNS de notre provider.


  • La problèmatique

Nous souhaitons avoir nous même authorité sur les IPs de notre /27.
C'est à dire gérer nous-même les PTR sans avoir à demander à provider.test.

Comme nous avons le /27 et non pas le /24, on est obligé de ruser un peu pour ne pouvoir donner délégation que sur une partie de la zone 3.2.1.in-addr.arpa.
La "technique" consiste à passer par des CNAME et une nouvelle zone...


  • Voici les manipulations à réaliser:

Sur les serveurs DNS nsX.provider.test. il faut

- Supprimer les PTR existants

- Créer les CNAME suivants

[...]
202.3.2.1.in-addr.arpa. IN CNAME 202.192-223.3.2.1.in-addr.arpa.
203.3.2.1.in-addr.arpa. IN CNAME 203.192-223.3.2.1.in-addr.arpa.
etc...

- Créer les NS suivants

192-223.3.2.1.in-addr.arpa. IN NS dns1.monDomaine.test.
192-223.3.2.1.in-addr.arpa. IN NS dns2.monDomaine.test.

Le nom de la zone 192-223.3.2.1.in-addr.arpa. est plus ou moins au libre choix de l'administrateur.

Sur nos serveurs DNS dnsX.monDomaine.test.

- Créer la zone 192-223.3.2.1.in-addr.arpa.

- Créer les PTR dans cette zone

[...]
202.192-223.3.2.1.in-addr.arpa. IN PTR cequejeveux.monDomaine.test.
203.192-223.3.2.1.in-addr.arpa. IN PTR autretrucquejeveux.monDomaine.test.
etc...

samedi, 19 septembre 2009

Utiliser un autre serveur DNS que celui donné par le serveur DHCP

En DHCP, pour pouvoir utiliser sont propre serveur DNS au lieu de se voir imposer celui du serveur:

- Avant:

$ cat /etc/resolv.conf
# Generated by NetworkManager
domain lan
search lan
nameserver 192.168.1.1
$

- La modification consiste à utiliser la ligne suivante dans le fichier /etc/dhcp3/dhclient.conf (ou dans le fichier /etc/dhcp/dhclient.conf )

prepend domain-name-servers 127.0.0.1;

Optionnellement supprimer domain-name-servers de la ligne request

- Après:

$ cat /etc/resolv.conf
# Generated by NetworkManager
domain lan
search lan
nameserver 127.0.0.1
nameserver 192.168.1.1
$

jeudi, 26 mars 2009

Dnstop - Visualisation de trafic DNS

Dnstop permet de visualiser simplement le trafic DNS.

uggy-dnstop2.png

Il y a pas mal d'options possibles...



En plus de visualiser diverses stats, il permet également de déceler certains types de trafic anormal comme des TLD invalides, des PTR d'adresses 1918 etc...

uggy-dnstop.png

uggy-dnstop1.png


D'autres exemples sont ici.

mardi, 7 octobre 2008

Performances serveur DNS avec DNSPerf et ResPerf

Ces outils de chez nominum permettent de tester les performances d'un serveur de cache / Récursif ( ResPerf ) et d'un serveur Authoritative ( DNSPerf ).

Le README explique que Bind doit etre installé car des librairies...etc.. sont utilisées. Il ne reste ensuite qu'à compiler.

Les man sont bient faits et expliquent de manière assez détaillée la manière dont les 2 programmes fonctionnent.


  • ResPerf

resperf -s 10.0.0.2 -d queryfile

queryfile est de la forme

domain1.com A
domain2.fr MX

Le fichier utilsé par QueryPerf dans le billet précédent peut donc être utilisé

$ wc -l /tmp/ile
880000 /tmp/file
$
$ head -4 /tmp/file
fhs.com A
bluejean.com.tr A
geeo.org A
bluessiden.com MX
$


Sans les données en cache on obtient sur un Bind:

Statistics:

Queries sent: 74240
Queries completed: 9780
Queries lost: 64460
Ran for: 49.438710 seconds
Maximum throughput: 1392.000000 qps
Lost at that point: 33.14%

Avec les données déjà en cache on obtient sur un Bind:

Statistics:

Queries sent: 78073
Queries completed: 13794
Queries lost: 64279
Ran for: 49.679299 seconds
Maximum throughput: 2044.000000 qps
Lost at that point: 1.83%


  • DNSPerf

Tout pareil au niveau des commandes ou des sorties, mais avec un code optimisé pour faire les requètes sur un serveur qui a authorité sur les domaines demandés.

Performances serveur DNS avec queryperf

Queryperf est un outil pour tester les performances d'un serveur DNS.

Il est fourni dans les sources de Bind.. Il n'y a qu'à compiler.

/xxx/bind-9.5.0-P2/contrib/queryperf/


Il y a plusieurs options, une des principales est de lui fournir en entrée un fichier avec des noms de domaines à résoudre...

$ queryperf -v -d /tmp/fichier

Ce fichier est sous la forme:

$ cat /tmp/fichier
nom1.fr A
nom2.com MX


Par défaut il utilise 127.0.0.1 comme serveur à interroger mais ceci, comme le reste se change par les options.


Pour créer un fichier source avec quelques entrées, j'ai utilisé comme base une de mes règles de rejet dans les logs de Postfix.. à coups de :

| grep "from=<" | awk -F@ '{print $3}' | awk -F\> '{print $1}'

Puis on ajoute A ou MX à la fin de la ligne à coups de:

| awk '{print $0"\tA"}'
| awk '{print $0"\tMX"}'

On obtient au final:

$ wc -l /tmp/file
880000 /tmp/file
$ ll /tmp/files | awk '{print $5'}
13M
$ head /tmp/file
fhs.com A
bluejean.com.tr A
geeo.org A
bluessiden.com MX
americanhomestaffing.com A
$

Ce sont des domaines trouvés dans les MAIL FROM:<> d'un des règles de rejet. On doit donc avoir un peu de tout, des domaines qui existent, d'autres non, des DNS non joignables.. Bref quelquechose qui doit être a peu près représentatif d'un trafic réel. (On n'a pas de "vrais" noms de machine, c'est vrai).


On obtient donc pour du récursif sur un Bind:

Statistics:

Parse input file: once
Ended due to: reaching end of file

Queries sent: 880000 queries
Queries completed: 872400 queries
Queries lost: 7600 queries
Queries delayed(?): 0 queries

RTT max: 5.006302 sec
RTT min: 0.000009 sec
RTT average: 0.064140 sec
RTT std deviation: 0.156662 sec
RTT out of range: 3 queries

Percentage completed: 99.14%
Percentage lost: 0.86%

Started at: Tue xxx x 11:59:54 2008
Finished at: Tue xxx x 13:18:25 2008
Ran for: 4710.344667 seconds

Queries per second: 185.209377 qps


Un dump du cache pour vérifier:

$ rndc dumpdb
$ ll /var/chroot-named/etc/namedb/named_dump.db | awk '{print $5}'
6.9M
$

On peut ensuite gréper dans un domaine de la liste pour trouver les entrées correspondantes dans le cache.


Le test en cours:

Ce n'est probablement pas ce qui se fait de mieux pour des stats, mais ca peut aider lors de manipulations diverses sur des serveurs DNS.

- page 2 de 4 -