Le système
Comme beaucoup de bonnes choses sur l'Internet, la documentation
arrive comme
Un certain nombre de sites connectés à
l'
% 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
On peut voir la délégation de l'AS112 avec dig :
> DiG 9.7.1 <<>> NS 168.192.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56273
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;168.192.in-addr.arpa. IN NS
;; ANSWER SECTION:
168.192.in-addr.arpa. 300 IN NS blackhole-2.iana.org.
168.192.in-addr.arpa. 300 IN NS blackhole-1.iana.org.
;; ADDITIONAL SECTION:
blackhole-1.iana.org. 3500 IN A 192.175.48.6
blackhole-2.iana.org. 3500 IN A 192.175.48.42
;; Query time: 29 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 6 12:34:19 2011
;; MSG SIZE rcvd: 141
]]>
La délégation va être conservée dans les mémoires caches des
résolveurs DNS et la racine ou
Mais qui sont ces machines
L'AS112 doit son nom au
Les détails pratiques, maintenant. La liste des zones servies
figure en section 2.1. Elle comprend
> 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
La section 2.2 décrit les serveurs de noms qui reçoivent la
délégation, joliment (mais incorrectement, puisqu'ils répondent)
nommés
Ce
L'AS112 n'impose pas de système d'exploitation particulier (section
3.3) mais tous les serveurs existants semblent utiliser
Le serveur signale son existence et sa disponibilité en
# 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 le préfixe
Les exemples du RFC supposent que le serveur BGP est
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 3.5), évidemment compatible avec toutes les règles du DNS
(
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)
};
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"; };
// 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";
};
Un exemple équivalent pour
Que contiennent les fichiers de zone
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.
> 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 deux fichiers de zone figure
dans le RFC.)
Une fois le nœud installé, il faut évidemment le tester (avec
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 4 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'
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 5) en écrivant à la liste officielle.
Et dans le futur ? La section 6 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
Il pourrait même s'étendre à
Enfin, qu'en est-il de la sécurité ? Comme le rappelle la section 8, 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 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
Comme l'AS112 n'a pas de chef et que l'
L'annexe A du RFC expose la longue histoire de l'AS112, de ses
débuts en
On voit que neuf ans ont donc été nécessaires pour documenter ce projet. Une des raisons du retard était la longue discussion pour savoir si le RFC devait documenter l'état actuel de l'AS112 (ce qui a finalement été fait) ou son état souhaité (avec, par exemple, les nouvelles zones IPv6).
À 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
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
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
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 pour les données et pour sa relecture.