In a few words, this organization manages the administrative tasks to register domains in the .be zone and also maintains a set of .be-root servers which forward requests to the right name servers to resolve .be domains. At the moment, nine servers are used by dns.be:
;; ANSWER SECTION: dns.be. 84061 IN NS a.ns.dns.be. dns.be. 84061 IN NS b.ns.dns.be. dns.be. 84061 IN NS c.ns.dns.be. dns.be. 84061 IN NS x.dns.be. dns.be. 84061 IN NS london.ns.dns.be. dns.be. 84061 IN NS milano.ns.dns.be. dns.be. 84061 IN NS prague.ns.dns.be. dns.be. 84061 IN NS brussels.ns.dns.be. dns.be. 84061 IN NS amsterdam.ns.dns.be.
One of their goal is to increase the security and accuracy of the .be TLD. To achieve this, they have a project to increase the usage of “Anycasting“.
Anycast (like unicast, broadcast or multicast) is a method to route packets issued by a client to the best server on a pure routing level. The best server will be selected depending on the geographic location, availability or network costs.
An anycast address can be assigned to several servers spread over the network (the Internet). Anycast relies on BGP to announce the prefix to the whole Internet. But an example will be much more interesting.
Let’s have a look at the following name server: x.dns.be. First, resolve the host name and then query the RIPE WHOIS database:
# host x.dns.be x.dns.be has address 188.8.131.52 # whois -h whois.ripe.net 184.108.40.206 % This is the RIPE Whois query server #3. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html % Note: This output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '220.127.116.11 - 18.104.22.168' inetnum: 22.214.171.124 - 126.96.36.199 netname: ICB-CO-UK descr: Internet Computer Bureau country: GB org: ORG-ICB1-RIPE admin-c: PMK3-RIPE tech-c: PMK3-RIPE status: ASSIGNED ANYCAST mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-by: ICB-MNT mnt-by: NETCONNEX-MNT mnt-routes: ICB-MNT mnt-routes: NETCONNEX-MNT mnt-domains: ICB-MNT mnt-domains: NETCONNEX-MNT source: RIPE # Filtered organisation: ORG-ICB1-RIPE org-name: Internet Computer Bureau org-type: OTHER address: Box 4040, Christchurch, BH23 1XW e-mail: firstname.lastname@example.org mnt-ref: ICB-MNT mnt-by: ICB-MNT source: RIPE # Filtered person: Paul M. Kane address: Internet Computer Bureau plc address: P.O. Box 4040 address: Christchurch address: UK address: BH23 1XW phone: +44 1202 420 710 fax-no: +44 1202 430 580 e-mail: email@example.com nic-hdl: PMK3-RIPE source: RIPE # Filtered % Information related to '188.8.131.52/24AS21396' route: 184.108.40.206/24 descr: ICB plc Anycast (via NetConnex AS21396) origin: AS21396 mnt-by: NETCONNEX-MNT source: RIPE # Filtered % Information related to '220.127.116.11/24AS42909' route: 18.104.22.168/24 descr: ICB plc Anycast (via Community DNS AS42909) origin: AS42909 mnt-by: NETCONNEX-MNT mnt-by: ICB-MNT source: RIPE # Filtered
You can see that the netblock 22.214.171.124/24 is referenced in two distinct AS (autonomous systems): AS21396 and AS42909! [Note: if you’re not familiar with those terms, read this introduction to BGP]. AS42909 belongs to Community DNS. This company operates a worldwide network of DNS servers using anycast.
If we look now at the BGP announces from two different locations (via public looking glasses), what can we see? First from Belgium:
BGP routing table entry for 126.96.36.199/24 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 188.8.131.52 GBXS-AS  NJIIX-AS-1  COMMUNITYDNS  184.108.40.206 from 220.127.116.11 (18.104.22.168) Origin IGP, localpref 100, valid, internal, best Community: 9009:4600 19318:999 Last update: Sat Dec 20 06:08:00 2008 GBXS-AS  NJIIX-AS-1  COMMUNITYDNS  22.214.171.124 from 126.96.36.199 (188.8.131.52) Origin IGP, localpref 100, valid, internal Community: 9009:4600 19318:999 Last update: Sat Dec 20 06:09:58 2008
Then from France:
BGP routing table entry for 184.108.40.206/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 174 39122 42909 220.127.116.11 from 18.104.22.168 (22.214.171.124) Origin IGP, metric 0, localpref 300, valid, internal Community: 12670:1001 Originator: 126.96.36.199, Cluster list: 0.0.0.100 0.0.0.255 Last update: Wed Nov 12 13:08:39 2008 174 39122 42909 188.8.131.52 from 184.108.40.206 (220.127.116.11) Origin IGP, metric 0, localpref 300, valid, internal, best Community: 12670:1001 Originator: 18.104.22.168, Cluster list: 0.0.0.100 0.0.0.255 Last update: Wed Nov 12 13:08:39 2008
Finally, from the United States:
BGP routing table entry for 22.214.171.124/24, version 696725982 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to peer-groups: RESOLVER 2516 17819 23352 42909 126.96.36.199 (metric 4403) from 188.8.131.52 (184.108.40.206) Origin IGP, metric 0, localpref 100, valid, internal, best Community: 209:209 209:887 209:11050 2516:2516 Originator: 220.127.116.11, Cluster list: 0.0.122.40, 18.104.22.168 2516 17819 23352 42909 22.214.171.124 (metric 4403) from 126.96.36.199 (188.8.131.52) Origin IGP, metric 0, localpref 100, valid, internal Community: 209:209 209:887 209:11050 2516:2516 Originator: 184.108.40.206, Cluster list: 0.0.122.40, 220.127.116.11
We clearly see that the packets sent to x.dns.be won’t take the same path. The Community DNS autonomous system is always reachable via a “short” AS path. Check out:
|Belgium:||GBXS-AS  -> NJIIX-AS-1  -> COMMUNITYDNS |
|France:||COGENT  -> BLACKNIGHT-AS  -> COMMUNITYDNS |
|USA:||JPNIC  -> EQUINIX  -> SERVERCENTRAL  -> COMMUNITYDNS |
Why does dns.be use anycast addressing? First, the DNS protocol is UDP based. It does not have to care of any session management like TCP requires. It’s a simple two-packets communication. If the chosen server suddenly dies, another one will be used. Second, UDP is a connection-less protocol, once the packet is sent, there is no more control. By using anycast,we can be sure to use the “nearest” server, so with the best network performances. Finally, it’s a good protection against DDoS, the attack will be distributed among the servers participating in the anycast mesh.
If you’re interested in anycast addressing, check out the following paper: Anycast Addressing on the Internet. There is also a RFC which covers this topic: Distributing Authoritative Name Servers via Shared Unicast Addresses RFC3258.
Finally, here is a video about DNS Anycast: