LES CAHIERS d'AIX

Publication réservée aux abonnés du Point Service AIX
Janvier 1998

Etudes de statistiques sur un serveur de noms

William FAUGERE

Introduction

Cet article a pour objectif de vous faciliter l'étude de statistiques des serveurs de noms.
Il s'adresse aux personnes connaissant le fonctionnement architectural des serveurs de noms de type "Berkeley".
Il a été écrit en s'appuyant sur la version BIND 4.9.3 (Berkeley Internet Name Domain) disponible pour les versions 4.1, 4.2 et 4.3 d'AIX.

Pour commencer, nous décrirons un échange de données standard dans un environnement DNS (Domain Name Service) très courant, ceci afin d'aborder plus facilement la description détaillée des divers champs de données du fichier de statistiques de named.
De nombreux exemples nous permettront ensuite de mettre en pratique les raisonnements nécessaires aux études réelles.

Echange DNS

Le client (resolver), sollicite (Appl query 1) le serveur de noms local (Local name server).
Cette requête étant non-autoritative au domaine, le serveur sollicite les serveurs de noms éloignés (Remote name servers) susceptibles de la résoudre : (Name server query 1, Name server query 2, etc.).
En effet, le serveur de noms local duplique ces questions aux différents serveurs de noms éloignés après un délai (timeout) atteint à la suite d'un problème réseau, d'un serveur inopérant ou occupé, etc.

Dans notre exemple, l'application reformule sa question car elle a également atteint son timeout. On remarquera que cette reformulation a été reconnue comme "duplicate" par le serveur de noms, et a donc été détruite.
Les serveurs de noms détectent une requête comme "dupliquée" s'ils sont actuellement occupés à la résolution de celle-ci. Ceci explique aussi pourquoi le "serveur de noms éloigné 1" n'a pas détruit la seconde question reçue : il a en effet déjà répondu à la première (Sends response to name server query 1).

De même, on notera que toutes les réponses arrivant après que le serveur de noms local ait reçu la réponse du "remote serveur 1", sont considérées comme "duplicate" et sont donc détruites.

Prendre les statistiques de named

Format du fichier de statistiques

• La première partie (+++ Statistics Dump +++), donne des informations générales sur named, telles que : le temps en secondes depuis son initialisation, le nombre de résolutions de type A (name to address) effectuées, le nombre de résolutions de types PTR, CNAME, MX, etc.
  Il est intéressant de noter que seuls les types sollicités sont rapportés, à l'exception du champ "Unknown query types" qui apparaîtra même si sa valeur est à zéro (0).

• La deuxième partie (++ Name Server Statistics ++) détaille chaque interface sollicitée par les différents types de requêtes selon un format particulier.

+--------------------------------------------------------------------------------+ | | |(Legend) | | RQ RR RIQ RNXD RFwdQ | | RFwdR RDupQ RDupR RFail RFErr | | RErr RTCP RAXFR RLame ROpts | | SSysQ SAns SFwdQ SFwdR SDupQ | | SFail SFErr SErr RNotNsQ SNaAns | | SNXD | |(Global) | | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | | | |[9.53.248.2] | | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | | | | ... | | | +--------------------------------------------------------------------------------+

La première ligne (Global) donne les statistiques globales de named, toutes les interfaces apparaissent en-dessous.

La correspondance des données par rapport aux champs de la légende est naturelle, c'est-à-dire : respectivement de gauche à droite puis de haut en bas.

Par exemple :

                                                                                                                          
(Global)                                                                                                                            
        0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0                                              
        | | | | |                         | | | | |
    RQ <- | | | -> RFwdQ           SysQ  <- | | | -> SDupQ
      RR <- | -> RNXD                SAns  <- | -> SFwdR
           RIQ                              SFwdQ   

Définition des champs de la légende

RQ

(Received Query) - "named a reçu de ? n queries".
Identifie le nombre de questions reçues par le serveur de noms.

RR

(Received Response) - "named a reçu de ? n réponses".
Identifie le nombre de réponses reçues par le serveur de noms.

RIQ

(Received Inverse Query) - "named a reçu de ? n queries inversées".
Identifie le nombre de questions inverses reçues par le serveur de noms.
Les "Inverse Queries" sont maintenant remplacées par les "PTR Queries" ; mais vous pouvez encore trouver ce type de "resource records" utilisé par d'anciennes applications.

RNXD

(Received a Not eXist in Domain response) - "named a reçu de ? n réponses négatives".
Identifie le nombre de réponses négatives reçues par le serveur de noms.
La réponse négative la plus courante arrive lorsque le serveur de noms ne trouve pas le host dans l'espace du domaine.

RFwdQ

(Received a Forwarded Query) - "named a reçu de ? n queries, que named a dû rediriger".
Identifie le nombre de questions reçues par le serveur de noms qu'il a dû rediriger vers d'autres serveurs.

RFwdR

(Received a Forwarded Response) - "named a reçu de ? n réponses, dont les queries ont dû être redirigées".
Identifie le nombre de réponses reçues par le serveur de noms, dont les queries ont du être précédemment redirigées.

RDupQ

(Received a Duplicate Query) - "named a reçu de ? n queries dupliquées".
Identifie le nombre de questions considérées comme dupliquées, reçues par le serveur de noms.

RDupR

(Received a Duplicate Response) - "named a reçu de ? n réponses dupliquées".
Identifie le nombre de réponses considérées comme dupliquées reçues par le serveur de noms.

RFail

(Received a servFail) - "named a reçu de ? n SERVFAIL errors".
Identifie le nombre d'erreurs SERVFAIL reçues par le serveur de noms.
Une erreur SERVFAIL symbolise un problème durant l'exécution d'une requête. Elle est le plus couramment générée par une erreur de syntaxe sur les fichiers "zones".

RFErr

(Received a FormErr) - "named a reçu de ? n FORMERR errors".
Identifie le nombre d'erreurs FORMERR reçues par le serveur de noms.
Une erreur FORMERR symbolise un problème d'interprétation de la requête. Elle peut, par exemple, être générée à la suite d'une erreur de format du protocole DNS.

RErr

(Received an other Error) - "named a reçu de ? n autres erreurs".
Identifie le nombre d'erreurs considérées comme "autres" que celles explicitement définies (SERFAIL et FORMERR) reçues par le serveur de noms.

RTCP

(Received a TCP query) - "named a reçu de ? n TCP queries".
Identifie le nombre de questions utilisant TCP comme "couche" de transport reçues par le serveur de noms.

RAXFR

(Received an AXFR) - "named a reçu de ? n AXFR".
Identifie le nombre d'AXFR reçus par le serveur de noms.
Un AXFR symbolise une demande de "zone transfer".

RLame

(Received a Lame delegation) - "named a reçu de ? n lame delegations".
Identifie le nombre de "lame delegation errors" reçues par le serveur de noms.
Une erreur "lame delegation" symbolise un problème de "parenting".

ROpts

(Received some IP Options) - "named a reçu de ? n Paquets contenant des options IP".
Identifie le nombre de paquets de données contenant des options IP.

SSysQ

(Sent SysQuery) - "named a envoyé à ? n system queries".
Identifie le nombre de questions générées et envoyées par le serveur de noms.

SAns

(Sent Answer) - "named a envoyé à ? n réponses".
Identifie le nombre de réponses envoyées par le serveur de noms.

SFwdQ

(Sent a Forwarded Query) - "named a envoyé à ? n questions que named a dû rediriger".
Identifie le nombre de questions envoyées par le serveur de noms que celui-ci a dû précédemment rediriger.

SFwdR

(Sent a Forwarded Response) - "named a envoyé à ? n réponses dont les questions ont dû être redirigées".
Identifie le nombre de réponses, envoyées par le serveur de noms, dont les queries ont dû, précédemment, être redirigées.

SDupQ

(Sent Duplicate Query) - "named a envoyé à ? n questions dupliquées".
Identifie le nombre de questions considérées comme dupliquées envoyées par le serveur de noms.

SFail

(Sent a servFail) - "named a envoyé à ? n SERVFAIL errors".
Identifie le nombre d'erreurs SERVFAIL envoyées par le serveur de noms.
Une erreur SERVFAIL symbolise un problème durant l'exécution d'une requête. Elle est, le plus couramment, générée par une erreur de syntaxe dans les fichiers "zones".

SFErr

(Sent a FormErr) - "named a envoyé à ? n FORMERR errors".
Identifie le nombre d'erreur FORMERR envoyées par le serveur de noms.
Une erreur FORMERR symbolise un problème d'interprétation de la requête. Elle peut, par exemple, être générée à la suite d'une erreur de format du protocole DNS.

SErr

(Sent an sendto() Error) - "named a rencontré n erreurs sur le "system call" sendto() lorsque ? était la destination".
Identifie le nombre d'erreurs sur le "system call" sendto().

RNotNsQ

(Received a Not Name server port Query) - "named a reçu de ? n queries ne provenant pas du port name-domain server".
Identifie le nombre de questions, reçues par le serveur de noms, ne provenant pas d'un autre serveur de noms.

SNaAns

(Sent a No authoritative Answer) - "named a envoyé à ? n réponses non autoritatives".
Identifie le nombre de réponses provenant du cache, envoyées par named.

SNXD

(Sent a Not eXist in Domain response) - "named a envoyé à ? n réponses négatives".
Identifie le nombre de réponses négatives envoyées par le serveur de noms.
La réponse négative la plus courante survient lorsque le serveur de noms ne trouve pas le host dans l'espace du domaine.

Tests

Initialisation de named

   # startsrc -s named
   # kill -IOT &rprime.cat /etc/named.pid&rprime.

+--------------------------------------------------------------------------------+ | | | +++ Statistics Dump +++ (881713500) Tue Dec 9 18:25:00 1997 | | 4 time since boot (secs) | | 4 time since reset (secs) | | 0 Unknown query types | | ++ Name Server Statistics ++ | | (Legend) | | RQ RR RIQ RNXD RFwdQ | | RFwdR RDupQ RDupR RFail RFErr | | RErr RTCP RAXFR RLame ROpts | | SSysQ SAns SFwdQ SFwdR SDupQ | | SFail SFErr SErr RNotNsQ SNaAns | | SNXD | | (Global) | | 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 | | [9.53.248.2] | | 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 | | ++ Name Server Statistics ++ | | +++ Statistics Dump +++ (881713500) Tue Dec 9 18:25:00 1997 | | | +--------------------------------------------------------------------------------+

On remarquera que seule l'interface "9.53.248.2" apparaît. Cette interface correspond a notre "forwarder" (directive "forwarder" présente dans le fichier de configuration named.boot).

Que se passe-t-il ?

Lors de l'initialisation de named, celui-ci envoie une "query" au "forwarder" afin de connaître les "root servers" de son domaine.

Cette "query" correspond au champ "SSysQ" (Sent System Query) qu'il faut comprendre comme suit :

• Je (named) lui (9.53.248.2) ai envoyé une "system query".
  Le fait que cette statistique apparaisse sur l'interface du "forwarder" permet de l'identifier.
  La réponse à la "query" correspond au champ "RR" (Received Response) qu'il faut comprendre, comme suit :
• J'ai (named) reçu une réponse de (9.53.248.2).

Note: Nous verrons par la suite, qu'il est important de suivre le même format de traduction pour quasiment tous les champs de la légende.

Résolution de nom

   # startsrc -s named
   # host jacobi
   # kill -IOT &rprime.cat /etc/named.pid&rprime.

+--------------------------------------------------------------------------------+ | | | +++ Statistics Dump +++ (881803424) Wed Dec 10 19:23:44 1997 | | 15 time since boot (secs) | | 15 time since reset (secs) | | 0 Unknown query types | | 1 A queries | | ++ Name Server Statistics ++ | | (Legend) | | RQ RR RIQ RNXD RFwdQ | | RFwdR RDupQ RDupR RFail RFErr | | RErr RTCP RAXFR RLame ROpts | | SSysQ SAns SFwdQ SFwdR SDupQ | | SFail SFErr SErr RNotNsQ SNaAns | | SNXD | | (Global) | | 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 | | [9.3.252.198] | | 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 | | [9.53.248.2] | | 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 | | ++ Name Server Statistics ++ | | +++ Statistics Dump +++ (881803424) Wed Dec 10 19:23:44 1997 | | | +--------------------------------------------------------------------------------+

On remarquera, dans la première partie du fichier, que le champ "A" "queries" est à 1, ce qui correspond au nombre de résolutions de type "A" (name to address) que named a effectuées depuis son initialisation.

Dans cet exemple, nous avons deux interfaces : celle du "name server" et celle du "forwarder".

Nous n'avons rien à dire de plus pour la ligne de l'interface du "forwarder" car elle est identique à l'exemple précédent.

Que se passe-t-il pour l'interface 9.3.252.198 correspondant à notre serveur primaire ?

Cette fois-ci, procédons de la manière suivante : Traduisons les différentes données des blocs, c'est-à-dire les champs renseignés :

                                                                                                                          
                                                                                                                                    
[9.3.252.198]                                                                                                                       
        1 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0 1 0 0 0  0 0 0 1 0  0                                   
        |                                  |              |
        |                                  |              |
        RQ                                SAns         RNotNsQ                                                                      
                                                                                                                                    

• RQ (Received Query) doit être compris comme suit :
  • J'ai (named) reçu une "query" de (9.3.252.198).
• SAns (Sent Answer) doit être compris comme suit :
  • Je (named) lui (9.3.252.198) ai envoyé une réponse.
• RNotNsQ (Received a Not Name server port Query) doit être compris comme suit :
  • J'ai (named) reçu de (9.3.252.198) un "query" provenant d'un port éphémère.

Notre traduction reflète-t-elle la réalité ?

• J'ai (named) reçu une "query" de (9.3.252.198) :
  en effet, cette "query" correspond à la demande de résolution de Jacobi.
• Je (named) lui (9.3.252.198) ai envoyé une réponse :
  plutôt sympathique, non ?
• J'ai (named) reçu de (9.3.252.198) une "query" provenant d'un port éphémère :
  Ceci mérite qu'on s'y attarde...

  Cette "query" (RNotNsQ) est en fait la même que RQ. Nous n'avons qu'une seule query (voir : A queries = 1 dans la première partie du fichier).
  RNotNsQ est un complément d'information à la "query".

  Nous avons utilisé un port éphémère pour cette "query" car l'auteur de celle-ci est le resolver. Par contre, lorsque named effectue une "query", en fait une "System query", il utilise le "well-known port" 53.
  Nous mettrons en évidence ces différents ports dans les prochains tests.

Telnet à partir d'un client

   # startsrc -s named
   jacobi># tn dirac
   # kill -IOT &rprime.cat /etc/named.pid&rprime.

+--------------------------------------------------------------------------------+ | | | +++ Statistics Dump +++ (881720511) Tue Dec 9 20:21:51 1997 | | 18 time since boot (secs) | | 18 time since reset (secs) | | 0 Unknown query types | | 1 A queries | | 1 PTR queries | | ++ Name Server Statistics ++ | | (Legend) | | RQ RR RIQ RNXD RFwdQ | | RFwdR RDupQ RDupR RFail RFErr | | RErr RTCP RAXFR RLame ROpts | | SSysQ SAns SFwdQ SFwdR SDupQ | | SFail SFErr SErr RNotNsQ SNaAns | | SNXD | | (Global) | | 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 0 0 0 0 0 0 2 0 0 | | [9.3.252.240] | | 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 | | [9.3.252.198] | | 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 | | [9.53.248.2] | | 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 | | ++ Name Server Statistics ++ | | +++ Statistics Dump +++ (881720511) Tue Dec 9 20:21:51 1997 | +--------------------------------------------------------------------------------+

Nous n'avons pas encore sollicité le "forwarder" pour adresser, par exemple, des requêtes externes au domaine ; par conséquent, les données relatives à l'interface du domaine ne sont pas différentes de celles des exemples précédents.

Sachant que jacobi &identical. 9.3.252.240, et que dirac &identical. 9.3.252.198, nous pouvons maintenant aller plus vite pour traduire ces statistiques :

• J'ai reçu, de jacobi, une "query" (RQ) sur un port éphémère (RNotNsQ). Je lui ai envoyé une réponse (SAns).
• J'ai reçu, de dirac, une "query" (RQ) sur un port éphémère (RNotNsQ).
  Je lui ai envoyé une réponse (SAns).

En effet, si nous regardons la première partie du fichier, nous découvrons "1 A query" et "1 PTR query".
Pourquoi deux "queries" ?
En fait, cela dépend de l'application. Dans notre cas, nous avons utilisé telnet.
De la même façon, nous pourrions remarquer que l'application rlogin occasionne "3 A queries" et "1 PTR query" en utilisant le nom.

Requête extérieure au domaine

   # starsrc -s named
   jacobi># host ouioui.astaix.france.ibm.com
   # kill -IOT &rprime.cat /etc/named.pid&rprime.

+--------------------------------------------------------------------------------+ | | | +++ Statistics Dump +++ (881811277) Wed Dec 10 21:34:37 1997 | | 13 time since boot (secs) | | 13 time since reset (secs) | | 0 Unknown query types | | 1 A queries | | ++ Name Server Statistics ++ | | (Legend) | | RQ RR RIQ RNXD RFwdQ | | RFwdR RDupQ RDupR RFail RFErr | | RErr RTCP RAXFR RLame ROpts | | SSysQ SAns SFwdQ SFwdR SDupQ | | SFail SFErr SErr RNotNsQ SNaAns | | SNXD | | (Global) | | 1 2 0 0 1 1 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0 0 0 1 0 0 | | [9.3.252.240] | | 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 | | [9.53.248.2] | | 0 2 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 | | ++ Name Server Statistics ++ | | +++ Statistics Dump +++ (881811277) Wed Dec 10 21:34:37 1997 | | | +--------------------------------------------------------------------------------+

Après traduction des données et mise en forme (oublions le "RR" et le "SSysQ" provenant de l'initialisation de named), nous obtenons les informations suivantes: :

• J'ai (named) reçu, de jacobi, une "query" (RQ) sur un port éphémère (RNotNsQ), qui a dû être redirigée (RFwdQ) vers le "forwarder" (SFwdQ).
• J'ai reçu du "forwarder" une réponse (RR) à ma query précédemment redirigée (RFwdR).
• J'ai envoyé une réponse provenant d'une "query" redirigée vers jacobi (SFwdR).

D'accord, l'interprétation n'est pas instantanée... mais, ceci n'est qu'un exercice,
Jamais vous ne traduirez les statistiques de la sorte... d'abord, ce n'est pas le but recherché, et en plus, c'est impossible à faire avec les statistiques d'un serveur de noms en exploitation,
Retenez seulement que les données de types RFwdQ, RFwdR, SFwdQ et SFwdR correspondent entre-elles et doivent êtres cohérentes.

Statistiques d'un traceroute

# startsrc -s named -a "-d 1"
jacobi># traceroute 9.101.3.45
# kill -IOT &rprime.cat /etc/named.pid&rprime.
# kill -INT &rprime.cat /etc/named.pid&rprime.
# kill -USR2 &rprime.cat /etc/named.pid&rprime.

Comme vous l'avez remarqué, nous avons lancé named en mode "debug 1", et en plus des statistiques, pris un dump de celui-ci.

Voici le résultat du traceroute :

+--------------------------------------------------------------------------------+ | | | 1 9.3.252.194 (9.3.252.194) 2 ms 2 ms 2 ms | | 2 9.111.38.1 (9.111.38.1) 5 ms 66 ms 12 ms | | 3 bba-def.austin.ibm.com (9.3.136.253) 7 ms 8 ms 8 ms | | 4 aus1wf.nssouth.ibm.com (9.3.133.182) 10 ms 5 ms 6 ms | | 5 aus2wf.nssouth.ibm.com (9.3.133.183) 11 ms 12 ms 8 ms | | 6 rtp2wf-aus2-hssi.nssouth.ibm.com (9.32.200.78) 40 ms 39 ms 84 ms | | 7 rtp1wf-serbb.nssouth.ibm.com (9.32.204.49) 64 ms 76 ms 50 ms | | 8 9.32.204.190 (9.32.204.190) 48 ms 86 ms 58 ms | | 9 cmpnbet3.mpn.ibm.com (9.32.1.133) 133 ms 69 ms 114 ms | |10 portsmouth4.mpn.ibm.com (9.32.74.50) 164 ms 148 ms 209 ms | |11 9.31.255.2 (9.31.255.2) 179 ms 235 ms 189 ms | |12 9.101.25.3 (9.101.25.3) 212 ms 225 ms 210 ms | |13 9.31.226.5 (9.31.226.5) 260 ms 255 ms 9.101.25.3 (9.101.25.3) 157 ms | |14 9.31.226.22 (9.31.226.22) 214 ms 215 ms 210 ms | |15 tournesol.france.ibm.com (9.101.224.11) 209 ms 220 ms 222 ms | |16 ouioui.astaix.france.ibm.com (9.101.3.45) 223 ms 266 ms 265 ms | | | +--------------------------------------------------------------------------------+

Observons le fichier des statistiques :

+--------------------------------------------------------------------------------+ | | | +++ Statistics Dump +++ (881795023) Wed Dec 10 17:03:43 1997 | | 23 time since boot (secs) | | 23 time since reset (secs) | | 0 Unknown query types | | 17 PTR queries | | ++ Name Server Statistics ++ | | (Legend) | | RQ RR RIQ RNXD RFwdQ | | RFwdR RDupQ RDupR RFail RFErr | | RErr RTCP RAXFR RLame ROpts | | SSysQ SAns SFwdQ SFwdR SDupQ | | SFail SFErr SErr RNotNsQ SNaAns | | SNXD | | (Global) | | 17 16 0 6 15 15 0 0 0 0 0 0 0 0 0 1 2 15 15 0 0 0 0 17 0 2 | | [9.3.252.240] | | 17 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 2 0 15 0 0 0 0 17 0 2 | | [9.53.248.2] | | 0 16 0 6 0 15 0 0 0 0 0 0 0 0 0 1 0 15 0 0 0 0 0 0 0 0 | | ++ Name Server Statistics ++ | | +++ Statistics Dump +++ (881795023) Wed Dec 10 17:03:43 1997 | | | +--------------------------------------------------------------------------------+

Notre serveur a été l'objet de 17 queries de type PTR ; en effet, pour afficher les informations, le programme traceroute effectue des résolutions "address to name".
Les queries ont été initialisées par jacobi (17 RQ).
Quinze de ces queries ont été redirigées par named (15 RFwdQ) car elles étaient non-autoritatives au domaine. Remarquons que nous avons 15 RFwdQ, 15 SFwdR, 15 RFwdR et 15 SFwdQ ; tout est donc cohérent.

Il y a également 2 "SAns", ce qui veut dire que named a résolu lui-même ces deux queries (non redirigées).
Donc : 15 queries redirigées plus 2 queries non redirigées font bien un total de 17 queries.

Nous remarquons aussi "2 SNXD" et "6 RNXD" indiquant :

• j'ai (named) reçu 6 réponses négatives du forwarder,
• j'ai (named) envoyé 2 réponses négatives à jacobi.

• les 6 RNXD sont compris dans les 15 RFwdR,
• les 2 SNXD sont compris dans les 2 SAns.

Mais que se passe-t-il vraiment ?
Si l'on observe le résultat de traceroute, on peut remarquer que les adresses n'ont pas toutes été résolues. Nous avons huit adresses non résolues (dont deux en ligne 13). Deux SNXD et six RNXD font bien huit réponses négatives. Le fait que certaines adresses ne soient pas correctement résolues ne dérange pas le programme traceroute (sinon, celui-ci serait dépendant de named, ).

La première action du programme traceroute est la résolution inverse de "9.3.252.194".
Named examine le fichier " /etc/named.boot " ; comme la ligne " 252.3.9.in-addr.arpa " est définie dans ce fichier, il en déduit qu'il est le serveur autoritatif de la zone correspondante.
Cependant, named ne trouve pas l'adresse " 194.252.3.9.in-addr.arpa " dans ce fichier zone... Il va donc renseigner le fichier de statistiques avec un SAns et un SNXD.

Nous pouvons mettre ceci en évidence avec la partie concernée du fichier debug :

+-------------------------------------------------------------------------------------+ | | |1 datagram from [9.3.252.240].3014, fd 6, len 42; now Wed Dec 10 17:03:23 1997 | |2 ENTER(0:.tree_srch) | |3 RET(0:.tree_srch) | |4 ENTER(0:.tree_srch) | |5 RET(0:.tree_srch) | |6 ENTER(0:.tree_add) | |7 ENTER(1:.sprout) | |8 MSGF(LESS. sprouting left.) | |9 ENTER(2:.sprout) | |10 MSGF(grounded. adding new node, setting h=true) | |11 RET(2:.sprout) | |12 MSGF(LESS: left branch has grown) | |13 MSGF(LESS: case 0.. balnce bad but still ok) | |14 RET(1:.sprout) | |15 RET(0:.tree_add) | |16 ENTER(0:.tree_srch) | |17 RET(0:.tree_srch) | |18 ENTER(0:.tree_srch) | |19 RET(0:.tree_srch) | |20 req: nlookup(194.252.3.9.in-addr.arpa) id 1 type=12 | |21 req: found '194.252.3.9.in-addr.arpa' as '252.3.9.in-addr.arpa' (cname=0) | |22 ns_req: answer -> [9.3.252.240].3014 fd=6 id=1 Local | | | +-------------------------------------------------------------------------------------+

• Ligne 21 :
  Named s'aperçoit que la query est autoritative au domaine, donc :
• Ligne 22 :
  il renseigne la réponse comme "local".
• Lignes 1 et 22 :
  Nous pouvons remarquer que la query émise par jacobi est négociée par le port éphémère 3014.

+--------------------------------------------------------------------------------+ | | | ns_req: answer -> [9.3.252.197].3070 fd=6 id=1 Local | | ;; ->>HEADER<<<- opcode: QUERY, status: NXDOMAIN, id: 1 | | ;; flags: qr aa rd ra | | ;; QUESTIONS: | | ;; 194.252.3.9.in-addr.arpa, type = PTR, class = IN | | | | ;; AUTHORITY RECORDS: | | 252.3.9.in-addr.arpa. 86400 IN SOA dirac.ztrans.com. | | root.dirac.ztrans.com. ( | | 1 ; serial | | 14400 ; refresh (4 hours) | | 3600 ; retry (1 hour) | | 604800 ; expire (7 days) | | 86400 ) ; minimum (1 day) | | | +--------------------------------------------------------------------------------+

Le statut NXDOMAIN (Not eXist in DOMAIN) vérifie l'entrée SNXD dans le fichier de statistiques.

En ligne 12 du résultat du programme traceroute, la requête consiste à résoudre l'adresse 9.101.25.3.
Named regarde dans le fichier /etc/named.boot ; ne trouvant rien, il cherche ensuite dans son cache et trouve que la zone autoritative est : 9.in-addr.arpa. Mais comme il n'est pas le serveur de la zone 9.in-addr.arpa, il redirige alors la requête au "forwarder".
Il se trouve que la réponse du "forwarder" est négative (NXDOMAIN), named garde donc la trace de cette information en mémorisant la réponse dans son cache.
Named renseigne alors les statistiques d'un RNSD et d'un SFwrR.
En ligne 13, on peut à nouveau voir une demande de résolution pour l'adresse 9.101.25.3 (cette requête est réitérée car un timeout a été atteint).
Named peut répondre car il possède l'information dans son cache ; puis il renseigne les statistiques par un SNSD et un SAns.

Nous venons de voir que les réponses négatives du "forwarder" sont mémorisées dans le cache de named, nous pouvons donc mettre en évidence les six RNSD via le fichier dump de named.

+--------------------------------------------------------------------------------+ | | |# grep NXDOMAIN /var/tmp/named_dump.db | | | |;3 577 IN PTR NXDOMAIN ;-$ ;[9.53.248.2] | |;22 578 IN PTR NXDOMAIN ;-$ ;[9.53.248.2] | |;5 577 IN PTR NXDOMAIN ;-$ ;[9.53.248.2] | |;2 576 IN PTR NXDOMAIN ;-$ ;[9.53.248.2] | |;190 574 IN PTR NXDOMAIN ;-$ ;[9.53.248.2] | |;1 574 IN PTR NXDOMAIN ;-$ ;[9.53.248.2] | | | +--------------------------------------------------------------------------------+

Conclusion

L'analyse d'un serveur de noms en exploitation est très différente de ce que nous venons de montrer. En effet, il n'est pas envisageable d'analyser chaque donnée comme nous venons de le faire.
En pratique, dans la grande majorité des cas, un simple coup d'oeil jeté sur la première partie du fichier de statistiques et sur la ligne global, suffit pour faire un bilan.

En guise de conclusion, nous allons regarder les statistiques d'un serveur de noms en exploitation.

Voici le fichier des statistiques :

+----------------------------------------------------------------------------------+ | | | | |1 +++ Statistics Dump +++ (881949040) Fri Dec 12 11:50:40 1997 | |2 260855 time since boot (secs) | |3 260855 time since reset (secs) | |4 660 Unknown query types | |5 116521 A queries | |6 6 MB queries | |7 36 MG queries | |8 5 MR queries | |9 23120 PTR queries | |10 156 MX queries | |11 46 AAAA queries | |12 1535 ANY queries | |13 ++ Name Server Statistics ++ | |14 (Legend) | |15 RQ RR RIQ RNXD RFwdQ | |16 RFwdR RDupQ RDupR RFail RFErr | |17 RErr RTCP RAXFR RLame ROpts | |18 SSysQ SAns SFwdQ SFwdR SDupQ | |19 SFail SFErr SErr RNotNsQ SNaAns | |20 SNXD | |21 (Global) | |22 142085 7719 0 1153 6013 5344 14 759 1094 0 0 422 0 0 0 518 135662 | |23 [0.0.0.0] | |24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 3 0 0 0 0 0 | |25 [9.3.252.194] | |26 0 66 0 0 0 0 0 66 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | |27 [9.3.252.196] | |28 104 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 104 0 0 0 0 0 0 104 0 0 | |30 [9.3.252.197] | |31 39 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 39 0 0 0 0 0 0 39 0 0 | |32 [9.3.252.198] | |33 65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 65 0 0 0 0 0 0 65 0 0 | |34 [9.3.252.199] | |35 37 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 37 0 0 0 0 0 0 37 0 0 | |36 [9.3.252.204] | |37 36 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 36 0 0 0 0 0 0 36 0 0 | |38 [9.3.252.208] | |39 35 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35 0 0 0 0 0 0 35 0 0 | |40 [9.3.252.212] | |41 51962 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 51962 0 0 0 0 0 0 51962 0 0 | |42 [9.3.252.214] | |43 154 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 154 0 0 0 0 0 0 154 0 0 | |44 [9.3.252.216] | |45 18 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 15 0 3 0 0 0 0 18 3 0 | |46 [9.3.252.217] | |47 40 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 40 0 0 0 0 0 0 40 0 0 | |48 [9.3.252.219] | |49 2970 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2970 0 0 0 0 0 0 2970 0 0 | |50 [9.3.252.220] | |51 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 12 0 0 0 0 0 0 12 0 1 | |52 [9.3.252.225] | |53 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 53 0 0 0 0 0 0 53 0 7 | |54 [9.3.252.226] | |55 2929 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2929 0 0 0 0 0 0 2 2929 0 0 | | | +----------------------------------------------------------------------------------+

+----------------------------------------------------------------------------------+ | | |56 [9.3.252.237] | |57 46 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 46 0 0 0 0 0 0 46 0 0 | |58 [9.3.252.238] | |59 149 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 148 0 1 0 0 0 0 149 0 1 | |60 [9.3.252.241] | |61 113 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 112 0 1 0 0 0 0 113 0 1 | |62 [9.3.252.242] | |63 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 93 0 0 0 0 0 0 93 0 0 | |64 [9.3.252.244] | |65 36 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 36 0 0 0 0 0 0 36 0 0 | |66 [9.3.252.252] | |67 496 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 496 0 0 0 0 0 0 496 0 492 | |68 [9.3.252.253] | |69 4 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 2 0 2 0 0 0 0 4 0 0 | |70 [9.52.48.179] | |71 2205 0 0 0 16 0 0 0 0 0 0 0 0 0 0 0 2189 0 15 0 1 0 0 2205 2188 | |72 [9.53.39.50] | |73 802 0 0 0 23 0 0 0 0 0 0 45 0 0 0 0 736 0 21 0 0 0 0 802 18 8 | |74 [9.53.39.56] | |75 1015 0 0 0 29 0 0 0 0 0 0 5 0 0 0 0 981 0 29 0 0 0 0 1015 231 6 | |76 [9.53.39.62] | |77 55443 0 0 0 1540 0 8 0 0 0 0 314 0 0 0 0 53604 0 1533 0 2 0 0 554| |78 [9.53.39.63] | |79 16395 0 0 0 42 0 0 0 0 0 0 58 0 0 0 0 16296 0 41 0 0 0 0 0 16395| |80 [9.53.39.246] | |81 318 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 318 0 0 0 0 0 0 318 0 0 | |82 [9.53.183.2] | |83 0 937 0 24 0 49 0 515 371 0 0 0 0 0 0 0 0 0 0 1417 0 0 0 0 0 0 | |84 [9.53.248.2] | |85 0 6716 0 1129 0 5292 0 178 723 0 0 0 0 0 0 518 0 6013 3 691 0 0 0| |86 [9.87.252.113] | |87 5416 0 0 0 4130 3 0 0 0 0 0 0 0 0 0 0 1286 0 3473 0 657 0 0 0 557| |88 [9.87.252.123] | |89 166 0 0 0 112 0 3 0 0 0 0 0 0 0 0 0 51 0 108 0 4 0 0 166 39 10 | |90 [9.87.253.193] | |91 165 0 0 0 30 0 0 0 0 0 0 0 0 0 0 0 135 0 30 0 0 0 0 165 15 114 | |92 [32.225.38.33] | |93 371 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 364 0 7 0 0 0 0 371 1 170 | |94 [32.225.38.76] | |95 49 0 0 0 26 0 3 0 0 0 0 0 0 0 0 0 20 0 25 0 1 0 0 49 0 13 | |96 [32.225.38.144] | |97 80 0 0 0 44 0 0 0 0 0 0 0 0 0 0 0 36 0 44 0 0 0 0 80 4 27 | |98 [32.225.39.126] | |99 253 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 248 0 5 0 0 0 0 253 0 35 | |101 [32.225.39.242] | |102 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 | |103 [32.225.40.30] | |104 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 4 0 0 | |105 [32.225.41.49] | |106 9 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 7 0 2 0 0 0 0 9 0 1 | |107 [32.226.52.198] | |108 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 | |109 [32.226.52.242] | |110 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 | |111 ++ Name Server Statistics ++ | |112 +++ Statistics Dump +++ (881949040) Fri Dec 12 11:50:40 1997 | | | | | +----------------------------------------------------------------------------------+

L'examen de ce fichier nous permet de dire que :

• Le serveur de noms est actif depuis trois jours (260855 time since boot (secs)).
• Son rendement de "1 Query / 1.8 seconde" (260855/142085) montre un serveur de noms peu chargé.
• Il y a un nombre important de "Unknown query types".
  Ces queries ne sont pas reconnues par notre serveur de noms. Cela peut signifier qu'il y a un problème de mise en oeuvre ou que quelqu'un fait des tests avec de nouveaux "resource record types"...
  Dans le cas présent, le fichier de statistiques provient d'un serveur de noms secondaire de nos laboratoires d'AUSTIN ; il n'est donc pas anormal d'observer de telles valeurs.
• Les types MX et ANY sont généralement utilisés par les "mailers" tels que sendmail.
• Les types MB, MG et MR sont des "resource record types" expérimentaux.
• Le type AAAA est un "address resource record" pour IPv6.

En ce qui concerne la ligne de statistiques globales, les champs à surveiller sont plus particulièrement :

• Les statistiques d'erreurs telles que RFErr et RLame,
• Les proportions de RQ pour chaque interface, afin de s'assurer d'une bonne répartition des queries.

Visiblement, notre serveur de noms ne rencontre pas d'erreur FORMERR ou de problème de "parenting". Donc, bien que deux serveurs se partagent 75% des queries, notre serveur de noms n'est pas surchargé et il n'est pas nécessaire d'envisager des délégations.

Afin que ce bilan soit représentatif du fonctionnement de notre serveur de noms, il faudrait renouveler cette analyse plusieurs fois.      :poinnoir.