Le système AS112, décrit dans ce
RFC, est à la fois un utile composant du
DNS, améliorant les performances et reduisant
la charge du réseau, un banc d'essai pour des nouvelles techniques
comme l'anycast, et une
expérimentation sociale, celle d'un service 100 % acentré.
Un certain nombre de sites connectés à
l'Internet utilisent des adresses IP privées, tirées du RFC 1918. Bien des logiciels, lorsqu'ils voient
passer un nouveau client, font une résolution
DNS pour obtenir le nom du client en fonction
de son adresse IP (résolution dite PTR). C'est
par exemple le cas du serveur de courrier
Postfix, chez qui ce comportement n'est pas
débrayable. Lorsque l'adresse IP est privée, il ne sert à rien de
poser la question au DNS public. Par définition, celui-ci ne peut pas
savoir que MaPetiteEntreprise utilise
192.168.1.0/24
et a attribué
192.168.1.33
à
posteclientX.mapetiteentreprise.example
. La bonne
pratique est donc que l'administrateur réseaux
d'un site qui utilise ces adresses privées doit configurer des
serveurs DNS pour répondre aux requêtes PTR (cf. RFC 6303). Pour voir cela, on peut utiliser l'option -x
de dig, qui permet de faire
automatiquement une résolution d'adresse en nom. Le domaine
in-addr.arpa
(RFC 5855) accueille la forme inversée des
adresses (192.168.1.33
devient
33.1.168.192.in-addr.arpa
). Testons ici une adresse publique :
% dig -x 192.134.4.20
...
;; ANSWER SECTION:
20.4.134.192.in-addr.arpa. 172800 IN PTR rigolo.nic.fr.
Mais beaucoup d'administrateurs réseaux sont négligents, surchargés
de travail, incompétents ou les trois à la fois. Ils ne configurent
pas ces serveurs DNS et, résultat, la requête PTR sort de leur réseau
et va taper sur les serveurs DNS de la racine puis à ceux de in-addr.arpa
. (Une bonne partie du trafic semble ainsi venir des réseaux 3G, où le smartphone ne reçoit qu'une adresse privée et où le résolveur DNS qui lui est indiqué ne connait pas les zones correspondantes.) Ceux-ci ont normalement
autre chose à faire que de répondre à des requêtes qui sont, dès le
départ, des erreurs. Ils délèguent donc à l'AS112, un ensemble de
serveurs de noms qui est chargé de répondre « ce nom n'existe pas » à
toutes ces requêtes parasites. L'AS112 est donc un puits où finissent
les erreurs. Initialement normalisé dans le RFC 6304, il est désormais décrit par ce nouveau RFC. Le nouvel
AS112 introduit une importante nouveauté, un mécanisme de délégation
utilisant les enregistrements DNAME (RFC 6672) et qui
permet de désigner plus facilement des zones à diriger vers le
puits. Il y a donc désormais l'ancien AS112 (qui
continue à fonctionner et à servir les zones du RFC 1918) et le nouvel AS112, qui servira
les futures zones comme les ULA
IPv6 du RFC 4193, ou
comme des TLD tels que
.local
ou .home
.
On peut voir la délégation de l'ancien AS112 (ancien mais toujours
utilisé) avec dig (sauf si votre résolveur suit
les recommandations du RFC 6303) :
% dig NS 168.192.in-addr.arpa
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> NS 168.192.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56121
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;168.192.in-addr.arpa. IN NS
;; ANSWER SECTION:
168.192.in-addr.arpa. 8726 IN NS blackhole-2.iana.org.
168.192.in-addr.arpa. 8726 IN NS blackhole-1.iana.org.
;; ADDITIONAL SECTION:
blackhole-1.iana.org. 604 IN A 192.175.48.6
blackhole-1.iana.org. 603 IN AAAA 2620:4f:8000::6
blackhole-2.iana.org. 603 IN A 192.175.48.42
blackhole-2.iana.org. 603 IN AAAA 2620:4f:8000::42
;; Query time: 2 msec
;; SERVER: 217.70.184.225#53(217.70.184.225)
;; WHEN: Fri May 15 10:28:38 2015
;; MSG SIZE rcvd: 197
La délégation va être conservée dans les mémoires caches des
résolveurs DNS et la racine ou
in-addr.arpa
ne seront donc plus embêtés, après la
première requête.
Pour le nouvel AS112, utilisant la technique du RFC 7535, la délégation est :
% dig NS empty.as112.arpa
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> NS empty.as112.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25550
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;empty.as112.arpa. IN NS
;; ANSWER SECTION:
empty.as112.arpa. 3595 IN NS blackhole.as112.arpa.
;; ADDITIONAL SECTION:
blackhole.as112.arpa. 3595 IN A 192.31.196.1
blackhole.as112.arpa. 3595 IN AAAA 2001:4:112::1
;; Query time: 2 msec
;; SERVER: 217.70.184.225#53(217.70.184.225)
;; WHEN: Fri May 15 10:29:25 2015
;; MSG SIZE rcvd: 113
Mais qui sont ces machines 192.175.48.6
,
192.175.48.42
et 192.31.196.1
? Des très gros serveurs payés par un mécène
et installés à un endroit bien connecté ? Pas du tout. C'est ici que
rentre en jeu l'AS112. Ce dernier est composé d'un réseau informel de
dizaines de machines un peu partout dans le monde et qui annoncent
toutes être 192.175.48.6
et
192.175.48.42
(pour l'ancien préfixe) et
192.31.196.1
(pour le nouveau). Chacune de ces machines encaisse une partie
de la charge. L'AS112 n'a pas de chef, juste un site Web et un
RFC, ce RFC 7534.
L'AS112 doit son nom au numéro de système
autonome qui lui a été attribué (et qui est désormais dans
le registre des AS spéciaux, créé par le
RFC 7249). Ses serveurs utilisent
l'anycast (RFC 4786) pour distribuer la
charge entre eux. Avant Global Anycast, c'était
donc le premier projet d'anycast entre serveurs
faiblement coordonnés. Une histoire complète de l'AS112 figure en
annexe A de notre RFC.
Les détails pratiques, maintenant. La liste des zones servies par
l'ancien AS112 (Direct Delegation)
figure en section 3.2. (Le nouvel AS112 suit un système de délégation
dynamique décrit dans le RFC 7535.) Elle comprend
10.in-addr.arpa
pour le réseau
10.0.0.0/8
,
de 16.172.in-addr.arpa
à
31.172.in-addr.arpa
pour le
172.16.0.0/12
, et
168.192.in-addr.arpa
pour le
192.168.0.0/16
, les préfixes du RFC 1918. Elle inclus aussi
254.169.in-addr.arpa
pour le préfixe « local au
lien » du RFC 5735. Pour aider à l'identification du
nœud qui répond, les serveurs de l'AS112 servent également la
zone hostname.as112.net
, ici à
Paris :
% dig +nsid TXT hostname.as112.net
; <<>> DiG 9.7.3 <<>> +nsid TXT hostname.as112.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1078
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hostname.as112.net. IN TXT
;; ANSWER SECTION:
hostname.as112.net. 267 IN TXT "Unicast IP: 193.17.192.194"
hostname.as112.net. 267 IN TXT "See http://as112.net/ for more information."
hostname.as112.net. 267 IN TXT "See http://noc.hivane.net/cgi-bin/dsc-grapher.pl for local information."
hostname.as112.net. 267 IN TXT "Paris, FR"
hostname.as112.net. 267 IN TXT "Hivane Networks"
;; AUTHORITY SECTION:
hostname.as112.net. 267 IN NS blackhole-2.iana.org.
hostname.as112.net. 267 IN NS blackhole-1.iana.org.
;; ADDITIONAL SECTION:
blackhole-1.iana.org. 241 IN A 192.175.48.6
blackhole-2.iana.org. 241 IN A 192.175.48.42
;; Query time: 1 msec
;; SERVER: 217.70.184.225#53(217.70.184.225)
;; WHEN: Wed Jul 6 12:36:14 2011
;; MSG SIZE rcvd: 348
On note que les préfixes IPv6 n'y figurent
pas. Pour le nouvel AS112, voici le même test :
% dig +nsid TXT hostname.as112.arpa
; <<>> DiG 9.9.2-P2 <<>> +nsid TXT hostname.as112.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22893
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;hostname.as112.arpa. IN TXT
;; ANSWER SECTION:
hostname.as112.arpa. 604318 IN TXT "RIPE NCC" "Amsterdam, The Netherlands"
hostname.as112.arpa. 604318 IN TXT "See http://www.as112.net/ for more information."
;; AUTHORITY SECTION:
hostname.as112.arpa. 604317 IN NS blackhole.as112.arpa.
;; Query time: 16 msec
;; SERVER: 192.168.2.254#53(192.168.2.254)
;; WHEN: Fri May 15 10:34:06 2015
;; MSG SIZE rcvd: 180
(On peut avoir une liste des serveurs, à jour, sur
le site officiel).
La section 3.3 décrit les serveurs de noms qui reçoivent la
délégation, joliment (mais incorrectement, puisqu'ils répondent)
nommés blackhole-1.iana.org
et
blackhole-2.iana.org
, et
blackhole.as112.arpa
pour le nouvel AS (en dépit de leurs noms, les
serveurs de l'AS112 ne sont pas gérés par
l'IANA, cf. section 7). Dans le champ
MNAME
du SOA de la zone
déléguée, on trouve également (pour l'ancien AS112) prisoner.iana.org
dont la tâche principale est de répondre aux mises à jour dynamiques
(RFC 2136) que certaines machines envoient audit
MNAME
. Du temps du RFC 6304, ces serveurs n'étaient accessibles qu'en IPv4 mais ils
ont désormais également des adresses IPv6.
Ce RFC 7534 n'est pas seulement la description d'une
technique mais également un HOWTO sur la
configuration d'un serveur de l'AS112. De tels textes, prévus pour les
administrateurs système, sont rares dans les
RFC. La section 4 décrit ainsi tout
ce que doit savoir le volontaire qui va créer un nouveau
nœud. Il doit connaître BGP (RFC 4271), nécessaire pour
l'anycast (RFC 4786) et la gestion d'un serveur DNS faisant
autorité. Les serveurs de l'AS112 peuvent être situés n'importe où
mais ils sont surtout utiles dans les endroits bien connectés,
notamment les points d'échange. Ils peuvent
être locaux (annonçant les routes avec la communauté
BGP no-export
, 0xFFFFFF01,
cf. RFC 1997), ou
globaux (servant le monde entier). Et naturellement, ils doivent se
coordonner (via une liste de diffusion) avec les
autres serveurs de l'AS112.
L'AS112 n'impose pas de système d'exploitation particulier (section
4.3) mais tous les serveurs existants semblent utiliser
Unix et un grand nombre (c'est difficile à dire, puisque
l'AS112 ne contrôle pas tout ce qui se passe sur les serveurs) se
servent de BIND. Il est recommandé que la
machine AS112 soit dédiée à cette tâche : ces serveurs reçoivent
parfois un trafic intense qui pourrait perturber leurs autres
activités.
Le serveur signale son existence et sa disponibilité en
BGP. Il faut donc coupler le serveur de noms au
serveur BGP, pour que l'arrêt du serveur DNS entraîne l'arrêt de
l'annonce (le RFC ne fournit pas de script pour cela). Un exemple de
comment cela peut se réaliser sur Linux, avec
les adresses de l'AS112 attachées à une interface dummy
, est
(code utilisé sur un serveur anycast réel, quoique
pas de l'AS112) :
# Load the variables (the machine is a RedHat)
. /etc/sysconfig/network-scripts/ifcfg-eth0
# Test if the name server actually works. Do not use ps: the server
may be there but unresponsive
TMP=(`dig +short +time=1 +tries=1 @${IPADDR} SOA example.`)
MASTER=${TMP[0]:=somethingwaswrong}
# Normal reply or not?
if test ${MASTER} != "nsmaster.nic.example."
then
# Disable the interface: Quagga will stop announcing the route
ifdown dummy0
# Raise an alarm, send SMS, etc
fi
Le serveur BGP annonce les préfixes de l'ancien AS112,
192.175.48.0/24
et
2620:4f:8000::/48
, qui couvrent les adresses de tous
les serveurs et l'origine est évidemment
112 (les préfixes
IP sont dans le
registre des préfixes
spéciaux créé par le RFC 6890). Si le serveur
gère la zone du nouvel AS112, il annonce en BGP
192.31.196.0/24
et
2001:4:112::/48
.
Les exemples du RFC supposent que le serveur BGP est
Quagga mais cela peut évidemment marcher avec
d'autres. Dans l'exemple ci-dessous, tiré du RFC (section 4.4), le router
ID est 203.0.113.1
et le serveur BGP a
deux pairs, 192.0.2.1
et
192.0.2.2
. Voici un extrait du
bgpd.conf
(la version intégrale est dans le
RFC) :
hostname my-router
...
router bgp 112
bgp router-id 203.0.113.1
network 192.175.48.0/24
neighbor 192.0.2.1 remote-as 64496
neighbor 192.0.2.1 next-hop-self
neighbor 192.0.2.2 remote-as 64497
neighbor 192.0.2.2 next-hop-self
En farfouillant sur
le site
officiel (pas très bien organisé, je trouve), on peut trouver
d'autres exemples.
Le serveur AS112 a ensuite besoin d'un serveur DNS faisant autorité
(section 4.5), évidemment compatible avec toutes les règles du DNS
(RFC 1034). Les exemples de configuration du RFC
sont fondés sur BIND. Voici un extrait du
named.conf
(la version intégrale est dans le
RFC) :
options {
listen-on {
...
// the following addresses correspond to AS112 addresses, and
// are the same for all AS112 nodes
192.175.48.1; // prisoner.iana.org (anycast)
192.175.48.6; // blackhole-1.iana.org (anycast)
192.175.48.42; // blackhole-2.iana.org (anycast)
// The following address is used to support DNAME redirection
// AS112 service and is the same for all AS112 nodes.
192.31.196.1; // blackhole.as112.arpa (anycast)
};
listen-on-v6 {
...
// The following addresses are used to support Direct Delegation
// AS112 service and are the same for all AS112 nodes.
2620:4f:8000::1; // prisoner.iana.org (anycast)
2620:4f:8000::6; // blackhole-1.iana.org (anycast)
2620:4f:8000::42; // blackhole-2.iana.org (anycast)
// The following address is used to support DNAME redirection
// AS112 service and is the same for all AS112 nodes.
2001:4:112::1; // blackhole.as112.arpa (anycast)
};
recursion no; // authoritative-only server
};
// RFC 1918
zone "10.in-addr.arpa" { type master; file "db.empty"; };
...
// RFC 5735
zone "254.169.in-addr.arpa" { type master; file "db.empty"; };
// DNAME redirection AS112 Service
zone "empty.as112.arpa" { type master; file "db.dr-empty"; };
// also answer authoritatively for the HOSTNAME.AS112.NET zone,
// which contains data of operational relevance
zone "hostname.as112.net" {
type master;
file "db.hostname.as112.net";
};
zone "hostname.as112.arpa" {
type master;
file "db.hostname.as112.arpa";
};
Un exemple équivalent pour NSD (utilisé sur le nœud AS112 de Paris) est disponible en
as112-nsd.conf
(ancien AS112 seulement). Pour simplifier son écriture, il a été
produit à partir d'un source en M4,
as112-nsd.conf.m4
.
Que contiennent les fichiers de zone db.empty
,
db-fr.empty
,
db.hostname.as112.net
et db.hostname.as112.arpa
? Conformes à la syntaxe
de la section 5 du RFC 1035, ils sont communs à
BIND et NSD. Les deux premiers, comme leur nom l'indique, sont des fichiers de
zone vide, puisque le serveur AS112 ne connait évidemment rien : il ne
peut que répondre NXDOMAIN
(ce nom n'existe pas)
à toutes les requêtes. Ils ne contiennent donc que les informations
obligatoires à toute zone (SOA, avec une adresse
de contact appropriée) et NS. Les deux autres zones servent au déboguage de l'AS112,
lorsqu'on veut obtenir des informations sur le serveur AS112
courant. Un contenu typique est juste composé d'enregistrements TXT :
TXT "Human AS112 server" "Minas Tirith, Gondor"
TXT "Forbidden to orcs and nazguls."
TXT "See http://www.as112.net/ for more information."
et parfois d'une localisation (cf. RFC 1876).
Le résultat sur un site réel étant :
% dig ANY hostname.as112.net.
; <<>> DiG 9.7.3 <<>> ANY hostname.as112.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41528
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hostname.as112.net. IN ANY
;; ANSWER SECTION:
hostname.as112.net. 604796 IN LOC 37 58 22.590 N 23 44 43.890 E 100.00m 100m 10m 10m
hostname.as112.net. 604796 IN TXT "See http://as112.net/ for more information."
hostname.as112.net. 604796 IN TXT "Unicast IP: as112.grnet.gr"
hostname.as112.net. 604796 IN TXT "Greek Research & Technology Network" "Athens, Greece"
hostname.as112.net. 604796 IN SOA flo.gigafed.net. dns.ryouko.imsb.nrc.ca. 1 604800 60 604800 604800
hostname.as112.net. 604796 IN NS blackhole-2.iana.org.
hostname.as112.net. 604796 IN NS blackhole-1.iana.org.
;; AUTHORITY SECTION:
hostname.as112.net. 604796 IN NS blackhole-1.iana.org.
hostname.as112.net. 604796 IN NS blackhole-2.iana.org.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 6 12:51:53 2011
;; MSG SIZE rcvd: 391
(La version intégrale des quatre fichiers de zone figure
dans le RFC.)
Une fois le nœud installé, il faut évidemment le tester (avec
dig, par exemple). Si les réponses aux requêtes
PTR sont correctes, mais pas celles aux requêtes pour le nom
hostname.as112.{net,arpa}
, c'est sans doute un problème
de routage (on est envoyés sur un autre nœud de l'AS112) et il
faut alors sortir traceroute et les
looking glasses (section 4.6). Des
tests dignes de ce nom doivent être faits depuis plusieurs
FAI, et
doivent tester les trois (ou quatre pour les nouveaux nœuds) adresses IPv4 de
l'AS112, plus ses adresses IPv6.
Le bon fonctionnement de l'AS112 ne dépend pas uniquement de sa
configuration initiale mais aussi de sa gestion et surveillance
quotidiennes. La section 5 est consacrée aux questions
opérationnelles. Le nœud doit être surveillé automatiquement,
pour s'assurer qu'il répond toujours. S'il doit être arrêté (par
exemple pour une maintenance prévue), il faut s'assurer que l'annonce
BGP stoppe (autrement, BGP annonce un trou noir, d'où aucune réponse
ne reviendra). Autre point important de la gestion opérationnelle d'un
serveur de l'AS112, des statistiques, obtenues à partir d'outils comme
DSC ou dnstop. Quelle
est l'utilisation réelle de l'AS112 ? Ces statistiques n'étant pas
consolidées globalement, c'est difficile à dire. Certains opérateurs
publient leurs chiffres mais pas tous. Par exemple, le serveur
d'Ottawa voit mille requêtes par seconde
(cf. « AS112
Intro » par l'un des auteurs du RFC), celui géré par le RIPE-NCC dans les mille cinq cents, et celui à
Paris deux fois plus (voir les
graphiques), ce qui fait quand même quelques mégabits par
seconde. La majorité des types demandés est évidemment du PTR mais il
y a aussi un flux important de TXT, apparemment dus à la technologie
SD (Service Discovery) d'Apple (voir des statistiques plus détaillées à la fin).
Le nouveau serveur peut alors être annoncé sur les listes
appropriées (par exemple, chaque point d'échange a en général la
sienne). Enfin, bien que chaque serveur de l'AS112 puisse fonctionner
indépendemment des autres, il est évidemment préférable de se
coordonner avec les petits camarades (section 6) en écrivant à la liste officielle.
Et dans le futur ? La section 7 explore l'avenir possible de
l'AS112. Idéalement, il devrait disparaître petit à petit au fur et à
mesure que les administrateurs réseaux prennent soin de ne pas laisser
fuir les requêtes PTR pour les réseaux privés, comme recommandé dans
le RFC 6303. Le déploiement de logiciels
respectant ce principe dès le début pourrait aider. Toutefois,
aujourd'hui, les opérateurs de l'AS112 n'observent pas de tendance à
la baisse du trafic. Même des années après le déploiement de serveurs
mettant en œuvre le RFC 6303, il est
probable que le trafic de l'AS112 ne tombera pas à zéro et que ce
service restera donc nécessaire.
Enfin, qu'en est-il de la sécurité ? Comme le rappelle la section
9, les requêtes DNS auxquelles répond l'AS112 ne devraient jamais y
arriver, normalement. Elles auraient dû rester sur le réseau local. En
sortant, elles exposent de l'information interne, qui était peut-être
privée (qu'il y ait un serveur AS112 qui y réponde ou pas ne change guère ce
risque).
Plus rigolo, comme ces requêtes sont en général involontaires
(comme indiqué, elles auraient dû rester privées), les réponses sont
inattendues. Plus d'un IDS a donc crié que
l'AS112 essayait d'attaquer le réseau. Le RFC 6305 a été écrit pour fournir une réponse toute faite aux
administrateurs incompétents qui accusaient l'IANA ou l'AS112.
Comme l'AS112 n'a pas de chef et que l'anycast
ne permet pas de limiter le nombre de participants, il est tout à fait
possible de fantasmer sur l'hypothèse d'un nœud AS112 voyou, qui
donnerait exprès de mauvaise réponses. Ce problème (purement
théorique) n'a pas vraiment de solution. Signer les zones avec
DNSSEC semble franchement
excessif, et difficile à réaliser de manière sûre puisqu'il faudrait
distribuer la clé privée à tous les opérateurs de l'AS112.
L'annexe A du RFC expose la longue histoire de l'AS112, de ses
débuts en 2002 (les adresses IP
privées datent de 1996) à son état actuel,
après la redélégation en 2011 de
in-addr.arpa
, autrefois sur les serveurs de la
racine (RFC 5855). L'AS112 a été le premier
déploiement massif de l'anycast et a donc joué un
rôle primordial dans l'évaluation de cette technologie.
À noter que, d'après la
liste officielle des sites, il existe au moins un serveur AS112 en
France, chez Hivane, désormais (novembre 2011) connecté au France-IX. Malgré cela, les requêtes françaises pour
les serveurs de l'AS112 voyagent souvent loin. C'est un problème
banal comme le montrait l'excellente présentation « Investigating
AS112 Routing and New Server Discovery ».
Voici quelques analyses sur le trafic de ce serveur français, faites avec
DNSmezzo. Le fichier pcap
fait 6,8 Go. Il y a 43 701 087 paquets DNS dont 21 858 845 sont des
requêtes. Les données ont été prises un vendredi, de 13h40 à 15h30 (heure
locale). Regardons d'abord les types de données demandés :
dnsmezzo=> SELECT (CASE WHEN type IS NULL THEN qtype::TEXT ELSE type END),
meaning,
count(results.id)*100/(SELECT count(id) FROM DNS_packets WHERE query) AS requests_percent FROM
(SELECT id, qtype FROM dns_packets
WHERE query) AS Results
LEFT OUTER JOIN DNS_types ON qtype = value
GROUP BY qtype, type, meaning ORDER BY requests_percent desc;
type | meaning | requests_percent
-------+----------------------------------------+------------------
PTR | a domain name pointer | 57
TXT | text strings | 35
SOA | marks the start of a zone of authority | 6
CNAME | the canonical name for an alias | 0
MX | mail exchange | 0
AAAA | IP6 Address | 0
40 | | 0
DS | Delegation Signer | 0
...
La première place des
PTR
est normale. Celle des
TXT
est plus surprenante. En regardant les noms
utilisés
(
cf._dns-sd._udp.Y.X.243.10.in-addr.arpa
...), on
voit qu'ils sont dus à la technique
Service
Discovery d'Apple, un système normalement confiné au réseau
local mais qui bave beaucoup à l'extérieur.
Et quels sont les domaines les plus populaires ?
dnsmezzo=> SELECT substr(registered_domain,1,46) AS domain,
count(id)*100/(SELECT count(id) FROM DNS_packets WHERE query) AS requests_percent
FROM dns_packets WHERE query GROUP BY registered_domain ORDER BY requests_percent DESC LIMIT 30;
domain | requests_percent
------------------+------------------
10.in-addr.arpa | 78
192.in-addr.arpa | 12
172.in-addr.arpa | 7
169.in-addr.arpa | 1
151.in-addr.arpa | 0
i~-addr.arpa | 0
83.in-addr.arpa | 0
| 0
gfi.private | 0
local.de | 0
grupofdez.com | 0
....
On voit que le réseau
10.0.0.0/8
est nettement le
plus populaire. On notera les trois derniers, sans doute des erreurs
de configuration.
Et quels sont les résolveurs les plus actifs ? En agrégeant les
préfixes IPv4 en /28 :
dnsmezzo=> SELECT set_masklen(src_address::cidr, 28) AS client, count(id)*100/(SELECT count(id) FROM DNS_packets WHERE query) AS requests_percent
FROM dns_packets WHERE query GROUP BY set_masklen(src_address::cidr, 28)
ORDER by requests_percent DESC LIMIT 30;
client | requests_percent
--------------------+------------------
CENSURE.160/28 | 29
CENSURE.0/28 | 10
CENSURE.16/28 | 8
CENSURE.96/28 | 6
...
Oui, j'ai préféré ne pas donner les adresses. Je dirai simplement que
ces quatre plus gros sont des opérateurs de téléphonie mobile, deux
français et deux extrême-orientaux (les mystères du routage...).
Merci à Clément Cavadore, administrateur du plus gros (en nombre de
requêtes) serveur AS112 du monde, pour les données et pour sa relecture.
Les principaux changements depuis le RFC 6304 :
- Adresses IPv6 pour les serveurs de l'AS112,
- « Nouvel AS112 », servant la zone
empty.as112.arpa
, vers laquelle les zones à gérer
seront redirigées par un DNAME,
- Enregistrement des préfixes à l'IANA.