dns.be: More Anycasting

Anycasting

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:

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.