The oral arguments in the challenge to the FCC’s 2015 Open Internet regulations illustrated the difference between the way engineers and users see the Internet and the way that lawyers and judges see it (the recorded audio is here, keep your volume control handy.)

• The lawyers use a number of terms such as “routing” and “network management” that have clear and well-defined meanings to engineers to mean something completely different.
• The lawyers argue that certain practices are reasonable and others not on the basis of home-spun analogies to screws and national capitols.
• Much of the legal reasoning is circular; in particular presuming the conclusion (that used to be called “begging the question”) doesn’t appear to be much of a problem.
• If a question can be decided on the basis of an answer that has a substantial factual record, the lawyers will, on occasion, prefer to decide it on the basis of assertions that can’t be supported by facts.

Please allow me to explain the first point in this post and others in subsequent posts.

FCC chief counsel Jon Sallet asserted that the DNS is the Internet’s routing function at least twice in his oral argument, doubling down on the claim in the FCC’s reply brief to the challengers’ petition to vacate the regulations. He offered no evidence in the arguments, just as the reply brief simply asserts this proposition without evidence. The judges didn’t challenge this claim, and in fact promptly moved the discussion along to more legally interesting questions.

So let’s see what the Internet’s own factual record has to say about the role of DNS with respect to routing. There are about 250 RFCs that deal with DNS, starting with RFC 799 in September 1981 and going up to RFC 7673 in October 2015.

I haven’t reviewed every one of them, but there’s a clear pattern in the formative RFCs from the late 1980s, beginning with RFC 1034 by Paul Mockapetris, the principal designer of DNS: the DNS design documents only use the term “routing” when discussing email. DNS is a database system that responds to particular questions with answers (known as “resource records”) or error codes. So the purpose of DNS is to answer questions about how resources are used by domains. Domains are simply administrative elements within the overall Internet operation space.

So an application program can ask DNS for the IPv4 address attached to a domain like “catvideos.com” by asking for the domain’s “address resource record” (its “A record”); it can ask for the IPv6 address by seeking its “AAAA record.” The RFCs don’t use the term “routing” for these queries because they are simply questions and answers.

The foundation DNS RFCs only use “routing” in one special circumstance: there is a Mail Exchanger (MX) record for routing email from a sender in the source domain to a recipient in the destination domain. Now the thing about this “DNS routing” is that it has nothing to do with IP addresses. When RFC 1034 describes the MX transaction, it shows a query for the MX of the domain that returns a sub-domain:

ISI.EDU.        MX      10 VENERA.ISI.EDU.

This means there’s a computer named “venera” in the isi.edu domain that handles mail for everyone and its priority is 10. Hence the originating mail server is advised to lookup the A record for venera.isi.edu and send all email to that address unless there’s a failure, in which case there are some lower priority MXs that can be used.

So the Internet has a very different concept of routing and DNS than the FCC does. The FCC asserts that the purpose of DNS is network management, making ISP networks operate more efficiently than they would without DNS.

This is only true to the extent that email is an essential part of the service ISPs offer to the public, a claim that the FCC actually denies. In the FCC’s own words, email is simply an add-on the ISPs’ real service, access to web sites.

So the factual record exposes a contradiction in the FCC’s arguments about DNS: In reality, DNS is only a routing function in connection with an unimportant add-on, email. It comes as no surprise then that third party email services such as Google Mail are bundled with Google DNS.

In the general sense, DNS is a valuable part of the real ISP service, “access to web sites”, because it frees the user from the burden of remembering IP addresses on the one hand and also because it allows the owners of web sites to communicate the best IP addresses for each user to employ when accessing these web sites on the other.

The primary motivation for devising a DNS in the first place was to allow users to get quick updates to resource records direct from domain owners. Before there was a DNS, network administrators used FTP to download text files of the RR’s associated with domains once a week or so, so there were frequent consistency problems when RR’s changed mid-week. But in a general way, the Internet worked pretty well without a DNS.

You can’t really call this “network management” because the purpose of this exercise has more to do with end-to-end relationships between ISP customer systems and remote domains than with any operational details of the ISP’s own network.

There is a very intriguing RFC about the use of DNS to actually do routing, RFC 1383, “An Experiment in DNS Based IP Routing” by Christian Huitema. This is an “Experimental RFC” that never graduated to Internet Standard status. Huitema is attempting to address the problem of the exploding number of routes in BGP, the Internet’s routing information protocol (BGP doesn’t route packets, but it creates maps in routers that allow them to figure out how to route packets.)

The experimental approach sought to add routing information to DNS:

The “MX records” are currently used by the mail routing application to introduce a level of decoupling between the “domain names” used for user registration and the mailbox addresses. They are particularly useful for sending mail to “non connected” domains: in that case, the MX record points to one or several Internet hosts that accept to relay mail towards the target domain. We propose to generalize this scheme for packet routing.

The RFC explains why additional work will be required to enable DNS to perform and/or aid routers in doing their job:

A standard Internet router Ix cannot in principle send a packet to the address Dx: it does not have any corresponding routing information. However, if the said Internet router has been modified to exploit our scheme, it will query the DNS with the name build up from “Dx” in the “in-addr.arpa” domain, obtain the RX records, and forward the packet towards I1 (or I2), using some form of “source routing”. The gateway I1 (or I2) will receive the packet; its routing tables contain information on the domain D and it can relay the packet to the host Dx.

This simply means that routers need information about where to route packets, and that it may be more efficient to have them get this information by asking DNS for it than to have them rely on BGP announcing routing information every so often. The information transmitted would be the same, but a question-and-answer system such as DNS would cause less information to transit the network than the announcement system [still] used by the Internet’s real routing system.

The downside of the DNS for routing system was the extra time and complexity it would have added to Internet routing.

So not only does DNS not do routing for anything but email, its use to do general routing was tried and rejected.

But that doesn’t prevent the FCC from standing up before the DC Circuit court and claiming “DNS is a routing function that enables the efficient operation of ISP networks.”

The FCC’s claim only makes sense if we presuppose that the Internet is essentially a telephone network whose special features are all more or less the same as telephone network features. This reasoning considers DNS the same as “call forwarding,” the telephone feature that forwards calls to your office number to your cell, home, or somewhere else.

But that doesn’t work either, because call forwarding is the sort of thing the Internet calls “mobility.” Mobility support in the Internet is the job of Mobile IP, an enhanced version of the Internet’s actual routing protocol, IP itself. Mobile IP allows a device to roam without loss of connectivity, and DNS does not.

So the FCC’s reasoning is circular at best, but uninformed in any case.

Engineers and regulatory lawyers inhabit different Internets.