Forum Linux.général dig option +trace

Posté par Philippe M (site web personnel) le 01 septembre 2015 à 09:35. Licence CC By‑SA.

Étiquettes : aucune

sept.

2015

Bonjour,

Je debug mon serveur local dns parce que je trouve qu'il est long à répondre et je soupçonne que certains programmes aiment pas les temps de réponse trop long.

Lorsque je fais

    dig server.mon.dom +trace
    ; <<>> DiG 9.10.2-P3-RedHat-9.10.2-4.P3.fc22 <<>> server.mon.dom +trace
    ;; global options: +cmd
    .           518400  IN  NS  M.ROOT-SERVERS.NET.
    .           518400  IN  NS  A.ROOT-SERVERS.NET.
    .           518400  IN  NS  B.ROOT-SERVERS.NET.
    .           518400  IN  NS  C.ROOT-SERVERS.NET.
    .           518400  IN  NS  D.ROOT-SERVERS.NET.
    .           518400  IN  NS  E.ROOT-SERVERS.NET.
    .           518400  IN  NS  F.ROOT-SERVERS.NET.
    .           518400  IN  NS  G.ROOT-SERVERS.NET.
    .           518400  IN  NS  H.ROOT-SERVERS.NET.
    .           518400  IN  NS  I.ROOT-SERVERS.NET.
    .           518400  IN  NS  J.ROOT-SERVERS.NET.
    .           518400  IN  NS  K.ROOT-SERVERS.NET.
    .           518400  IN  NS  L.ROOT-SERVERS.NET.
    ;; Received 811 bytes from 192.168.xxx.xxx#53(192.168.xxx.xxx) in 0 ms

    hermes.         86400   IN  NSEC    hiphop. NS DS RRSIG NSEC
    hermes.         86400   IN  RRSIG   NSEC 8 1 86400 20150910170000 20150831160000 1518 . f6l2sOxUCof8wSHxmeX2h68cYdTWAIB3hp2GTX1d2qmUhK9FZ6LyC0mf 1uSsYxT85iZ/UYSd8wGNL3ENxzxVze/ejtQXcgNvlEeatqarwbpyG4m+ ltKK7MOG0gXa0Z1Ahc/bEFmaOIszFZftG4h9i4dtCrNEKFtw3bePx9u6 tdU=
    .           86400   IN  NSEC    aaa. NS SOA RRSIG NSEC DNSKEY
    .           86400   IN  RRSIG   NSEC 8 0 86400 20150910170000 20150831160000 1518 . p0msPrsZzvxWB0fpa3A06nPyTFzYZ4dWbseHVa1Ws0X0bnME3q80KnBB rLxl6H92Xzoo/i1zUEW/aLgMCSlSQThCAhuGBl0v0KgAui0kwH4dAYe8 IZkW3TW9rP4bUDiUQCfbfH1AJ0fJKG8/Ol4TmPSvFMu8iuhBa94IvNB/ 3mY=
    .           86400   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2015083101 1800 900 604800 86400
    .           86400   IN  RRSIG   SOA 8 0 86400 20150910170000 20150831160000 1518 . q0y5HOog7oNLlzyRc7iNIrkicosQl+4KkUKKFqr1vOdmcsVEJllbQtXT lHEt4yFHw4tBLDM1c2IDVB3BFIDi4gGBw10qUy7eJkOkFX+za1wrMMf2 /RbXSV5hVvdZRqUIPaVHvKJgqAzLc9ZjfprzxI/NG8C2Wt1AV0kwh0bj qZg=
    ;; Received 657 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 103 ms

Est-ce que ça veut dire qu'il va chercher d'abord sur les DNS root puis ensuite il va sur mon DNS local (192.168.xxx.xxx) ?

Merci d'avance.

# probablement que oui

Posté par NeoX le 01 septembre 2015 à 09:39. Évalué à 2.

la premiere reponse liste les NS, et elle est donnée par la machine 192.168.xxx.xxx (ta machine locale je pense)
la 2e reponse est donnée par 128.63.2.53

et d'apres cette sortie, il n'y a de toute facon pas d'entrée pour server.mon.dom

[^] # Re: probablement que oui

Posté par Philippe M (site web personnel) le 01 septembre 2015 à 09:48. Évalué à 1. Dernière modification le 01 septembre 2015 à 10:28.

Si je rend dig un peu plus bavard

    dig server.mon.dom +trace +all

    ; <<>> DiG 9.10.2-P3-RedHat-9.10.2-4.P3.fc22 <<>> server.mon.dom +trace +all
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62548
    ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;.              IN  NS

    ;; AUTHORITY SECTION:
    .           518400  IN  NS  E.ROOT-SERVERS.NET.
    .           518400  IN  NS  F.ROOT-SERVERS.NET.
    .           518400  IN  NS  G.ROOT-SERVERS.NET.
    .           518400  IN  NS  H.ROOT-SERVERS.NET.
    .           518400  IN  NS  I.ROOT-SERVERS.NET.
    .           518400  IN  NS  J.ROOT-SERVERS.NET.
    .           518400  IN  NS  K.ROOT-SERVERS.NET.
    .           518400  IN  NS  L.ROOT-SERVERS.NET.
    .           518400  IN  NS  M.ROOT-SERVERS.NET.
    .           518400  IN  NS  A.ROOT-SERVERS.NET.
    .           518400  IN  NS  B.ROOT-SERVERS.NET.
    .           518400  IN  NS  C.ROOT-SERVERS.NET.
    .           518400  IN  NS  D.ROOT-SERVERS.NET.

    ;; ADDITIONAL SECTION:
    A.ROOT-SERVERS.NET. 603670  IN  A   198.41.0.4
    A.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:503:ba3e::2:30
    B.ROOT-SERVERS.NET. 603670  IN  A   192.228.79.201
    B.ROOT-SERVERS.NET. 80684   IN  AAAA    2001:500:84::b
    C.ROOT-SERVERS.NET. 603670  IN  A   192.33.4.12
    C.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:7fe::53
    D.ROOT-SERVERS.NET. 603670  IN  A   199.7.91.13
    D.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:500:2d::d
    E.ROOT-SERVERS.NET. 603670  IN  A   192.203.230.10
    E.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:500:1::803f:235
    F.ROOT-SERVERS.NET. 603670  IN  A   192.5.5.241
    F.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:500:2f::f
    G.ROOT-SERVERS.NET. 603670  IN  A   192.112.36.4
    G.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:500:2d::d
    H.ROOT-SERVERS.NET. 603670  IN  A   128.63.2.53
    H.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:500:1::803f:235
    I.ROOT-SERVERS.NET. 603670  IN  A   192.36.148.17
    I.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:7fe::53
    J.ROOT-SERVERS.NET. 603670  IN  A   192.58.128.30
    J.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:503:c27::2:30
    K.ROOT-SERVERS.NET. 603670  IN  A   193.0.14.129
    K.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:7fd::1
    L.ROOT-SERVERS.NET. 603670  IN  A   199.7.83.42
    L.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:500:3::42
    M.ROOT-SERVERS.NET. 603670  IN  A   202.12.27.33
    M.ROOT-SERVERS.NET. 603670  IN  AAAA    2001:dc3::35

    ;; Query time: 0 msec
    ;; SERVER: 192.168.xxx.xxx#53(192.168.xxx.xxx)
    ;; WHEN: mar. sept. 01 09:46:49 CEST 2015
    ;; MSG SIZE  rcvd: 811

    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10842
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;server.mon.dom.        IN  A

    ;; AUTHORITY SECTION:
    hermes.         86400   IN  NSEC    hiphop. NS DS RRSIG NSEC
    hermes.         86400   IN  RRSIG   NSEC 8 1 86400 20150910170000 20150831160000 1518 . f6l2sOxUCof8wSHxmeX2h68cYdTWAIB3hp2GTX1d2qmUhK9FZ6LyC0mf 1uSsYxT85iZ/UYSd8wGNL3ENxzxVze/ejtQXcgNvlEeatqarwbpyG4m+ ltKK7MOG0gXa0Z1Ahc/bEFmaOIszFZftG4h9i4dtCrNEKFtw3bePx9u6 tdU=
    .           86400   IN  NSEC    aaa. NS SOA RRSIG NSEC DNSKEY
    .           86400   IN  RRSIG   NSEC 8 0 86400 20150910170000 20150831160000 1518 . p0msPrsZzvxWB0fpa3A06nPyTFzYZ4dWbseHVa1Ws0X0bnME3q80KnBB rLxl6H92Xzoo/i1zUEW/aLgMCSlSQThCAhuGBl0v0KgAui0kwH4dAYe8 IZkW3TW9rP4bUDiUQCfbfH1AJ0fJKG8/Ol4TmPSvFMu8iuhBa94IvNB/ 3mY=
    .           86400   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2015083101 1800 900 604800 86400
    .           86400   IN  RRSIG   SOA 8 0 86400 20150910170000 20150831160000 1518 . q0y5HOog7oNLlzyRc7iNIrkicosQl+4KkUKKFqr1vOdmcsVEJllbQtXT lHEt4yFHw4tBLDM1c2IDVB3BFIDi4gGBw10qUy7eJkOkFX+za1wrMMf2 /RbXSV5hVvdZRqUIPaVHvKJgqAzLc9ZjfprzxI/NG8C2Wt1AV0kwh0bj qZg=

    ;; Query time: 8 msec
    ;; SERVER: 192.203.230.10#53(192.203.230.10)
    ;; WHEN: mar. sept. 01 09:46:49 CEST 2015
    ;; MSG SIZE  rcvd: 657

Born to Kill EndUser !

[^] # Re: probablement que oui

Posté par Philippe M (site web personnel) le 01 septembre 2015 à 10:43. Évalué à 1. Dernière modification le 01 septembre 2015 à 11:13.

Autre test

    dig monserveur.example.com

    ; <<>> DiG 9.10.2-P3-RedHat-9.10.2-4.P3.fc22 <<>> monserveur.example.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60440
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;monserveur.example.com.        IN  A

    ;; ANSWER SECTION:
    monserveur.example.com. 86400   IN  A   192.168.xxx.01

    ;; AUTHORITY SECTION:
    example.com.        86400   IN  NS  ns2.example.com.
    example.com.        86400   IN  NS  gw.example.com.
    example.com.        86400   IN  NS  ns1.example.com.

    ;; ADDITIONAL SECTION:
    ns1.example.com.    86400   IN  A   192.168.xxx.02
    gw.example.com. 86400   IN  A   192.168.xxx.03

    ;; Query time: 0 msec
    ;; SERVER: 192.168.5.31#53(192.168.5.31)
    ;; WHEN: mar. sept. 01 10:38:01 CEST 2015
    ;; MSG SIZE  rcvd: 154


    dig monserveur

    ; <<>> DiG 9.10.2-P3-RedHat-9.10.2-4.P3.fc22 <<>> monserveur
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35917
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;monserveur.            IN  A

    ;; AUTHORITY SECTION:
    .           479 IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2015083101 1800 900 604800 86400

    ;; Query time: 0 msec
    ;; SERVER: 192.168.5.31#53(192.168.5.31)
    ;; WHEN: mar. sept. 01 10:42:22 CEST 2015
    ;; MSG SIZE  rcvd: 111

Dans le deuxième cas la résolution ne marche pas car pas de domaine indiqué.

Born to Kill EndUser !

[^] # Re: probablement que oui

Posté par NeoX le 01 septembre 2015 à 11:17. Évalué à 2.
ca c'est un cas plus classique,

c'est que dans le /etc/resolv.conf
tu ne lui dit pas d'ajouter example.com quand une requete part sans etre FQDN.

ton resolv.conf devrait ressembler à ca :
```
search example.com
nameserver IP_de_ton_serveur_DNS
```
et sinon, quand tu colles du code il faut mettre un retour à la ligne avant ```langage

et un apres ``` quand tu fermes le bloc.

exemple :

```sh
dig toto.example.com

QUERY…

ANSWER…
```

va donner
```
dig toto.example.com

QUERY...

ANSWER...
```
- [^] # Re: probablement que oui
  
  Posté par Philippe M (site web personnel) le 01 septembre 2015 à 11:25. Évalué à 1.
  La config réseau est envoyé par un serveur dhcp
```
cat /etc/resolv.conf 
# Generated by NetworkManager
search example.com
nameserver 192.168.xxx.02
nameserver 192.168.xxx.04
nameserver 192.168.xxx.03
```
  Sur Windows j'ai ajouté un suffix via la GPO dans la liste des domaines recherchés mais parfois j'ai l'impression qu'il en tient pas compte.
  
  Born to Kill EndUser !
  - [^] # Re: probablement que oui
    
    Posté par NeoX le 01 septembre 2015 à 11:46. Évalué à 3.
    
    je crois que quelqu'un a posé la question recemment,
    et dig semble ignoré le search du resolv.conf
    
    par contre un ping lamachine semblait etre un bon test
    car ca resolvait en ping lamachine.example.com

# +trace

Posté par 🚲 Tanguy Ortolo (site web personnel) le 01 septembre 2015 à 10:16. Évalué à 3.

Alors, deux choses.

Premièrement, quand tu fais un dig +trace, tu ne testes pas du tout ton résolveur local ; au contraire, tu demandes à dig de ne pas l'interroger et d'effectuer lui-même la résolution. Cela effectue la même chose que ce que ferait ton résolveur, mais sans passer par lui.

Et deuxièmement, oui, ton résolveur se comporte ainsi, enfin presque. Pour être précis, pour une requête donnée, ton résolveur va d'abord chercher dans son cache, et s'il n'y trouve pas la réponse, il va d'abord interroger un des serveurs racine, et redescendre vers des serveurs de plus en plus proches du nom demandé en fonction de ce qu'il obtient à chaque étape.
- [^] # Re: +trace
  
  Posté par Philippe M (site web personnel) le 01 septembre 2015 à 10:27. Évalué à 1.
  
  Les tests que je fais sont réalisés depuis un pc sur le réseau local. Donc si je comprends bien ta réponse, pour résoudre un nom de domaine ou chercher une machine sur mon réseau local le résolveur (mon pc je suppose) interroge son cache, si il y a rien il va sur un serveur racine, si y a rien il va chercher sur le DNS local ?
  
  Je trouve pas très logique, surtout pour un domaine local. Il me semble plus normal d'interroger le DNS le plus proche et si il trouve pas il va chercher le suivant.
  
  Born to Kill EndUser !
  - [^] # Re: +trace
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 01 septembre 2015 à 17:25. Évalué à 3.
    Donc si je comprends bien ta réponse, pour résoudre un nom de domaine ou chercher une machine sur mon réseau local le résolveur (mon pc je suppose)
    
    Non, le résolveur c'est celui qui est indiqué dans /etc/resolv.conf.
    
    interroge son cache, si il y a rien il va sur un serveur racine, si y a rien il va chercher sur le DNS local ?
    
    Oui, s'il s'agit d'une résolution sur un nom qui n'est pas dans une zone qu'il sert lui-même.
    
    Je trouve pas très logique, surtout pour un domaine local. Il me semble plus normal d'interroger le DNS le plus proche et si il trouve pas il va chercher le suivant.
    
    Désolé, j'avais mal compris la question, du coup je corrige ce que je disais. Pour une requête donnée, le résolveur :
    1. si le nom demandé est dans une zone qu'il sert, il renvoie ce qu'il a à son sujet ;
    2. sinon, si l'enregistrement demandé est dans son cache, il le renvoie ;
    3. sinon, il interroge les serveurs racine, puis selon les réponses, des serveurs de plus en plus proches du nom demandé, jusqu'à obtenir une réponse qui fait autorité, qu'il place alors dans son cache et renvoie au client.
# .example

Posté par 🚲 Tanguy Ortolo (site web personnel) le 01 septembre 2015 à 10:19. Évalué à 7.

Pour les exemples, il ne faut pas inventer des noms.de.domaine.bidon, domaine.tld ou autres mon.dom. Il y a des noms de domaines dédiés à cela : example.com, example.net, example.org, example.edu, et un TLD .example.

L'avantage, c'est qu'il est garanti qu'ils ne seront jamais utilisés pour autre chose, contrairement aux exemples bidons qui peuvent être utilisés pour de vrai, et pour lesquels on risque de nuire à leur propriétaire en les utilisant comme exemples.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.