Yop

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

lundi, 20 juillet 2015

Cas debug DNS

Je suis tombé sur un petit problème DNS interressant...
Le voici dans l'ordre...

- Je clic sur un lien et me voila envoyé vers un article du site http://www.leparisien.fr
- Patatra, marche pas.
- Vérification DNS:

$ dig www.leparisien.fr

; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> www.leparisien.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53534
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 448 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 15 21:36:55 CEST 2015
;; MSG SIZE rcvd: 46

$

Marche pas, status: SERVFAIL

- Interressant

$ dig cname www.leparisien.fr
www.leparisien.fr. 86400 IN CNAME 2-01-275c-0002.cdx.cedexis.net.

Bon cette 1ère partie fonctionne.

- Essayons de voir ce que donne 2-01-275c-0002.cdx.cedexis.net.

$ dig 2-01-275c-0002.cdx.cedexis.net.

; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> 2-01-275c-0002.cdx.cedexis.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7708
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2-01-275c-0002.cdx.cedexis.net. IN A

;; Query time: 25 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 15 21:39:41 CEST 2015
;; MSG SIZE rcvd: 59

Donc c'est lui qui ne résoud pas chez moi... status: SERVFAIL...

- Voyons voir les DNS de cdx.cedexis.net. ou plutôt ceux de cedexis.net.

$ dig ns cedexis.net. +short
flipa.cedexis.net.
flipd.cedexis.net.
flipg.cedexis.net.
$

- Testons les en direct

$ dig 2-01-275c-0002.cdx.cedexis.net. @flipa.cedexis.net. +short
cdn2.lequipe.fr.
$ dig 2-01-275c-0002.cdx.cedexis.net. @flipd.cedexis.net. +short
cdn2.lequipe.fr.
$ dig 2-01-275c-0002.cdx.cedexis.net. @flipg.cedexis.net. +short
cdn2.lequipe.fr.
$

Arf çà répond.
Alors que cela ne répond toujours pas avec mon serveur local:

$ dig 2-01-275c-0002.cdx.cedexis.net.

; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> 2-01-275c-0002.cdx.cedexis.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31061
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2-01-275c-0002.cdx.cedexis.net. IN A

;; Query time: 44 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 15 21:44:22 CEST 2015
;; MSG SIZE rcvd: 59

- Comme vous l'avez remarqué, j'interroge mon serveur récursif local.

Quand la demande passe par lui, cela ne fonctionne pas, sinon cela semble fonctionner.

$ dig 2-01-275c-0002.cdx.cedexis.net. @8.8.8.8 +short
cdn2.lequipe.fr.
62.210.149.48
$

- Mon serveur DNS local est Unbound, et il semble qu'un truc le dérange (uniquement avec ces serveurs DNS cedexis.net !)...

- Activation des logs verbeux par la ligne

verbosity: 3

- Et on regarde les logs:

1436989983] unbound[12494:1] info: reply from <cedexis.net.> 209.107.211.4#53
1436989983] unbound[12494:1] info: Capsforid fallback: getting different replies, failed
1436989983] unbound[12494:1] debug: return error response SERVFAIL

- Capsforid... Interressant

- Allons voir la doc de la conf d'Unbound

use-caps-for-id: <yes or no> Use 0x20-encoded random bits in the query to foil spoof
attempts. This perturbs the lowercase and uppercase of query
names sent to authority servers and checks if the reply still
has the correct casing. Disabled by default. This feature is
an experimental implementation of draft dns-0x20.

Donc en gros, avec ce paramètre à "yes", unbound envoit le nom à résoudre avec des minuscule/majuscule aléatoires, puis vérifie que la réponse à la question, qui contient la question, à bien les minuscules/majuscules aux bons endroits.

Et ce paramètre est a "yes" dans ma conf Unbound.

- Avant d'aller voir le draft dns-0x20, on lance wireshark

dns-wireshark-1.png


dns-wireshark-2.png

On voit clairement ce qui se passe, la réponse contient la question en minuscule, donc pas exactement comme elle a été posée.

- Vérifions avec un autre domaine.. Au hasard bortzmeyer.org

$ dig www.bortzmeyer.org +short
204.62.14.153
$

Mon unbound résoud parfaitement.

On voit bien que la réponse, contient bien cette fois exactement la question, avec les minuscules/majuscules aux bons endroits.

dns-wireshark-3.png

- Vérifions en mettant à "no" le use-caps-for-id (ce qui, il est vrai, est la valeur par défaut)

Bingo, çà fonctionne cette fois

$ dig 2-01-275c-0002.cdx.cedexis.net. +short
cdn2.lequipe.fr.
62.210.149.48
$

Unbound considère maintenant comme valide la réponse des serveurs de cedexis.net
Victoire, je peux lire mon article sur www.leparisien.fr

- C'est quoi cedexis.net, ils auraient leur propre serveur DNS maison ?

"We’re dedicated to building a faster web for everyone in the world. Cedexis optimizes web performance across data centers, content delivery networks (CDNs) and clouds..."

Ah oui, çà colle, ils seraient bien capable d'avoir leur implémentation DNS maison.

- Maintenant allons voir ce fameux draft dns-0x20.

Déjà on peut noter que c'est rédigé par Paul Vixie de l'ISC, c'est du sérieux.

Je vais vous résumer en gros:

Le protocole DNS est tel, qu'il y a parfois moyen de réussir à forger des réponses et donc de poluer les caches DNS.
Il est donc ensuite possible de rediriger les users vers des faux site web.. bref pas cool.. mais rien de nouveau pour l'instant.
Mais tout moyen permettant d'améliorer la sécurité, en rendant plus difficile de forger des fausses réponses, sans tout casser au protocole existant, est donc la bienvenue.
Ce draft expose un moyen d'y parvenir.

Comme vous l'avez compris (pour les 3 personnes qui sont arrivées jusqu'ici, chapeau bas), il s'agit de mettre des majuscules/minuscules aléatoires dans la question envoyée au serveur DNS, puis considérer comme invalides, les réponses qui ne reprendaient pas la question en respectant la casse.

Pour forger une fausse réponse DNS et donc polluer le cache, il faudrait donc non seulement trouver le bon ID (Kaminsky, Paradoxe des anniversaires etc..) mais donc en plus avoir les bonnes majuscules/minuscules aux bons endroits. (Pas con le Paul Vixie ! )

Mais pour que l'idée soit exploitable, il faut donc voir ce que dit la RFC 1035 et voir comment réagissent les principales implémentations de serveurs DNS authoritatives.

Pour ce qui est de la RFC1035 on peut lire en 7.3

that the question section corresponds to the information currently desired

Mmmm...Ce n'est pas super précis ... Est-ce que cela inclu le respect de la casse... ?

Voyons voir les différentes implémentations:

On peut lire en 6.1

Several popular authoritative DNS implementations including ISC BIND (versions 4, 8, and 9), Nominum ANS, Akamai AKADNS, Neustar UltraDNS, Verisign Atlas, NLNetLabs NSD, PowerDNS, and DJBDNS were tested. All copied the question name exactly, bit for bit, from the request into the response.

Et en 6.2

Operational testing has revealed a small set of rare and/or private label authoritative DNS implementations who modify the 0x20 bits in question names while copying the question section from the request to the response. Usually this modification is to set the 0x20 bit, thus converting a domain name to be all-lower-case (0x61..0x7A, e.g., a-z).

- Conclusion:

Toutes les implémentations de serveur DNS authoritative majeures répondent en respectant la casse de la question.
Si les serveurs récursifs pouvaient implémenter cette vérification, ceci pourrrait améliorer la sécurité du DNS.
Et c'est d'ailleurs la 1ère fois que j'ai ce problème avec un serveur DNS, je vais donc garder mon paramêtre, et tant pis pour le site web du Parisien ;)

Les serveurs DNS de cedexis.net ne semblent pas tourner sous une "popular authoritative DNS implementations" :)
Je les ai contacté pour les informer.... si çà les interresse...


EDIT 31 Août 2015:

Antoine de Cedexis est tombé sur le billet et a remonté l'information aux bonnes personnes chez eux.
Je contaste que les modifications nécessaires (indiquées dans la roadmap dans son commentaire ci-dessous) semblent avoir été implémentées en production sur leurs serveurs DNS, et les résolutions ce font donc désormais correctement en respectant le draft dns-0x20.
Merci Antoine ;)

mercredi, 31 octobre 2012

Underscore et DNS

  • On ne peut PAS avoir un underscore dans un nom (record A, CNAME)

A "name" (Net, Host, Gateway, or Domain name) is a text string [...] drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.)

RFC952

Certaines parties de cette RFC (longueur du nom etc..) ne sont plus d'actualité car mises à jour dans des RFC plus récentes, mais a priori rien n'a changé pour la partie qui indique que l'underscore n'est pas authorisé pour un nom.


  • On peut avoir un underscore dans d'autres type d'enregistrement (SRV, TXT etc.. )

The format of the SRV RR

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature.

RFC2782


Bind ignore tout simplement un enregistrement A qui contient un underscore.

mardi, 4 octobre 2011

Modification de valeurs dans beaucoup de zones

Rien d'extraordinaire.. mais vu que j'ai beaucoup de zones à modifier.. et que je devrais faire la même chose dans l'autre sens...

  • Modification du MX pour toutes les zones:

$ for FICHIER in `find /var/chroot-named/etc/namedb/zones/pri/ -type f`; do sed -i 's/10 smtp.example.org./50 smtp.example.org./g' $FICHIER ; done

  • Modification du serial pour toutes les zones:

$ for FICHIER in `find /var/chroot-named/etc/namedb/zones/pri/ -type f`; do sed -i '/serial - YYYYMMDDxx/s/[0-9][0-9]*/2011100401/' $FICHIER ; done

Car la ligne qui contient le serial dans mes zones contient:

1111111111 ; serial - YYYYMMDDxx

Source

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...

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.

- page 1 de 3