Re: Stupid DNS tricks

2003-09-16 Thread Masataka Ohta
Adam Roach;

 Because this is probably a community of interest for the
 topic of DNS, I thought it would be worthwhile mentioning
 that Verisign has apparently unilaterally put in place
 wildcard DNS records for *.com and *.net. All unregistered
 domains in .com and .net now resolve to 64.94.110.11, which
 runs a Verisign-operated web search engine on port 80.

A very interesting stupidity.

However, as I checked whois database of verisign for *.com and
*.net, the answers are negative

No match for *.COM.

No match for *.NET.

that, according to verysign, they are not registered domain names.

So, I tried to get the names by myself, for obvious reasons :-),
through www.verisign.com. :-) But, my request was denied as

Please use only letters, numbers or dashes [-]. Do not
enter spaces, periods [.] or other punctuation.

that they are, according to verisign, not domain names open for
registration.

So, the remaining question is whether the stupidity is interesting
enough to make verisign not to be qualified to be a gtld registry
anymore or not.

Masataka Ohta



Re: Stupid DNS tricks

2003-09-16 Thread Florian Weimer
Adam Roach [EMAIL PROTECTED] writes:

 Because this is probably a community of interest for the
 topic of DNS, I thought it would be worthwhile mentioning
 that Verisign has apparently unilaterally put in place
 wildcard DNS records for *.com and *.net. All unregistered
 domains in .com and .net now resolve to 64.94.110.11, which
 runs a Verisign-operated web search engine on port 80.

And SMTP on 25/TCP.

The current setup breaks setups like

example.com 86400   IN  MX  10 mail1.xeample.com
example.com 86400   IN  MX  20 mail2.example.com

Previously, MTAs could not resolve xeample.com and would therefore use
the secondary.  Now, they can, and get a 550 error on RCPT TO:.

Granted, the setup has always been erroneous and risky, but breaking
this without proper notice is still extremely annoying.



Re: Stupid DNS tricks

2003-09-16 Thread Masataka Ohta
Any comment on the attached draft ID?

Abstract

   This memo describes actions against broken content of a primary
   server of a TLD.  Without waiting for an action of some, if any,
   central authority, distributed actions TLD server operators and ISPs
   can settle the issue, for a short term.

Masataka Ohta
---






INTERNET DRAFT   M. Ohta
draft-ohta-broken-tld--1.txt   Tokyo Institute of Technology
  September 2003

 Distributed Actions Against Broken TLD

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html The list of Internet-Draft
   Shadow Directories can be accessed at http://www.ietf.org/shadow.html

Abstract

   This memo describes actions against broken content of a primary
   server of a TLD.  Without waiting for an action of some, if any,
   central authority, distributed actions TLD server operators and ISPs
   can settle the issue, for a short term.

1. Introduction

   DNS is a fully distributed database of domain names and their
   associated values with loose integrity.

   However, the primary server of a zone is a single point of failure of
   the zone to hold the current most copy of the zone and such a failure
   at TLD can cause a lot of damage to the Internet.

   As it may take time for a central authority, if any, take care of the
   problem, this memo describes distriburted actions as a short term
   solution to protect the Internet against broken TLD zone content.

   The long term solution is to let the primary server operator fix the
   content or to change the primary server operator, which may involve a
   central authority.



M. OhtaExpires on March 17, 2004[Page 1]

INTERNET DRAFT Broken TLD  June 2003


   Similar technique is applicable to root servers with broken contents.

2. Actions of TLD Server Operators

   A TLD server operator who have found that TLD zone content is broken
   should disable zone transfer and use a copy of old zone content known
   not to be broken.

   Or, if the fix for the zone content is obvious and easy, the operator
   may manually or automatically edit the content of the current most
   one without updating SOA serial number. In this case, zone transfer
   may not be disabled, though actions of ISPs described in section 3
   may make the transfer from servers of broken content impossible.

3. Actions of ISPs

   ISPs should disable routes to TLD servers with broken content and/or
   filter packets to/from the TLD servers.

   ISPs should periodically check the servers, whether they still
   contain broken content or not.

4. Security Considerations

   As for security, TLD servers should never have broken content.

5. Author's Address

   Masataka Ohta
   Graduate School of Information Science and Engineering
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3299
   EMail: [EMAIL PROTECTED]















M. OhtaExpires on March 17, 2004[Page 2]




Stupid DNS tricks

2003-09-15 Thread Adam Roach
Because this is probably a community of interest for the
topic of DNS, I thought it would be worthwhile mentioning
that Verisign has apparently unilaterally put in place
wildcard DNS records for *.com and *.net. All unregistered
domains in .com and .net now resolve to 64.94.110.11, which
runs a Verisign-operated web search engine on port 80.

In other words, it is effectively impossible to provoke
an NXDOMAIN response for any host in either of these TLDs.
 
$ dig sdlfkjglei.com

;  DiG 9.2.1  sdlfkjglei.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 35289
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;sdlfkjglei.com.IN  A

;; ANSWER SECTION:
sdlfkjglei.com. 900 IN  A   64.94.110.11

;; AUTHORITY SECTION:
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.

;; Query time: 48 msec
;; SERVER: xx.xx.xx.xx
;; WHEN: Mon Sep 15 23:12:05 2003
;; MSG SIZE  rcvd: 272

/a