ISC Blogs

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.

Taking Back the DNS

Most new domain names are malicious.

I am stunned by the simplicity and truth of that observation. Every day lots of new names are added to the global DNS, and most of them belong to scammers, spammers, e-criminals, and speculators. The DNS industry has a lot of highly capable and competitive registrars and registries who have made it possible to reserve or create a new name in just seconds, and to create millions of them per day. Domains are cheap, domains are plentiful, and as a result most of them are dreck or worse.

Using the root DNSSEC key in BIND 9 resolvers

To use the signed root zone in DNSSEC validation in your BIND 9 resolvers, you must be running BIND 9.6.2 or higher. Earlier versions do not support the required algorithms to enable validation using the root zone's key. It is strongly recommended you run BIND 9.7 to use the automatic key updating functionality.

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.

Backwards compatibility issues in BIND 9.7.0 and 9.7.1

ISC has announced that there were some backwards compatibility problems in the 9.7.1 release. Here is a bit more information on the topic. These problems were also in 9.7.0.

The first issue was a problem in how those versions of BIND 9 processed certain formats of negative responses. In particular, BIND 9's internal logic expected certain records to be present because that is what BIND 9 generated. Some other types of servers (many were custom-created it appears) did not include everything we expected to find, and sometimes those had to be queried for.

Towards a DNSCERT Definition

To mix metaphors, my e-mail has been ringing off the hook after my previous article ("Perspectives on a DNS-CERT") and I've had to think deep and difficult thoughts about what we really mean by DNSCERT, and whether DNS-OARC really has the capability or really can grow the capability to operate such a thing. I've had some discussions with ICANN and with members of the DNS-OARC board and staff, and it's time I checkpointed the current state of my thinking about all this.

BIND 9.7.2 and automatic DNSSEC signing

BIND 9.7.0 and 9.7.1

BIND 9.7.0 introduced automatic in-server signature re-freshing and automatic key rollover.  This allows BIND 9.7, if provided with the DNSSEC private key files, to sign records as they are added to the zone, or as the signatures need to be refreshed.  This refresh happens periodically to spread out the load on the server and to even out zone transfer load.

Open source *more* secure?

I seem to read all the time that open source projects must be less secure, since the bad guys can look through the source code to find vulnerabilities. I was pleased to see an article today that takes the point of view that security through obscurity is not the right direction and that open source projects can be more secure than competing proprietary software.

Imminent Death of Internet Predicted. Film at 11.

The press seems to love stories of doom and gloom. And for almost as long as the Internet has been around, there have been dire predictions of some resource exhaustion, success disaster or security flaw that will destroy the internet. And who is the villain in this week's piece? DNSSEC and the signing of all the root servers.

While I love a good story as much as the next person, it seems time to actually throw a few facts on the fire.

DNSSEC Readiness

DNSSEC is coming. Is your organization ready?

The DNS community is buzzing with activity around the implementation of the DNS Security Extension, DNSSEC. In simple terms, DNSSEC provides a "chain of trust" within the DNS hierarchy and the authentication of DNS responses. Once deployed across the DNS, DNSSEC will render the infamous man-in-the-middle attack a thing of the past.

blog topics