From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 13:41:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8E7216A4B3 for ; Tue, 16 Sep 2003 13:41:54 -0700 (PDT) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 025D443FA3 for ; Tue, 16 Sep 2003 13:41:54 -0700 (PDT) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id 115FC153CCB; Tue, 16 Sep 2003 10:41:23 -1000 (HST) Date: Tue, 16 Sep 2003 10:23:56 -1000 From: Clifton Royston To: freebsd-hackers@freebsd.org Message-ID: <20030916102356.A11571@lava.net> Mail-Followup-To: freebsd-hackers@lava.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Resent-From: cliftonr@lava.net Resent-Date: Tue, 16 Sep 2003 10:41:22 -1000 Resent-To: freebsd-hackers@freebsd.org Resent-Message-Id: <20030916204123.115FC153CCB@malasada.lava.net> Subject: Any workarounds for Verisign .com/.net highjacking? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2003 20:41:54 -0000 For those who don't know what I'm talking about, try executing "host thisdomainhasneverexistedandneverwill.com", or any other domain you'd care to make up in .com or .net. Verisign has abused the trust placed in them to operate a root name server, by creating wildcard A records directly under .com and .net, which point to Verisign's "search" website. This kind of abuse, which I don't think was ever anticipated as coming from an authorized root name server, is busting all manner of things in DNS. To name just a couple at this site, it's a bonanza to spammers because it breaks all the antispam measures which depend on validating the sender or hello domain, and it's screwing up the proxy-autoconfigure script for our webcache (which uses Javascript to check if a domain exists so that the user can get an in-browser error rather than a web-cache error page on typos) I'm sure there are other little things that it will break to have every possible .com or .net domain resolve. To add insult to injury, the site is slow as molasses to come up, taking literally minutes to finally appear in a browser. I filed a personal complaint to ICANN asking that they revoke Verisign's right to operate a root name server and to be a registrar for .com and .net. (If you think this is overly harsh, check the requirements for TLD managers given in RFC 1591 and for root name server operators in RFC 2870.) Given the rate at which ICANN moves, maybe I'll get an initial response that they've read my message in the next 2 years. In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? -- Clifton -- Clifton Royston -- cliftonr@tikitechnologies.com Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss