Re: [sitefinder-tech-discuss] Pseudo code please

[Mo McKinlay <mo.mckinlay@cirrus-multimedia.ltd.uk>]

On Thu, Oct 23, 2003 at 06:40:16PM -0400, Andrew Newton wrote:

> >The real issue and reason that .com and .net are different from .museum
> >is that .museum is a "sponsored" domain with a clear owner and a clear
> >constituency that agreed that wildcards were an acceptable and good idea
> >for that TLD.  It serves a very different purpose than .com and .net.
> >I suspect that if you were to approach the community about wildcarding
> >.org or .edu, you'd get similar responses.  Frankly, the only reason I
> >can think of that noone has objected to this in .us is that we just
> >didn't notice the change because not very many people actually use
> >the .us domain in URLs that they type.
> 
> I believe this to be a political opinion.  Unless your network cannot 
> receive mail from machines with these TLD's and unless your machines are 
> incapable of making HTTP requests to domains in the these TLD's, their 
> wildcards have the same effects as the one in com/net.  The DNS protocol 
> doesn't behave differently for "sponsored" domains.

Yes and no.

It's not political opinion, it's the principle of least suprise. A TLD which
is created and /from the start/ uses wildcards isn't going to cause anybody
any headaches.

Similarly, a TLD which has [relatively] few users and later starts to use
wildcards; very few people will care.

When the largest domains in the world suddenly contain wildcard A records,
people notice. The point is that there isn't something fundamentally
different between .com and .museum on a technical level, but that the use of
a wildcard doesn't scale well.

For starters, consider spam:

- How much spam originates from nonexistant .museum domains? As a percentage?

From my logs of the past 12 months, I can tell you: precisely 0%.

From .com/.net combined, you're looking at a huge figure. Suddenly the most
basic initial check which causes mail from nonexistant domains to get
dropped on the floor before it has a chance to be accepted for delivery
stops working. You violate the principle of least suprise.

On another note, how many customers regularly hit .museum domains, again, as 
a percentage?

[I'm sure someone on NANOG would happily grep their Squid logs for us, were
someone to ask]

How many customers are USED to their browser plugin working and providing
search results? How many of them have Internet Explorer configured to hit
the search engine of /their choice/ when it recieves an NXDOMAIN? How many
of them ring support lines because the browser is ignoring the search engine
they chose from the drop-down box?

Are you seriously telling me that the functionality (which obviously
inspired SiteFinder) is badly designed because it relies on NXDOMAIN to work?

No, of course it isn't.

There needs to be some clarification of what wildcards are for, I think.

Put simply, a wildcard is used when you _always_ want it to appear to
clients that a given RR is present. If you provide a wildcard A record, you
are requesting that your DNS server inform clients that ALL HOSTS EXIST.
You're synthesising a positive response, and you do this when you want ALL
applications to believe that the host they are resolving really does exist
when it's really a figment of their imagination.

Much of the traffic on this list seems to consist of:

Q: My application no longer works because it can't tell whether a host
exists or not, because the .COM servers say all hosts exist.

A: Your application is dumb. You can use these work-arounds, though, but
they need twice as many queries to be made.

Q: But surely, if the .COM servers say a host exists, then it must exist?

A: It depends how you define 'exists'

Q: Okay, you're telling me that I should ignore the definition traditionally
used by applications developers, and instead modify (at cost to me) all the
software that I have to use DNS in a manner not mandated by any Internet
standards (or even drafts) in order to get a response that used to be
returned as a result of the original query (in accordance with Internet
standards and drafts)?

At the end of the day, DNS is the wrong place for this, and .COM and .NET
are definitely far too large-scale domains to be experimenting with these
sorts of ideas without even a second thought as to what the impact might be.

Scott, Andrew, I appreciate the fact that you guys are in a difficult
position. But I'm not sure anybody can take you overly seriously when the
only solution you can offer is for people to spend time and money kludging
something that isn't broken, telling us you're listening to the technical
community, while at the *same time* press releases from Verisign say that
the SF service will be resumed in the very near future.

If you guys have a solution to re-enabling SF without screwing half of the
Internet, then it should be discussed with the technical community. If you
don't, I don't want to hear from your press office about how it's going to
get turned back on RSN - not least because I have a sneaking suspicion that
the guys in the press office are far closer to the people making decisions
than the technical staff who have to implement these "services".

"Voted with their mouses" indeed.

Mo.

-- 
E: mo.mckinlay@cmlx.co.uk
T: +44 (0) 709 200 3083
W: http://cmlx.co.uk/

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.elistx.com/unsubscribe>