Blog entries for "F-root"

ISC in Africa

ISC has always been supportive of Internet infrastructure development in Africa. In addition to being the first root-server operator to offer anycast instances in Africa, we have long provided Secondary Name Services (SNS) to a number of African ccTLDs as part of our public benefit mission. We have also sent our staff to AfNOG meetings to help in training on our FOSS (BIND and DHCP).

Origin ASN for Anycasted Services

 There is a new draft from the IETF GROW working group that attempts to standardize how Anycasted services manage their routing announcements.  The draft can be found at:

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-grow-unique-origin-as-01.txt

Before commenting directly on the draft a review of how ISC operates the F-Root Anycast network is in order.

Evolution of Internet Exchanges

Something we're fortunate to have at ISC is the founders of some of the most influential Internet Exchanges (IXPs) amongst our senior staff. I haven't been personally involved in the IXP business for around 7 years now, so it was a pleasure to be invited as guest speaker to the AGM of the TorIX, Canada's biggest IXP, in Toronto.

Preparing for a world consisting of larger DNS responses.

While many of you know ISC as the maintainer of the BIND DNS server software, we have always had our hand in the DNS operations field, including operating one of the 13 DNS root servers (F.ROOT-SERVERS.NET), as well as secondaring many ccTLD and non-commercial zones for over a decade. ISC has also been at the forefront of designing and implementing DNS Security Extensions (DNSSEC) which is a mechanism to cryptographically verify that the response given to a DNS request is correct.

Implementing IPv6 is no longer optional

The exhaustion of IPv4 space from IANA is coming as soon as February (yes, next month!) and the reserve held by the RIRs will be running dry shortly thereafter. The ability to provide (and use) IPv6 infrastructure is no longer optional; it is a requirement.

F-Root Routing: How does it work?

ISC uses an unusual routing configuration for the F-Root name server. While the configuration is relatively easy to understand, it's hard to deduce by looking at the routing tables. We'll explain it here!

The network 192.5.4.0/23 is used for F-Root. The reasons for using this block are historical and unimportant, but the fact that it is a /23 is very important. Looking in the global routing table, you'll find 192.5.4.0/23 routed worldwide; ISC has obtained multiple transit providers for this network to provide excellent access to F-Root.

What's happening with DLV?

Now that the root zone has been officially signed, what happens with ISC's DNSSEC Look-aside Validation Registry? The short answer is, it gets smaller, but does not go away, at least not today.

While having the root signed is a critically important step in the DNSSEC deployment effort, it is not the final step. It's the one that enables a lot of other zones such as Top Level Domains (TLDs) to be signed usefully. It removes the need for many stop-gap measures like certain TARs, and the need for TLD entries in ISC's DLV system.

The Signed Root Is Coming! (And what this means for you)

In the Fall of 2009, the organizations responsible for generating the root zone, ICANN, Verisign, and the US Department of Commerce, announced that they had come to a agreement on how to sign the root zone with DNSSEC (DNS Security Extensions) A website has been created by ICANN and Verisign to provide information about the change and a rollout timeline.

ASN Collisions and Human Error

There is nothing more sensational than the unexpected, and when the NANOG (North American Network Operators Group) community was recently informed that an ASN collision had occurred it caused a lot of people to sit up and take notice. This event was also very interesting in that researching takes us back to a time before ARIN and RIPE existed, creating an interesting historical twist.