dns.be is responsible of the .be (Belgium) TLD.
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 194.0.1.10 # whois -h whois.ripe.net 194.0.1.10 % 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 '194.0.1.0 - 194.0.1.255' inetnum: 194.0.1.0 - 194.0.1.255 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: admin@icb.co.uk 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: paul.kane@icb.co.uk nic-hdl: PMK3-RIPE source: RIPE # Filtered % Information related to '194.0.1.0/24AS21396' route: 194.0.1.0/24 descr: ICB plc Anycast (via NetConnex AS21396) origin: AS21396 mnt-by: NETCONNEX-MNT source: RIPE # Filtered % Information related to '194.0.1.0/24AS42909' route: 194.0.1.0/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 194.0.1.0/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 194.0.1.0/24
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
89.106.240.70
GBXS-AS [9009] NJIIX-AS-1 [19318] COMMUNITYDNS [42909]
83.143.241.73 from 89.106.240.105 (89.106.240.100)
Origin IGP, localpref 100, valid, internal, best
Community: 9009:4600 19318:999
Last update: Sat Dec 20 06:08:00 2008
GBXS-AS [9009] NJIIX-AS-1 [19318] COMMUNITYDNS [42909]
83.143.241.69 from 89.106.240.106 (89.106.240.101)
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 194.0.1.0/24
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
174 39122 42909
213.30.128.117 from 213.30.129.97 (213.30.128.117)
Origin IGP, metric 0, localpref 300, valid, internal
Community: 12670:1001
Originator: 213.30.128.117, Cluster list: 0.0.0.100 0.0.0.255
Last update: Wed Nov 12 13:08:39 2008
174 39122 42909
213.30.128.117 from 213.30.129.96 (213.30.128.117)
Origin IGP, metric 0, localpref 300, valid, internal, best
Community: 12670:1001
Originator: 213.30.128.117, 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 194.0.1.0/24, version 696725982
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to peer-groups:
RESOLVER
2516 17819 23352 42909
205.171.0.81 (metric 4403) from 205.171.0.144 (205.171.0.144)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 209:209 209:887 209:11050 2516:2516
Originator: 205.171.0.81, Cluster list: 0.0.122.40, 205.171.0.129
2516 17819 23352 42909
205.171.0.81 (metric 4403) from 205.171.0.145 (205.171.0.145)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 209:209 209:887 209:11050 2516:2516
Originator: 205.171.0.81, Cluster list: 0.0.122.40, 205.171.0.129
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 [9009] -> NJIIX-AS-1 [19318] -> COMMUNITYDNS [42909] |
| France: | COGENT [174] -> BLACKNIGHT-AS [39122] -> COMMUNITYDNS [42909] |
| USA: | JPNIC [2516] -> EQUINIX [17819] -> SERVERCENTRAL [23352] -> COMMUNITYDNS [42909] |
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: