Sign In/My Account | View Cart  

advertisement

AddThis Social Bookmark Button

Paul Vixie on VeriSign

by chromatic
09/23/2003

Paul Vixie has spent more than two decades contributing to the protocols and software that run the Internet. He founded the Internet Software Consortium and chairs its board of directors. Paul may be best known as the primary author of BIND v8, an older reference implementation of DNS.

Paul recently agreed to a brief phone interview with the O'Reilly Network to discuss VeriSign's recent redirection of nonexistent URLs to an advertising page.

O'Reilly Network: Can you give our readers a summary of the current controversy? What did VeriSign do that has people up in arms? How are you involved?

Paul Vixie: VeriSign put a wildcard name in the root of COM and NET top-level domains. This functions as a default; there's now no such thing as a nonexistent domain name. Your typographical error has just been monetized. Now VeriSign is making a lot of money by selling advertising, thereby bypassing the ordinary sharing with the other registrars.

I'm not a registrar, so the loss of income doesn't affect me. But I've been contacted by many BIND users. Soon after VeriSign's move, my phone started ringing at home with users demanding that we work around this in BIND.

ORN: I see that ISC has just put out a patch.

PV: Yes. In fact we've put out several patches, for different releases of BIND, and then updated those patches slightly in order to deal with minor diagnostic and tuning issues.

ORN: How does the patch work? Does it disable wildcards in general or just for .com or .net?

PV: VeriSign's servers don't actually emit the wildcard data onto the wire; the DNS protocol allows for "synthesis" if there is no match in the zone but there is a wildcard in the zone. So what we see from outside VeriSign is their synthesized answers, not the wildcard itself.

Synthesized answers look slightly different from normal answers. A TLD server like VeriSign's normally sends either referrals toward other nameservers ("you're digging in the wrong place") or negative answers (signals of domain name nonexistence.)

For example, if you go to www.ora.com, your nameserver will ask another nameserver about it. If that nameserver doesn't have any information, it'll have to ask the root nameservers. They don't know anything about your machine named www.ora.com, but they do know who runs .com. Your nameserver knows it's received a delegation response, so it'll go ask the servers for .com. They also don't know anything about the O'Reilly web server, but they do know who the nameserver is for ora.com. They send back a delegation response, in effect telling you to go ask the ora.com nameserver. That's the way things work when the domain exists.

O'Reilly Emerging Technology Conference.

Delegation looks different on the wire from a synthesized wildcard response. Our patch allows nameserver operators to edit their configuration file. They can allow "delegation only" responses for .com and .net. If you receive something else, just pretend it doesn't exist.

ORN: It's optional if people want to disable synthetic responses?

PV: We'll never enable this by default. Any system administrator who wants it will have to enable it, based on local policy only. We just provide the tools.

ORN: How does this work with caching nameservers?

PV: You mean a forwarding name server where there are multiple caches? Your caching nameserver should perform all the operations I just described. A multi-level or forwarding nameserver could make this trickier, but that's pretty rare. Your forwarding nameserver would have to incorporate the logic in this patch. The average nameserver somewhere won't forward its queries.

ORN: This change in policy by VeriSign seems to make antispam activists angry.

PV: A lot more spam is getting through my outer defenses than used to. But that's not the only concern: the other registrars are concerned about monetization; ICANN is concerned about a big change in behavior for users; and standards zealots are just annoyed.

Actually ICANN was consulted about a similar issue, that is, to limit this behavior to just internationalized domain names. ICANN advised against doing that, as did the IETF and the IAB. The ICANN and IAB advice about internationalized domain names would apply even more strongly to the use of wildcards.

As for the standards zealots, the IANA has reserved a.com, b.com, and so on. They're not supposed to exist, but they now appear to exist. It's a small point of theory, but it angers some people.

There are also privacy concerns. Think of other information carried in URLs with query strings, all of which ends up, if URLs are malformed, in VeriSign logs now. Such information may include passwords, logins, and other sensitive information. It wouldn't be sent anywhere if the domain name lookups would fail. You also have other branding concerns. If someone guessed at your domain name it would previously have just failed.

ORN: Unless a typosquatter had it.

PV: So now your brand becomes a typomagnet so that anyone who guesses your name and guesses wrong will end up at a VeriSign adserver. This produces the exact opposite result that most registrants want, which is to protect their brand. Furthermore, in an e-mail context, many errors that used to be benign are now fatal, like MX chain problems.

ORN: Now you wouldn't go on down the chain of secondary and tertiary records.

PV: Right. You'd send to the first one, the misconfigured one, because it wouldn't fail. VeriSign's running a mail server that bounces everything now.

ORN: As far as we know, they're bouncing it. They could be keeping it.

PV: That's another concern that's been expressed. They could be keeping a list of addresses. They could send out marketing messages, something like "You looked for this domain. It doesn't exist. Want to buy it?"

ORN: Are there any penalties that could be levied against VeriSign? Could ICANN take away their right to run the root nameservers?

PV: That's tricky. VeriSign has been doing this since before ICANN existed. There's a contract in place, but it's hard to know whether that contract is enforceable.

Some people suggest that administration of the DNS is a public trust, and that VeriSign is merely the caretaker of this system, not its owner. And now VeriSign has abused that trust. That may be true. Before a few days ago it didn't matter whether VeriSign was the owner or a caretaker. Now it matters a lot. VeriSign kicked a sleeping dog. It's a bizarre thing to do. Was it really VeriSign's decision to make, unilaterally? Did it need permission to make this decision? If so, what entity has the authority to grant such permission?

As a result there will be a big policy debate now. Someone will decide if permission needed to be had. Someone will decide if it should be delegated to someone else.

ORN: Will this tempest be over if people apply the appropriate patches to their DNS servers?

PV: I hope but I don't think so. I've heard that the patch works well, but VeriSign could bypass the patch. It could make synthesized responses look more like delegations. I don't think it will do that. VeriSign's spokesperson, Brian O'Shaughnessy, suggested that if people don't want this, they're free to block it. It's really meant to be a service for the supposedly inconvenienced web surfers. VeriSign maintains that its search page is more useful than 404 error messages. If VeriSign bypassed the patch, it would have to escalate things and retract these statements about how folks were free to block the wildcard.

ORN: What do you think is the motivation behind this change?

PV: Microsoft, AOL, and others make a lot of eyeball revenue from similar features, so we're all assuming that VeriSign wanted a share.

ORN: Maybe that question should have been addressed a while ago.

PV: I dislike sleeping dogs of this kind. I'd have liked to deal with it separately in cooler times. It would have been better to deal with it long ago. Either VeriSign has the right to do this, so you just deal with it, or it doesn't have the right. In which case ICANN should do something about it.

ORN: Is there anything else you want to get across to our audience?

PV: Just that the ISC has no horse in this race. As for how these policy and governance questions are answered, ISC has no preference, as long as everyone knows what the answer is. We put the patch out because people asked for it. I saw several bootleg patches that looked pretty low-quality, and we wanted to create a single, unified way of handling the problem. We have no stake in the outcome. We just want to make sure that it's done as responsibly as possible.

VeriSign is a past member of the BIND forum and a root nameserver provider. Many smart and friendly people work for VeriSign. I wish them no ill will, but I also wish this had been handled better.

chromatic promotes free and open source software for O'Reilly's Open Technology Exchange.

Return to ONLamp.com.




-->