Technical requirements for hosting an I-root node

Distributed across the world, i.root-servers.net responds to several hundred million DNS queries a day. To further improve the robustness and availability of the I-root service, Netnod continuously expands the I-root anycast network.

If you are interested in hosting an I-root node, please read these requirements first. You can then contact us using the form here.

 

1. Physical Requirements

The server itself is a 19” rack mounted PC server, height 1 RU (rack units). It needs power (230/115 V, 50-60 Hz, max 500 W, with normal operations requiring less than 200 W), and reasonable cooling.

2. Networking Requirements

2.1 Physical Connections

The service needs three network connections: a peering connection, an admin connection, and a maintenance connection.

2.1.1 Peering connection

This is used for BGP peering with one or more parties. This is where the anycast prefixes are announced, and where the incoming DNS queries will arrive. The installation can be either a multilateral peering (e.g., for installation at an Internet Exchange Point), which is preferred, or a unilateral (point-to-point, P2P) peering (e.g., for installation inside an ISP).
 

  • Multilateral peering (preferred): The peering interface is connected to a switch (typically an Internet Exchange Point) over which multiple peering relationships with various parties can be established.
     
  • Unilateral peering: The peering interface is directly connected to a router at the hosting organisation. Peering is set up directly between the server and the hosting organisation’s router. The hosting organisation ensures further route propagation.

2.1.2 Admin connection

The cluster also needs a unicast connection for Netnod to reach the internal virtual machines individually in order to perform data transfer of DNS data and query statistics, software updates, etc. This link must be provided by the hosting organisation as a “normal customer connection” (minimum 30 Mbit/s, but preferably 1Gbit/s). This link may be combined with the maintenance link (see below) by connecting them both to a small LAN in a switch provided by the hosting organisation. Doing so may save router interface ports and possibly also addresses in the overall picture.

2.1.3 Maintenance connection

The server has a hardware maintenance connection to allow remote reset, power-on, power-off, system installation, etc. This is a similar connection as the admin connection with the same network requirements. It can be connected to the same LAN as the admin connection (see above).

 

2.2 Address Requirements

The three interfaces need addresses as do the virtual machines inside the box.

In all cases IPv4 addresses are mandatory. IPv6 addresses are warmly appreciated but not strictly necessary to make the site work.

The address needed for the the four network segments are:
 

  • Peering: one address on a p2p link for unilateral peering or one IPv4 address on the peering (IX) LAN for multilateral peering. Similar for IPv6.
     
  • Admin: One IPv4 address and one IPv6 on a LAN or P2P segment with Internet connectivity to Netnod in Stockholm. The internal IPv4 and IPv6 prefixes (see below) must be routed to the admin address across this network segment by the hosting organisation. The server is able to use a /31 IPv4 prefix for this link.
     
  • Maintenance: One IPv4 address and one IPv6 on a LAN or P2P segment with Internet connectivity to Netnod in Stockholm. The server is able to use a /31 IPv4 prefix for this link

These addresses must be reachable over the public internet from Netnod in Stockholm, and these prefixes must be routed by the hosting organisation to the admin addresses (IPv4 and IPv6 respectively) as mentioned above.

IPv6 is highly desired for all connections, but is optional in case it's not available.

 

2.3 Routing Requirements

  • Peering: No static routing is needed, regardless of unilateral or multilateral peering. Netnod expects to do BGP peering over this link, announcing the anycast prefixes used to attract traffic to the DNS service provided with several other peers (in the multilateral case), or with the hosting organisation (in the unilateral case). Netnod is happy to make use of route servers, if available.
     
  • Admin: The prefix must be reachable from Netnod in Stockholm. The internal prefixes (IPv4 and IPv6) must be forwarded to the admin addresses (typically by the hosting organisation adding a static route in the upstream router).
     
  • Maintenance: The prefix must be reachable from Netnod in Stockholm.