[Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]

[Yakov Shafranovich]

I am forwarding this message from the ASRG list. If you haven't heard it
yet, Verisign has activated their "typos" DNS service for .COM and .NET.

-------- Original Message --------
Subject: [Asrg] Verisign: All Your Misspelling Are Belong To Us
Date: Tue, 16 Sep 2003 03:10:52 +0200
From: Brad Knowles <***@skynet.be>
To: IRTF ASRG <***@ietf.org>

Folks,

This was just posted to the NANOG mailing list. There are
already people who are working on hacking BIND to return NXDOMAIN for
wildcard records in TLD zones, or perhaps for any reference to the
specific IP address(es) they are using (so far, we only know about
64.94.110.11). Meanwhile, many are already null-routing this IP
address.

This affects us, because now anyone can send spam with an address
like "***@spam.from.verisign.becausethisdomaindoesntreallyexist.net",
and yet still have that pass standard anti-spam checks like "Does
this domain really exist in the DNS"?


Another one for the service provider BCP, I think.

Date: Mon, 15 Sep 2003 19:24:29 -0400
Subject: Change to .com/.net behavior
Today VeriSign is adding a wildcard A record to the .com and .net
zones. The wildcard record in the .net zone was activated from
10:45AM EDT to 13:30PM EDT. The wildcard record in the .com zone is
being added now. We have prepared a white paper describing VeriSign's
http://www.verisign.com/resources/gd/sitefinder/implementation.pdf
By way of background, over the course of last year, VeriSign has been
engaged in various aspects of web navigation work and study. These
activities were prompted by analysis of the IAB's recommendations
regarding IDN navigation and discussions within the Council of
European National Top-Level Domain Registries (CENTR) prompted by DNS
wildcard testing in the .biz and .us top-level domains. Understanding
that some registries have already implemented wildcards and that
others may in the future, we believe that it would be helpful to have
a set of guidelines for registries and would like to make them
publicly available for that purpose. Accordingly, we drafted a white
paper describing guidelines for the use of DNS wildcards in top-level
domain zones. This document, which may be of interest to the NANOG
http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf
Matt
--
VeriSign Naming and Directory Services

[Neal McBurnett]

This is outrageous, both in breaking DNS, and in abusing monopoly
power.

Other references:

http://gnso.icann.org/mailing-lists/archives/ga/msg00311.html
http://www.icann.org/correspondence/lynn-message-to-iab-06jan03.htm
http://www.merit.edu/mail.archives/nanog/2003-01/msg00050.html

What can be done besides complaining to ICANN?
***@icann.org

Neal McBurnett http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60

Post by Yakov Shafranovich
I am forwarding this message from the ASRG list. If you haven't heard it
yet, Verisign has activated their "typos" DNS service for .COM and .NET.
-------- Original Message --------
Subject: [Asrg] Verisign: All Your Misspelling Are Belong To Us
Date: Tue, 16 Sep 2003 03:10:52 +0200
Folks,
This was just posted to the NANOG mailing list. There are
already people who are working on hacking BIND to return NXDOMAIN for
wildcard records in TLD zones, or perhaps for any reference to the
specific IP address(es) they are using (so far, we only know about
64.94.110.11). Meanwhile, many are already null-routing this IP
address.
This affects us, because now anyone can send spam with an address
and yet still have that pass standard anti-spam checks like "Does
this domain really exist in the DNS"?
Another one for the service provider BCP, I think.

Date: Mon, 15 Sep 2003 19:24:29 -0400
Subject: Change to .com/.net behavior
Today VeriSign is adding a wildcard A record to the .com and .net
zones. The wildcard record in the .net zone was activated from
10:45AM EDT to 13:30PM EDT. The wildcard record in the .com zone is
being added now. We have prepared a white paper describing VeriSign's
http://www.verisign.com/resources/gd/sitefinder/implementation.pdf
By way of background, over the course of last year, VeriSign has been
engaged in various aspects of web navigation work and study. These
activities were prompted by analysis of the IAB's recommendations
regarding IDN navigation and discussions within the Council of
European National Top-Level Domain Registries (CENTR) prompted by DNS
wildcard testing in the .biz and .us top-level domains. Understanding
that some registries have already implemented wildcards and that
others may in the future, we believe that it would be helpful to have
a set of guidelines for registries and would like to make them
publicly available for that purpose. Accordingly, we drafted a white
paper describing guidelines for the use of DNS wildcards in top-level
domain zones. This document, which may be of interest to the NANOG
http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf
Matt
--
VeriSign Naming and Directory Services

[Keith Moore]

so now verisign is deliberately misrepresenting DNS results.

why are these people allowed to live?

[Tim Chown]

Because noone can stop them doing it, apparently...

Post by Keith Moore
so now verisign is deliberately misrepresenting DNS results.
why are these people allowed to live?

[Dean Anderson]

Is it any worse than IE taking you to msn search when a domain doesn't
resolve? Or worse than Mozilla taking you to Netscape, duplicating a
Google search, and opening a sidebar (and a netscape search) you didn't
want?

I think it isn't.

And people shouldn't be using Reverse DNS for spam checks, either. This
has been hashed out on both DNSOP and Namedroppers. People have known not
to do this for a long time, but some still insist on it. For that reason
alone, this is a good idea.

--Dean

Post by Keith Moore
so now verisign is deliberately misrepresenting DNS results.
why are these people allowed to live?

[Zefram]

Post by Dean Anderson
Is it any worse than IE taking you to msn search when a domain doesn't
resolve? Or worse than Mozilla taking you to Netscape, duplicating a
Google search, and opening a sidebar (and a netscape search) you didn't
want?

Yes, it is worse. Much worse. There is a fundamental difference between
this defaulting happening in the DNS and happening in a client program.
It is necessary that the wire protocols distinguish between existence and
non-existence of resources in a standard manner (NXDOMAIN in this case)
in order to give the client the choice of how to handle non-existence.
If IE wishes to default to doing a web search under those circumstances,
that is silly but harms no one else. What Verisign has done pre-empts
that choice for everyone.

-zefram

[Spencer Dawkins]

I agree with Zefram here, for at least a couple of reasons:

- there's a difference between doing this in infrastructure and
doing this in a client program

- there's a difference between doing this in a scenario where
there probably really IS a human in the loop (IE) and a
scenario where there's no reason to think that a human is
involved (trivially, an FTP running from cron on a Unix box)

- there's a difference between doing this in a component that
can be replaced (IE) and one that is very difficult to replace
in a meaningful way (DNS)

Not that I think IE's redirection is a GREAT example of the
Internet at its finest...

Spencer

----- Original Message -----
From: "Zefram" <***@fysh.org>
To: "Dean Anderson" <***@av8.com>
Cc: "Keith Moore" <***@cs.utk.edu>; "Yakov Shafranovich"
<***@solidmatrix.com>; <***@ietf.org>
Sent: Tuesday, September 16, 2003 8:18 AM
Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To
Us]

Post by Zefram

Post by Dean Anderson
Is it any worse than IE taking you to msn search when a domain doesn't
resolve? Or worse than Mozilla taking you to Netscape, duplicating a
Google search, and opening a sidebar (and a netscape search) you didn't
want?

Yes, it is worse. Much worse. There is a fundamental difference between
this defaulting happening in the DNS and happening in a client

program.

Post by Zefram
It is necessary that the wire protocols distinguish between

existence and

Post by Zefram
non-existence of resources in a standard manner (NXDOMAIN in this case)
in order to give the client the choice of how to handle

non-existence.

Post by Zefram
If IE wishes to default to doing a web search under those

circumstances,

Post by Zefram
that is silly but harms no one else. What Verisign has done

pre-empts

Post by Zefram
that choice for everyone.
-zefram
--
_______________________________________________

which is a sublist of ***@ietf.org. Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

[Edward Lewis]

Post by Zefram
Yes, it is worse. Much worse. There is a fundamental difference between
this defaulting happening in the DNS and happening in a client program.
It is necessary that the wire protocols distinguish between existence and
non-existence of resources in a standard manner (NXDOMAIN in this case)
in order to give the client the choice of how to handle non-existence.

Here we go with DNS, wild card synthesis and existence again... ;)

I think there are a few separate issues here. One is understanding
the role of 'name errors' (the original name of NXDOMAIN) and wild
card synthesis in DNS. The other is understanding the difference
between DNS and registry contents. The operational issue is the
conditions under which the change was made.

As someone whose spent a lot of time studying DNS and currently is
editing a DNSEXT WG document on the topic of wild cards, what is
going on here is well within the protocol design of DNS. I can't see
an operational issue here either.

Having experience as the co-chair of PROVREG WG, I'd like to make a
case that the DNS isn't the best means to determine if an object
(even if it is a domain name) is registered - it's a first order
guess but not the last word. There are names registered that may not
have working servers (hence suspended from the DNS to prevent lame
delegations) or are otherwise reserved or suspended. There are
plenty of network address objects in use - in routing tables - that
are not in the reverse DNS map. So, to those who were relying on DNS
for "existence" or "legitimacy," perhaps they need to consider an
alternate method. (Namely something like whois or crisp.)

Operationally, at least the change was made on a Monday. But given
that there are other operational systems relying on the existing
conditions, advance notice would have been a good idea. In defense
of not giving the advance notice, it's sometimes not clear who is
impacted by a change because of the open nature of the Internet.

As someone who doesn't run spam tools (others do it for me), it
wasn't obvious to me until reading the threads of the impact of the
change on spam defenses. I can understand how someone in the spam
trenches would see the obvious impact, but be patient with others
that are not in the trenches with you.

PS - With DNSSEC, you'll be able to distinguish between synthesized
(wild card) answers and straight answers. If you want to see DNSSEC
because of this, get active in the the DNSEXT WG and help the effort
along.

PPS - Maybe this will raise the need for the CRISP WG to develop a protocol.

[Bruce Campbell]

Post by Edward Lewis

Post by Zefram
It is necessary that the wire protocols distinguish between existence and
non-existence of resources in a standard manner (NXDOMAIN in this case)
in order to give the client the choice of how to handle non-existence.

[ on dns not the best choice for authoritative non-existence ]

Post by Edward Lewis
are not in the reverse DNS map. So, to those who were relying on DNS
for "existence" or "legitimacy," perhaps they need to consider an
alternate method. (Namely something like whois or crisp.)

I'm not sure whether thats a good idea. The main fuss at the moment,
apart from Verisign acting without consultation, is that a lot of
automated software makes the assumption that 'NXDOMAIN' means 'Does Not
Exist'. Adding the wildcard removes this assumption, and removes DNS as a
useful stateless low-overhead method of existence-verification.

For these items of software to change from using a stateless method of
existence-verification with low overhead, to using a semi-stateless method
of existence-verification with high overhead, is something akin to the Y2K
bug in scope, albeit without all the hype.

Operationally, having one's not-low-overhead whois server being hit by
automated queries solely for existence-verification is a terrible state of
affairs.

Post by Edward Lewis
PPS - Maybe this will raise the need for the CRISP WG to develop a protocol.

I can see a lot of people requesting a low-overhead stateless subset of
crisp/whois.

[Dean Anderson]

inline

Post by Bruce Campbell

Post by Edward Lewis

Post by Zefram
It is necessary that the wire protocols distinguish between existence and
non-existence of resources in a standard manner (NXDOMAIN in this case)
in order to give the client the choice of how to handle non-existence.

[ on dns not the best choice for authoritative non-existence ]

Post by Edward Lewis
are not in the reverse DNS map. So, to those who were relying on DNS
for "existence" or "legitimacy," perhaps they need to consider an
alternate method. (Namely something like whois or crisp.)

I'm not sure whether thats a good idea. The main fuss at the moment,
apart from Verisign acting without consultation, is that a lot of
automated software makes the assumption that 'NXDOMAIN' means 'Does Not
Exist'. Adding the wildcard removes this assumption, and removes DNS as a
useful stateless low-overhead method of existence-verification.

Err, actually, its the opposite that they are assuming. They assume that
lack of an NXDOMAIN means the domain does exist. That is an invalid
assumption.

Post by Bruce Campbell
For these items of software to change from using a stateless method of
existence-verification with low overhead, to using a semi-stateless method
of existence-verification with high overhead, is something akin to the Y2K
bug in scope, albeit without all the hype.

The correct way to check for "domain existance" for email is to lookup an
MX record.

Post by Bruce Campbell
Operationally, having one's not-low-overhead whois server being hit by
automated queries solely for existence-verification is a terrible state of
affairs.

One shouldn't be doing whois queries. One just wants to know if the domain
of the sender can receive email, back.

--Dean

[Bruce Campbell]

Post by Dean Anderson

Post by Bruce Campbell
For these items of software to change from using a stateless method of
existence-verification with low overhead, to using a semi-stateless method
of existence-verification with high overhead, is something akin to the Y2K
bug in scope, albeit without all the hype.

The correct way to check for "domain existance" for email is to lookup an
MX record.

That would be the correct method as defined in RFC2821 would it? The one
which specifies:

5. Address Resolution and Mail Handling

If no MX records are found, but an A RR is found, the A RR
is treated as if it was associated with an implicit MX RR,
with a preference of 0, pointing to that host.

Post by Dean Anderson

Post by Bruce Campbell
Operationally, having one's not-low-overhead whois server being hit by
automated queries solely for existence-verification is a terrible state of
affairs.

One shouldn't be doing whois queries. One just wants to know if the domain
of the sender can receive email, back.

Yes. If I receive an SMTP connection purporting to be from
'***@ssdflvndslkvn.com', and I follow the established standards for
seeing whether I can send mail back, I end up with 64.94.110.11 . Ergo,
as far as that domain is concerned, it can receive mail back.

( This was covered at least 40 messages ago, do try to keep up ).

--==--
Bruce.

[Edward Lewis]

Post by Dean Anderson
Err, actually, its the opposite that they are assuming. They assume that
lack of an NXDOMAIN means the domain does exist. That is an invalid
assumption.

Using DNS to determine existence is a decent heuristic, but it isn't
exact. That's my point, in summary. (IOW - we agree.)

Post by Dean Anderson
One shouldn't be doing whois queries. One just wants to know if the domain
of the sender can receive email, back.

I was assuming that the check was done to see if the mail could be
"traced" back - from "claimed source address" to domain name to
registrant. Of course, with spoofing, nothing can be trusted, but if
it is legit, you should be able to check it out.

If the case is just to see if mail can go back, then yeah, there
oughta be an MX.

[Keith Moore]

Post by Bruce Campbell

Post by Zefram
It is necessary that the wire protocols distinguish between
existence and non-existence of resources in a standard manner
(NXDOMAIN in this case) in order to give the client the choice of
how to handle non-existence.

[ on dns not the best choice for authoritative non-existence ]

it's hard to imagine that there's a better oracle than DNS to ask about
the (non-) existence of a DNS name.

now to assume that the DNS name is bound to anything in particular,
like a host, or a particular business concern, that would be a stretch.

[David Morris]

Post by Bruce Campbell
Operationally, having one's not-low-overhead whois server being hit by
automated queries solely for existence-verification is a terrible state of
affairs.

Has anyone tried Verisign's whois server ... at least their 'web'
interface which is impractical to automate access to because of a
fuzzy image which a human or similar of visual discernment must
read?

[Keith Moore]

Post by Edward Lewis
Having experience as the co-chair of PROVREG WG, I'd like to make a
case that the DNS isn't the best means to determine if an object
(even if it is a domain name) is registered - it's a first order
guess but not the last word.

I strongly disagree. The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an entry
in the DNS. Making existence of a domain depend on a separate
registry makes no sense and is inconsistent with longstanding practice.

What's happening here is that the COM and NET zones were supposed to
reflect their respective registries, but Verisign is adding records to
the DNS that are not in the registry. This is fraud.

Post by Edward Lewis
There are
plenty of network address objects in use - in routing tables - that
are not in the reverse DNS map.

that's not the same thing at all. DNS is not the authority for whether
a device is connected to the net. DNS is the authority on whether a DNS
name exists.

[Edward Lewis]

Post by Keith Moore
I strongly disagree. The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an entry
in the DNS. Making existence of a domain depend on a separate
registry makes no sense and is inconsistent with longstanding practice.

DNS is the ultimate authority on whether there is an DNS answer to a
DNS query, but that's about it. What a DNS server answers is based
on what is in the registry it represents.

To quote what I wrote on the provreg list in
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00164.html:

"DNS names [...] are limited to 255 octets, which is about 2K bits,
and 2^2k possibilities minus special cases. Boom - all names exist."

The point is, before saying that DNS makes any statement about
"existence" you need to define "exists for what purpose." In the
message above, it was "exists so that I can't register it." In the
wcard clarify draft in DNSEXT, it's "exists for the purposes of
ruling out synthesis of the answer."

Post by Keith Moore
that's not the same thing at all. DNS is not the authority for whether
a device is connected to the net. DNS is the authority on whether a DNS
name exists.

In engineering the DNS, "com." has been and still is a peculiar case
and there has been the temptation to tailor the DNS protocol to
accommodate it. The community has said time and again not to do so -
not to treat that zone (and the others growing like it) as special
cases. I think turnabout is fair play - that we not restrict "com."
and the others from using what's in DNS protocol.

I'm neither endorsing nor criticizing what has been added to "com."
and "net." Let's just be fair, accurate, and on-topic (like,
protocols) in the discussion.

[Keith Moore]

Post by Edward Lewis

Post by Keith Moore
I strongly disagree. The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an
entry in the DNS. Making existence of a domain depend on a
separate registry makes no sense and is inconsistent with
longstanding practice.

DNS is the ultimate authority on whether there is an DNS answer to a
DNS query, but that's about it. What a DNS server answers is based
on what is in the registry it represents.

What a DNS server answers is based on what is in the zone it represents.
Not all zones have registries.

Post by Edward Lewis
To quote what I wrote on the provreg list in
"DNS names [...] are limited to 255 octets, which is about 2K bits,
and 2^2k possibilities minus special cases. Boom - all names exist."

You didn't actually cite any support for your statement. And the
existence of the NXDOMAIN response code contradicts that statement.

Post by Edward Lewis
The point is, before saying that DNS makes any statement about
"existence" you need to define "exists for what purpose."

That's beside the point. NXDOMAIN is still a meaningful condition even
though you can't tell what a domain means if it does exist.

Post by Edward Lewis

Post by Keith Moore
that's not the same thing at all. DNS is not the authority for
whether a device is connected to the net. DNS is the authority on
whether a DNS name exists.

In engineering the DNS, "com." has been and still is a peculiar case
and there has been the temptation to tailor the DNS protocol to
accommodate it. The community has said time and again not to do so -
not to treat that zone (and the others growing like it) as special
cases. I think turnabout is fair play - that we not restrict "com."
and the others from using what's in DNS protocol.

It is never appropriate to make wildcard assertions about names within a
zone if those assertions are not true. If all of the names in
foo.example.com zone will always be associated with address a.b.c.d,
it's reasonable to set up a wildcard A record for that zone. Otherwise
it is not reasonable. This is no less true for com or net than for
foo.example.com

COM and NET are supposed to reflect their respective registries - this
isn't itself a DNS protocol issue but part of the arrangement for
managing those zones. VeriSign is making assertions about names that
don't exist in the registries. (It also happens that those assertions
are disruptive to the operation of protocols when those protocols use
names in those zones, and that *is* a protocol issue)

Keith

[Dean Anderson]

Post by Keith Moore
I strongly disagree. The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an entry
in the DNS. Making existence of a domain depend on a separate
registry makes no sense and is inconsistent with longstanding practice.

No, the ultimate authority of whether a domain exists is the registry of
domain names. DNS is just a protocol to distribute that information.
What you are saying about DNS is like saying BGP is the ultimate authority
of IP address assignment. Obviously, it is the records of assignment that
are the ultimate authority.

We are not just now making a separate registry. There has always been a
separate registry, with records apart from DNS. DNS is a protocol for
distributing DNS records from hierarchically delegated subregistries.
The existance of the TLDs is managed by one registry. The existance of
.net and .com is managed by another.

It is quite reasonable to have all unassigned delegations come back to the
appropriate registry. This is the purpose of a wildcard record. There is
no reason that a registry isn't allowed to have all unassigned delegations
point to it.

--Dean

[Keith Moore]

Post by Dean Anderson

Post by Keith Moore
I strongly disagree. The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an
entry in the DNS. Making existence of a domain depend on a
separate registry makes no sense and is inconsistent with
longstanding practice.

No, the ultimate authority of whether a domain exists is the registry
of domain names.

There is no registry of domain names; there are only registries for a
few zones. You could claim that the registry for the other zones is
in a zone file somewhere, and that's the ultimate authority for that
zone, but that would be a stretch. If a domain isn't listed in DNS then
practically speaking it does not exist. (LLMNR might change that if they
ever make it reasonable enough to use - I will reserve judgement on the
lastest draft until I have read it).

Even if the domain might not be in DNS but still be in the registry for
that zone, and there were a way to query that registry, would you expect
apps to special-case handling of the zones that were defined by
registries? Given that they couldn't get the RRs for that domain
anyway, what would be the point of their doing so?

We've got ~16 years of history that says that NXDOMAIN means that the
domain does not exist, that is fully consistent with the protocol
specifications and which is built into apps. Changing this behavior
would be incompatible with all that code, and VeriSign's attempt to
subvert the COM and NET zones is not a compelling reason to do so.

Keith

p.s. Now, with something like LLMNR we might someday have a way of
distributing domain names and their RRsets that is separate from DNS,
and it could be very useful for it to do so. But in order to be viable
it needs to produce results that are consistent with DNS. We can't have
two different lookup services for the same names producing mutually
inconsistent results.

Note that this is not the same problem that VeriSign is causing -
VeriSign is uniformly mis-representing the COM and NET registries and
mis-reporting NXDOMAIN error conditions for these zones as successful
queries, which is not the same thing as producing inconsistent results
depending on who is asking. But it does relate to the question of
whether the DNS is the authority for DNS name information or just a way
of obtaining the information.

[Dean Anderson]

Post by Keith Moore

Post by Dean Anderson

Post by Keith Moore
I strongly disagree. The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an
entry in the DNS. Making existence of a domain depend on a
separate registry makes no sense and is inconsistent with
longstanding practice.

No, the ultimate authority of whether a domain exists is the registry
of domain names.

There is no registry of domain names; there are only registries for a
few zones.

Well, ICANN registers the Top level domains for something like 80+ top
level zones including country code zones. You can't have a TLD unless you
register with ICANN, first, and meet the requirements for a TLD. These
TLD sub-registries then have their own rules. ".com" and ".net" are two
that are (partially) handled by NetSol.

I know that there used to be a database of files which contained the
registration info. The DNS Zone files for .com, .net, .org etc were
generated by scripts that read these files. That database is accessed by
whois, which also accessed the files. I suspect this flat file database
has been converted to a relational database, but I can't be sure. When
Network solutions was created, the flat files were transfered to them,
from SRI, I think. I think there were paper records that were kept, too.

When you sent in registation email, scripts would process registration
templates into the flat files. Network solutions first added fees to this
process. Later, other registries were created.

Post by Keith Moore
You could claim that the registry for the other zones is
in a zone file somewhere, and that's the ultimate authority for that
zone, but that would be a stretch. If a domain isn't listed in DNS then
practically speaking it does not exist.

No, this isn't the case. A domain may not be in DNS in the case that it
exists but is suspended for some reason. There may be other reasons, such
as the DNS zones have been updated since the domain was created.

Post by Keith Moore
Even if the domain might not be in DNS but still be in the registry for
that zone, and there were a way to query that registry, would you expect
apps to special-case handling of the zones that were defined by
registries? Given that they couldn't get the RRs for that domain
anyway, what would be the point of their doing so?

I wouldn't expect that, unless of course, they are other registries trying
to register the domain.

People keep saying that something has been broken. But in fact, nothing
has been broken, except false assumptions that were false to begin with.
People have been told these assumptions are false by people on the various
DNS lists. They were well aware of the falseness of their assumptions, or
they ought to have been. This is not something that is surprising to any
reasonable person in any way whatsoever. These people just assumed that if
they kept using reverse DNS this way, that they would be able to keep
doing it. Well, that isn't how it works, is it?

Post by Keith Moore
We've got ~16 years of history that says that NXDOMAIN means that the
domain does not exist, that is fully consistent with the protocol
specifications and which is built into apps. Changing this behavior
would be incompatible with all that code, and VeriSign's attempt to
subvert the COM and NET zones is not a compelling reason to do so.

NXDOMAIN means the domain isn't in the DNS distributed databse. It
doesn't mean that it isn't registered. However, NXDOMAIN hasn't been
wrongly sent. It is not the case that NXDOMAIN _MUST_ be sent. That would
preclude wildcard records.

Further, lack of NXDOMAIN does't mean the record exists. Only NXDOMAIN
has meaning. No NXDOMAIN response means nothing. That is the case we
have. There is nothing that says a registry has to return NXDOMAIN
instead of a wildcard match.

Post by Keith Moore
p.s. Now, with something like LLMNR we might someday have a way of
distributing domain names and their RRsets that is separate from DNS,
and it could be very useful for it to do so. But in order to be viable
it needs to produce results that are consistent with DNS. We can't have
two different lookup services for the same names producing mutually
inconsistent results.
Note that this is not the same problem that VeriSign is causing -
VeriSign is uniformly mis-representing the COM and NET registries and
mis-reporting NXDOMAIN error conditions for these zones as successful
queries, which is not the same thing as producing inconsistent results
depending on who is asking. But it does relate to the question of
whether the DNS is the authority for DNS name information or just a way
of obtaining the information.

It is not _mis-reporting_ anything. Just the opposite in fact. The
purpose of a wildcard is to match queries that aren't matched by other
records. This is legal report and response for any zone.

--Dean

[Keith Moore]

Post by Dean Anderson
People keep saying that something has been broken. But in fact, nothing
has been broken, except false assumptions that were false to begin with.

You're simply wrong, and there have been numerous examples of this.

Post by Dean Anderson
NXDOMAIN means the domain isn't in the DNS distributed databse. It
doesn't mean that it isn't registered.

The app doesn't care whether the domain is registered. The app cares whether
the domain exists in DNS, because using DNS to look up the address is the way
the app is designed to work. Putting the domain in DNS is (either implicitly
or explicitly) part of the application protocol.

Post by Dean Anderson
However, NXDOMAIN hasn't been
wrongly sent. It is not the case that NXDOMAIN _MUST_ be sent. That would
preclude wildcard records.

Wildcard records make a global assertion for an entire zone. This is not
an assertion that VeriSign is entitled to make. VeriSign does not have the
right to make assertions about all unregistered domains in NET or COM.

Post by Dean Anderson
Further, lack of NXDOMAIN does't mean the record exists. Only NXDOMAIN
has meaning. No NXDOMAIN response means nothing. That is the case we
have.

No the case we have is not the lack of a response. It is a response
containing an A record. That A record is a lie.

Post by Dean Anderson

Post by Keith Moore
Note that this is not the same problem that VeriSign is causing -
VeriSign is uniformly mis-representing the COM and NET registries and
mis-reporting NXDOMAIN error conditions for these zones as successful
queries, which is not the same thing as producing inconsistent results
depending on who is asking. But it does relate to the question of
whether the DNS is the authority for DNS name information or just a way
of obtaining the information.

It is not _mis-reporting_ anything.

That is precisely what it is doing.

Keith

[Bill Manning]

% Wildcard records make a global assertion for an entire zone. This is not
% an assertion that VeriSign is entitled to make. VeriSign does not have the
% right to make assertions about all unregistered domains in NET or COM.
%
Can you back up your assertion that Verisign is -NOT- entitled?
A number of us think that they do, in fact, have the right to
assert information about COM and NET, registered or not. I have
reason to beleive this, since they assert their rights to do so
at least twice a day.

% Keith

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

[Keith Moore]

Post by Bill Manning
% Wildcard records make a global assertion for an entire zone. This is not
% an assertion that VeriSign is entitled to make. VeriSign does not have
the% right to make assertions about all unregistered domains in NET or COM.
%
Can you back up your assertion that Verisign is -NOT- entitled?

I've already done so, from numerous angles.

Post by Bill Manning
A number of us think that they do, in fact, have the right to
assert information about COM and NET, registered or not. I have
reason to beleive this, since they assert their rights to do so
at least twice a day.

Just like a thief asserts his rights to your property. Neither one is right.

[Bill Manning]

% > % Wildcard records make a global assertion for an entire zone. This is not
% > % an assertion that VeriSign is entitled to make. VeriSign does not have
% > the% right to make assertions about all unregistered domains in NET or COM.
% > %
% > Can you back up your assertion that Verisign is -NOT- entitled?
%
% I've already done so, from numerous angles.

ok, what about DoC & ICANN agreements w/ VSGN giving them
the authority to continue to register in and publish
the .COM and .NET domains? That looks like an entitlment to me.

% > A number of us think that they do, in fact, have the right to
% > assert information about COM and NET, registered or not. I have
% > reason to beleive this, since they assert their rights to do so
% > at least twice a day.
%
% Just like a thief asserts his rights to your property. Neither one is right.

Are you insinuating that COM and NET are "your" property?
Verisign has and continues to publish .COM and .NET zone data
twice each day that is marked with records that indicate
they, Verisign are asserting their rights to publish the
data in those zones. If you think that Verisign has stolen
.COM and .NET, then you should make your concerns known to
your legal advisors, DoC, and Verisign.

--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

[Keith Moore]

Post by Bill Manning
ok, what about DoC & ICANN agreements w/ VSGN giving them
the authority to continue to register in and publish
the .COM and .NET domains? That looks like an entitlment to me.

the very purpose of those agreements - hell, the primary purpose of ICANN, is
to constrain how NSI/VeriSign maintains those zones. how in the world you can
interpret this as an entitlement to VeriSign to make arbitrary and disruptive
changes to the zone is beyond me.

of course there are some people who feel that anything that you can get
away with becomes an entitlement. I don't happen to share that belief, but
if you are one of those who do, there's no point in our discussing it
further. but you might want to think about the implications of a world where
the only to solve problems like this is by force.

Post by Bill Manning
If you think that Verisign has stolen
.COM and .NET, then you should make your concerns known to
your legal advisors, DoC, and Verisign.

the NET owns .COM and .NET.

[grenville armitage]

Bill Manning wrote:
[..]

Post by Bill Manning
Verisign has and continues to publish .COM and .NET zone data
twice each day that is marked with records that indicate
they, Verisign are asserting their rights to publish the
data in those zones.

"... publish the data in those zones."

if Verisign were not now also (effectively) _adding_ unlimited data to
those zones, i suspect we'd have less of a debate right now.

cheers,
gja

[Masataka Ohta]

Bill;

Post by Bill Manning
% Wildcard records make a global assertion for an entire zone. This is not
% an assertion that VeriSign is entitled to make. VeriSign does not have the
% right to make assertions about all unregistered domains in NET or COM.
%
Can you back up your assertion that Verisign is -NOT- entitled?
A number of us think that they do, in fact, have the right to
assert information about COM and NET, registered or not. I have
reason to beleive this, since they assert their rights to do so
at least twice a day.

Right.

Because of the freedom of speech, anyone has the basic right to
assert anything, of course.

Others have right to ignore it.

And, if a false assertion causes damage to others, then...

Masataka Ohta

[Dean Anderson]

Post by Keith Moore

Post by Dean Anderson
People keep saying that something has been broken. But in fact, nothing
has been broken, except false assumptions that were false to begin with.

You're simply wrong, and there have been numerous examples of this.

Sounds like a canard.

Post by Keith Moore

Post by Dean Anderson
NXDOMAIN means the domain isn't in the DNS distributed databse. It
doesn't mean that it isn't registered.

The app doesn't care whether the domain is registered. The app cares whether
the domain exists in DNS, because using DNS to look up the address is the way
the app is designed to work. Putting the domain in DNS is (either implicitly
or explicitly) part of the application protocol.

The app is designed incorrectly. Only mail relays are expected to be able
to route mail.

As Valdis points out, the mail server should look up the address, and upon
connecting to port 25, it finds the mail rejected. A bounce is returned,
as it should be. A bounce would also be returned if there was nothing
listening on port 25. As it should be. There is nothing broken by having
a wildcard, that wasn't broken before by false assumptions.

Post by Keith Moore

Post by Dean Anderson
However, NXDOMAIN hasn't been
wrongly sent. It is not the case that NXDOMAIN _MUST_ be sent. That would
preclude wildcard records.

Wildcard records make a global assertion for an entire zone. This is not
an assertion that VeriSign is entitled to make. VeriSign does not have the
right to make assertions about all unregistered domains in NET or COM.

I think they do. They think they do. Other TLDs think they do. They have
the right to insert records into .net and .com. And they have the
privilege of selling entries in those zones. So, upon what is your
assertion based on?

Post by Keith Moore

Post by Dean Anderson
Further, lack of NXDOMAIN does't mean the record exists. Only NXDOMAIN
has meaning. No NXDOMAIN response means nothing. That is the case we
have.

No the case we have is not the lack of a response. It is a response
containing an A record. That A record is a lie.

No, it is a wildcard. It is no more or less a lie than any other wildcard.

Post by Keith Moore

Post by Dean Anderson

Post by Keith Moore
Note that this is not the same problem that VeriSign is causing -
VeriSign is uniformly mis-representing the COM and NET registries and
mis-reporting NXDOMAIN error conditions for these zones as successful
queries, which is not the same thing as producing inconsistent results
depending on who is asking. But it does relate to the question of
whether the DNS is the authority for DNS name information or just a way
of obtaining the information.

It is not _mis-reporting_ anything.

That is precisely what it is doing.

You have yet explain how is it misreporting anything. It in fact
reporting that the domain is available for purchase. How is that
misreporting?

Other TLDs have been doing this for a long time. What are they
misreporting?

--Dean

[V***@vt.edu]

Post by Dean Anderson
You have yet explain how is it misreporting anything. It in fact
reporting that the domain is available for purchase. How is that
misreporting?

Well.. let's follow this line of reasoning. If I mail to a domain, *and it gets
a pointer to a mail server* then we can conclude one of the following:

1) The domain is *NOT* available for purchase, because it is *IN USE* by
at least that mail server.

2) The domain is available, but is in the DNS. This would by all reasonable
people be judged a miscommunication between the registrar of record and the DNS
server, as there is data in the DNS that is not in any registrar.

If their bogus mailserver answered with an RFC1846 style reply:

521 mailserver.this-never-existed.com Domain Not In Use, contact <...> to purchase

you would *ALMOST* have a leg to stand on.

[Dean Anderson]

Post by V***@vt.edu

Post by Dean Anderson
You have yet explain how is it misreporting anything. It in fact
reporting that the domain is available for purchase. How is that
misreporting?

Well.. let's follow this line of reasoning. If I mail to a domain, *and it gets
1) The domain is *NOT* available for purchase, because it is *IN USE* by
at least that mail server.

No, that isn't correct. If you want to purchase a domain, you have to
check the registry database via whois.

Post by V***@vt.edu
2) The domain is available, but is in the DNS. This would by all
reasonable people be judged a miscommunication between the registrar of
record and the DNS server, as there is data in the DNS that is not in
any registrar.

Again, the method you describe is not a valid or method for determining if
domains are available. Nor is it one that any reasonable person would use
to determine if a domain was available for purchase. So it has no value
as a rationale to justify the claim that something has been misreported.

--Dean

[V***@vt.edu]

Post by Dean Anderson

Post by V***@vt.edu

Post by Dean Anderson
You have yet explain how is it misreporting anything. It in fact
reporting that the domain is available for purchase. How is that
misreporting?

Well.. let's follow this line of reasoning. If I mail to a domain, *and it gets
1) The domain is *NOT* available for purchase, because it is *IN USE* by
at least that mail server.

No, that isn't correct. If you want to purchase a domain, you have to
check the registry database via whois.

Why? As you yourself said: "It is in fact reporting that the domain is available
for purchase". If there's a nameserver for the domain, and there's an active
mail host for the domain, that indicates an *IN USE* domain, as far as anybody
can tell *ON THE SMTP PORT*.

[Doug Royer]

Before the change if I email ***@bogushost.com, the email tool would
tell me immedatally
that no such host exists.

Now, it unconditionally sends the email, then later bounces. This is a
HUGE difference
in behaviour.

[Dean Anderson]

It did that if you sent to any other toplevel domain that had wildcards,
and others do.

The behavior hasn't changed.

Your mail client was making a false assumption. That is a bug in the
software. The mail client shouldn't be looking up domains. It should be
sending it to the relay. The relay then decides where to send the message.
The relay may be configured to route non-DNS domains, or do translations
to other systems. Your mail client can't know about that. If the relay
can't send the message somewhere, then it is supposed to bounce the
message. This decision is made by the relay, not the mail client.

Your mail client has had a bug, for a long time.

--Dean

Post by Doug Royer
tell me immedatally
that no such host exists.
Now, it unconditionally sends the email, then later bounces. This is a
HUGE difference
in behaviour.
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
http://Royer.com/People/Doug | Fax: [phone]
| Cell: [phone]
We Do Standards - You Need Standards

[w***@elan.net]

Post by Dean Anderson
Your mail client was making a false assumption. That is a bug in the
software. The mail client shouldn't be looking up domains. It should be
sending it to the relay. The relay then decides where to send the message.
The relay may be configured to route non-DNS domains, or do translations
to other systems. Your mail client can't know about that. If the relay
can't send the message somewhere, then it is supposed to bounce the
message. This decision is made by the relay, not the mail client.
Your mail client has had a bug, for a long time.

Its not a bug. As many pointed out RFCs specify that mail servers should
attempt to get MX record for domain first but if it fails should use "A"
record if it exists. This behavior has existed for long time, but I think
it came from way early on the internet when MXs were not used by everybody
and mail was still being routed directly to the machine specified.

Its possible that this is also used (dont know how much) for internal mail
routing (i.e. when ***@companydomain.com is received by public mail
gateway it is then rerouted to ***@corporate.mailserver.domain.com
and mail administrator is too lazy to enter MX for corporate.mailserver
possibly because they are not even using DNS internally and are using
WINS or domain is directly in the mail routing gateway, like in /etc/hosts)

What would be interesting is too try to get some statistics on how much
the direct A DNS records (as opposed to MXs) are really used nowdays and
if the number if sufficiently small (on the public internet, i.e. if its
done on company net as described above, then mail routing software may handle
case as it wants anyway), it maybe good idea for IETF to release update
BCP to specify that mail should ALWAYS be routed to MX record and failure
maybe issued if it does not exist.

[Dean Anderson]

Post by w***@elan.net

Post by Dean Anderson
Your mail client was making a false assumption. That is a bug in the
software. The mail client shouldn't be looking up domains. It should be
sending it to the relay. The relay then decides where to send the message.
The relay may be configured to route non-DNS domains, or do translations
to other systems. Your mail client can't know about that. If the relay
can't send the message somewhere, then it is supposed to bounce the
message. This decision is made by the relay, not the mail client.
Your mail client has had a bug, for a long time.

^^^^^^

Post by w***@elan.net
Its not a bug. As many pointed out RFCs specify that mail servers should

^^^^^^^
I think you have pointed out that this is indeed the function of a mail
server, not a mail client. It is a bug.

Post by w***@elan.net
attempt to get MX record for domain first but if it fails should use "A"
record if it exists. This behavior has existed for long time, but I think
it came from way early on the internet when MXs were not used by everybody
and mail was still being routed directly to the machine specified.

[V***@vt.edu]

Post by Dean Anderson
I think you have pointed out that this is indeed the function of a mail
server, not a mail client. It is a bug.

OK Dean, let's go back and look at the original message.

Post by Dean Anderson
tell me immedatally
that no such host exists.

Well you know what Dean? When I mail to a duff address, my MUA (exmh)
hands it off to a proper MTA, and the MTA gets an error. And it hands a bounce
message back to my MUA, which tells me about it.

Hey - look what my mail tool is telling me:

----
(multipart/report)
Human-readable report (text/plain)
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************

The original message was received at Tue, 16 Sep 2003 15:42:05 -0400 (EDT)
from IDENT:***@evil-zidane [10.1.1.13]

----- Transcript of session follows -----
<***@vsu.edu>... Deferred: Connection timed out with vsu.vsu.edu.
Warning: message still undelivered after 1 day
Will keep trying until message is 3 days old
----

The DSN was generated on a Alphaserver running Sendmail some 8 miles
from where I'm typing. My laptop never even tried to resolve vsu.edu in connection
with this transaction. But I'm getting the notification from my MUA.

And neither is there any actual justification for your claim that the original poster's
mail client tried to do the lookup.

So all your sophistry about "the client shouldn't be doing it" is just that. Sophistry.

[Anthony Atkielski]

Post by Dean Anderson
I think you have pointed out that this is indeed the function of a mail
server, not a mail client. It is a bug.

SMTP makes no distinction between servers and clients. It's not a bug.

[Keith Moore]

Post by Dean Anderson
Your mail client was making a false assumption. That is a bug in the
software. The mail client shouldn't be looking up domains. It should be
sending it to the relay.

No, you're making an incorrect assumption. It's perfectly valid for a
mail client to send mail directly to the MX for the recipient domain
(or A record if there is no MX) That's how mail was intended to work,
having a local relay is just a popular optimization. So it's perfectly valid
for a mail client to look up domain names, and it's perfectly valid for a mail
client to assume that NXDOMAIN means that the domain does not exist. again,
that is how the mail protocol is defined to work.

Your attempt to reinterpret the mail specs in order to apologize for
VeriSign's fraud and unfair business practice is not in the least bit
persuasive.

[Dean Anderson]

Post by Keith Moore

Post by Dean Anderson
Your mail client was making a false assumption. That is a bug in the
software. The mail client shouldn't be looking up domains. It should be
sending it to the relay.

No, you're making an incorrect assumption. It's perfectly valid for a
mail client to send mail directly to the MX for the recipient domain
(or A record if there is no MX) That's how mail was intended to work,
having a local relay is just a popular optimization. So it's perfectly valid
for a mail client to look up domain names, and it's perfectly valid for a mail
client to assume that NXDOMAIN means that the domain does not exist. again,
that is how the mail protocol is defined to work.

No, its not valid for a mail client to make direct connections. There are
many ISPs that block this. Are they doing something wrong? Mail clients
are supposed to connect to their configured mail relays, which has the
responsibility to route mail.

Post by Keith Moore
Your attempt to reinterpret the mail specs in order to apologize for
VeriSign's fraud and unfair business practice is not in the least bit
persuasive.

What is not persuasive is the attempts to claim they did anything wrong.

--Dean

[Keith Moore]

Post by Dean Anderson
No, its not valid for a mail client to make direct connections. There are
many ISPs that block this. Are they doing something wrong?

IMHO yes, but that's between them and their customers.

Post by Dean Anderson
Mail clients
are supposed to connect to their configured mail relays, which has the
responsibility to route mail.

this is a figment of your imagination.

[Doug Royer]

Post by Dean Anderson
No, its not valid for a mail client to make direct connections.

Can you site any RFC that says that?

Post by Dean Anderson
There are
many ISPs that block this. Are they doing something wrong?

Orthogonal and unrelated.

Post by Dean Anderson
Mail clients
are supposed to connect to their configured mail relays, which has the
responsibility to route mail.

Says who?

Post by Dean Anderson

Post by Keith Moore
Your attempt to reinterpret the mail specs in order to apologize for
VeriSign's fraud and unfair business practice is not in the least bit
persuasive.

What is not persuasive is the attempts to claim they did anything wrong.

Breaking existing applications like MUA's (and your ISP's relays)
is wrong.

[Neal McBurnett]

I've put up a web page about this at:

http://bcn.boulder.co.us/~neal/ietf/verisign-abuse.html

with technical issues, pointers to relevant discussions, ICANN
agreements, contact info, etc.

I'd appreciate any pointers to similar efforts, or
suggestions for updates.

Neal McBurnett http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60

[Anthony Atkielski]

Post by Dean Anderson
No, its not valid for a mail client to make direct
connections.

There is no distinction between a mail client and a mail server in SMTP. It
is perfectly valid for either to deliver mail directly to another SMTP
server.

[V***@vt.edu]

Post by Dean Anderson
Your mail client was making a false assumption. That is a bug in the
software. The mail client shouldn't be looking up domains. It should be
sending it to the relay. The relay then decides where to send the message.

OK. Now repeat your entire thing, this time from the point of view of the MTA
that's just been handed a piece of mail by the MSA. Hey.. the MTA *should*
be looking up domains, and deciding where to route them. And most MTAs
really appreciate it if the DNS gives them *useful* information like an NXDOMAIN
return if it doesn't exist, so it can bounce the mail *RIGHT NOW* rather than
having it sit in a queue for hours or days waiting for Verisign's Snubby BMTP
(Broken Mail Transport Program) to become available so it can do something
silly like harvest the From: line and then reject the mail.

For bonus points, work out what happens to your mail if you happen to get
more than one RCPT TO (possibly by sending to 2 or 4 people at the same now-defunct
site). Wow, that 221 shows up at an inconvenient time, doesn't it?

[Doug Royer]

Post by Dean Anderson
It did that if you sent to any other toplevel domain that had wildcards,
and others do.
The behavior hasn't changed.
Your mail client was making a false assumption. That is a bug in the
software. The mail client shouldn't be looking up domains. It should be
sending it to the relay.

There is no rule that says that my smart MUA can not deliver email
itself. Not a bug.

[bill]

Depends on if you have wildcarded MX records as well too.

The mail might never bounce. Who is to say a clever spammer wouldn't
setup a wildcarded series of MX records to point to their own SMTP
servers, and harvest the FROM/REPLY TO addresses and place them in to
their spam lists. (obviously the TO field is wrong, since it's domain
bounced - however I wonder if you could take the @part.com and look for
valid domains that come close to matching and add THOSE TO: fields to
the spam directory)

An even WORSE difference in behavior (plus you aren't notified that your
mail didn't make it to where you thought it was going)

Bill

-----Original Message-----
From: owner-***@ietf.org [mailto:owner-***@ietf.org] On Behalf Of Doug
Royer
Sent: Wednesday, September 17, 2003 2:26 PM
To: ***@ietf.org
Subject: Re: [Fwd: [Asrg] Verisign: All Your ...



Before the change if I email ***@bogushost.com, the email tool would
tell me immedatally
that no such host exists.

Now, it unconditionally sends the email, then later bounces. This is a
HUGE difference
in behaviour.

[Tom Lord]

Given the importance of TLDs, perhaps the right thing to do here, for
ietf, is to assume the worst-relevant-case scenario:

* worst:

Presume that a malevolent entity gains control of a TLD.


* relevant:

Assume that through litigious or regulatory or (gasp) voluntary
mechanisms, the malevolent parties are subject to standards. They
must operate the TLD according to approved standards (which
apparently do not currently prohibit or even explicitly discourage
Verisign's behavior).


In other words: write RFCs with the presumption that they will have
force and with the goal that they would prevent objectionable behavior
(which in this case, from what I've seen on the list, is more
ambiguous than one might wish). And then leave the implementation of
"force" up to other entities. This is an alternative to the emerging
game of "core wars" exemplified by the recent patch to BIND.

For the case at hand, the ex-post-facto nature of the new standard is
problematic and RFCs should explain how and why that should be taken
into account.

In the best case, no force is actually necessary, and entities such as
Verisign will simply choose to comply voluntarily because so many
people have agreed that they should.

In other words: express the sin negatively as an RFC. That it is the
case, list traffic suggests, other TLD custodians have performed
similar acts without objection, complicates the issue, of course.

-t

[Anthony Atkielski]

What Verisign has done pre-empts that choice for everyone.

There's a simple way to stop Verisign: Type a domain name corresponding to
a registered trademark (or a near spelling of a registered trademark), for a
domain that isn't registered. When Verisign comes up with its own page, sue
Verisign for misuse of the trademark. In no time, Verisign will have
restored things back the way they were, since that would be cheaper than
trying to ensure that every single non-existent domain name typed is not a
registered trademark or something that resembles a registered trademark.

[Keith Moore]

Post by Dean Anderson
Is it any worse than IE taking you to msn search when a domain doesn't
resolve?

yes. if an app that interfaces to humans masks the difference between an
invalid domain and a valid one, it only affects people who use that particluar
app. however for other apps the difference between an invalid domain and a
valid one is significant.

verisign is masking the difference between a valid domain and NXDOMAIN for
all protocols, all users, and all software.

[James M Galvin]

On Tue, 16 Sep 2003, Keith Moore wrote:

verisign is masking the difference between a valid domain and
NXDOMAIN for all protocols, all users, and all software.

If you read the Verisign documentation (which is quite excellent by the
way) on what they did and what they recommend you will see that they
thought about this.

In fact, the purpose of the Stubby SMTP daemon is to return a 550 for
non-existent recipient domains.

It is left as an exercise to the reader as to which is more efficient:
DNS NXDOMAIN or SMTP 550.

Although taking note of the returned IP address and reacting accordingly
is roughly equivalent to DNS NXDOMAIN. It just requires an extra step
and more importantly a patched application. Would have been nice to get
some advance notice even if there are other TLDs that have been doing
this for some time. By the way, they do mention the other TLDs in their
documentation.

It is worth noting that if we are to "pass judgement against" Verisign
there are at least half-dozen other TLDs that blazed the trail. We just
overlooked them because of their size as compared to .NET and .COM.

Jim

[Keith Moore]

Post by Keith Moore
verisign is masking the difference between a valid domain and
NXDOMAIN for all protocols, all users, and all software.
If you read the Verisign documentation (which is quite excellent by the
way) on what they did and what they recommend you will see that they
thought about this.

their mistake is in assuming that they can respond appropriately for
all ports - particularly when the association of applications with
known ports is only advisory, and many ports are open for arbitrary use.

in fact, a 550 response in SMTP is a different condition from NXDOMAIN,
and sometimes the difference is important - as the spam filter folks
have discovered.

Post by Keith Moore
Although taking note of the returned IP address and reacting accordingly
is roughly equivalent to DNS NXDOMAIN. It just requires an extra step
and more importantly a patched application. Would have been nice to get
some advance notice even if there are other TLDs that have been doing
this for some time.

"nice" is not a word that seems to apply to forcing the entire net to have to
patch its applications and libraries just because verisign decided to make
inappropriate assertions about unregistered domains. that's like calling
a mugger "nice" because he talks to you politely while he takes your wallet
at gunpoint.

Post by Keith Moore
It is worth noting that if we are to "pass judgement against" Verisign
there are at least half-dozen other TLDs that blazed the trail. We just
overlooked them because of their size as compared to .NET and .COM.

not only their size, but their scope also.

[James M Galvin]

On Tue, 16 Sep 2003, Keith Moore wrote:

their mistake is in assuming that they can respond appropriately for
all ports - particularly when the association of applications with
known ports is only advisory, and many ports are open for arbitrary
use.

Agreed but this is overstating the issue since interoperability demands
we know which port is doing what and when. What we needed was time to
either stop this before it happened or to deal with the implications.

in fact, a 550 response in SMTP is a different condition from NXDOMAIN,
and sometimes the difference is important - as the spam filter folks
have discovered.

Yes and this could be fixed with a new well-defined error code, which
brings us back to needing time to make an adjustment (or to have stopped
it from ever happening).

Post by James M Galvin
Would have been nice to get
some advance notice even if there are other TLDs that have been doing
this for some time.

"nice" is not a word that seems to apply to forcing the entire net
to have to patch its applications and libraries just because
verisign decided to make inappropriate assertions about unregistered
domains. that's like calling a mugger "nice" because he talks to
you politely while he takes your wallet at gunpoint.

Agreed but let's be fair. Verisign was not first. In fact, they are
almost 10th in the process. Someone earlier (just today, sorry for not
looking back for the name) asked about .museum, which I've seen
references elsewhere to suggest it has in its contract with ICANN to
have this wildcard. I have not confirmed this but undoubtedly someone
out there will know and provide a reference.

And there is the matter of the other TLDs that are already doing this
and have been doing it for some time.

None of this makes it right but let's focus on the issue not Verisign.
And the issue is with ICANN and convincing it that this is bad behavior
for all registries. Verisign just made us all notice.

Post by James M Galvin
It is worth noting that if we are to "pass judgement against" Verisign
there are at least half-dozen other TLDs that blazed the trail. We just
overlooked them because of their size as compared to .NET and .COM.

not only their size, but their scope also.

What's the difference? Their scope matters because of their size, or
vice versa.

Jim

[Keith Moore]

Post by Keith Moore
their mistake is in assuming that they can respond appropriately
for all ports - particularly when the association of applications
with known ports is only advisory, and many ports are open for
arbitrary use.
Agreed but this is overstating the issue since interoperability
demands we know which port is doing what and when.

only the app (not the entire network) needs to know which port to use,
and this doesn't require that every port be assigned to a specific app.

Post by Keith Moore
What we needed was time to
either stop this before it happened or to deal with the implications.

what we need is a way to punish people who abuse the Internet.
personally I think drawing and quartering would be appropriate...

Post by Keith Moore
in fact, a 550 response in SMTP is a different condition from
NXDOMAIN, and sometimes the difference is important - as the spam
filter folks have discovered.
Yes and this could be fixed with a new well-defined error code

NO Jim. VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE CHANGE
ON THE INTERNET, not even with advance notice.

Post by Keith Moore
None of this makes it right but let's focus on the issue not Verisign.

Yes, let's focus on the issue. But let's not ignore who is doing it
either.

What's wrong for VeriSign is wrong for the other TLD operators also.
But Verisign causes much more harm by screwing COM and NET than the
operators of ccTLDs do.

[James M Galvin]

Post by Keith Moore
their mistake is in assuming that they can respond appropriately
for all ports - particularly when the association of applications
with known ports is only advisory, and many ports are open for
arbitrary use.
Agreed but this is overstating the issue since interoperability
demands we know which port is doing what and when.

only the app (not the entire network) needs to know which port to use,
and this doesn't require that every port be assigned to a specific
app.

You can't have it both ways. Either the app is so widespread that the
port in use is at least a de facto standard or it is a "de jure"
standard. Either way it is possible to respond appropriately. And
there aren't that many apps that fall into this category.

But I do agree that in the general case there are a lot of ports to
worry about. I just don't think the general case is a practical
concern. So perhaps we just disagree?

Post by Keith Moore
in fact, a 550 response in SMTP is a different condition from
NXDOMAIN, and sometimes the difference is important - as the spam
filter folks have discovered.
Yes and this could be fixed with a new well-defined error code

NO Jim. VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE CHANGE
ON THE INTERNET, not even with advance notice.

I'm not so sure. Others on this list and other lists, some more
qualified than I, have been asserting there are no rules -- technical or
otherwise -- to prevent Verisign and others from doing what they've
done. Oh we can certainly debate philosophical positions like "do not
harm," but what exactly is the disruption here?

Correct me if I'm wrong, the principle disruption -- and I want to
emphasize disruption here -- I've seen is that a particular spam
indicator no longer works as expected. Is there more to this than that?
Okay, yes, there may be technical DNS issues but it is still not
disruptive to the Internet infrastructure in general as far as I can
tell.

There seems to be no shortage of reasons to dislike the behavior but
what exactly has been disrupted?

Post by Keith Moore
None of this makes it right but let's focus on the issue not Verisign.

Yes, let's focus on the issue. But let's not ignore who is doing it
either.

Ignore, no. But let's not start Verisign bashing either.

What's wrong for VeriSign is wrong for the other TLD operators also.
But Verisign causes much more harm by screwing COM and NET than the
operators of ccTLDs do.

But what exactly is the "screw" here?

Jim

[Vernon Schryver]

Post by James M Galvin
...
Correct me if I'm wrong, the principle disruption -- and I want to
emphasize disruption here -- I've seen is that a particular spam
indicator no longer works as expected. Is there more to this than that?
...

The list I've seen is:

- failing to reject spam based on NXDOMAIN for the envelope sender.
(What you term "the principle disruption")

- rejecting legitimate mail because some long dead DNS-based
blacklists are suddenly resolving

- HTTP spiders will fetch Verisign's robots.txt a lot as they
find bogus domains (e.g. typos in HREFs) resolving.

- HTTP users see a stalled screen instead of an error message as
their browsers wait for Verisign's overloaded HTTP server to
deliver its advertising.


Vernon Schryver ***@rhyolite.com

[David Morris]

Post by Vernon Schryver

Post by James M Galvin
...
Correct me if I'm wrong, the principle disruption -- and I want to
emphasize disruption here -- I've seen is that a particular spam
indicator no longer works as expected. Is there more to this than that?
...

One more I've seen mentioned today ... an incorrect MX record which refers
to a non-existant domain will/may no longer properly fail over to an
alternate lower priority MX entry.

Post by Vernon Schryver
- failing to reject spam based on NXDOMAIN for the envelope sender.
(What you term "the principle disruption")
- rejecting legitimate mail because some long dead DNS-based
blacklists are suddenly resolving
- HTTP spiders will fetch Verisign's robots.txt a lot as they
find bogus domains (e.g. typos in HREFs) resolving.
- HTTP users see a stalled screen instead of an error message as
their browsers wait for Verisign's overloaded HTTP server to
deliver its advertising.

[V***@vt.edu]

Post by James M Galvin
But what exactly is the "screw" here?

Verisign was (as far as I knew) given *stewardship* of the .com and .net zones
as a public trust. I don't see anywhere they were given the right to use their
stewardship to try to make money selling typo eyeballs. (And note that unless
you do something *really* ugly like round-robin the wildcards, only one
organization can do this per TLD - so they're essentially abusing their
monopoly).

So the question boils down to: Are they owners of .com, or merely caretakers?

[James M Galvin]

Post by James M Galvin
But what exactly is the "screw" here?

Verisign was (as far as I knew) given *stewardship* of the .com and
.net zones as a public trust. I don't see anywhere they were given
the right to use their stewardship to try to make money selling typo
eyeballs. (And note that unless you do something *really* ugly like
round-robin the wildcards, only one organization can do this per TLD
- so they're essentially abusing their monopoly).

So the question boils down to: Are they owners of .com, or merely
caretakers?

An excellent question! But that is a discussion that belongs with
ICANN, not the IETF.

Jim

[Rick Wesson]

Post by James M Galvin
An excellent question! But that is a discussion that belongs with
ICANN, not the IETF.
Jim

Jim,

that would be true if the ICANN were functioning and this event is just
proof that the ICANN does not function.

the mission of ICANN (my paraphrase) is "Technical Administration of
Internet ?N?ames and Numbers"

It is ovious to anyone today, that there is no technical oversite of the
DNS today.


-rick

[Jaap Akkerhuis]

So the question boils down to: Are they owners of .com, or merely
caretakers?

An excellent question! But that is a discussion that belongs with
ICANN, not the IETF.

Nearly my reaction as well. Note, using the concept of "ownership"
has/will get quite some lawyers debating.

Some (rhetoric) questions:
If there is a caretaker, who is the owner of what is taken
care of? Under which law system?

jaap

[Anthony Atkielski]

Post by James M Galvin
Correct me if I'm wrong, the principle disruption -- and I want to
emphasize disruption here -- I've seen is that a particular spam
indicator no longer works as expected. Is there more to this than that?

You could make many random DNS requests of a DNS server and flush the cache,
producing a partial denial of service (or at least a drop in performance).
If every single request for a domain produces an address, existent or not,
it takes up more continuing resources than a request that produces an error.
No?

[Keith Moore]

Post by Keith Moore
only the app (not the entire network) needs to know which port to
use, and this doesn't require that every port be assigned to a
specific app.
You can't have it both ways. Either the app is so widespread that the
port in use is at least a de facto standard or it is a "de jure"
standard.

False. Many ports have neither a de factor nor a de jure assignment.

Post by Keith Moore
Either way it is possible to respond appropriately.

False. As I pointed out earlier, there is no SMTP respose which is
equivalent to "this domain does not exist". Furthermore there are
failure modes associated with the wildcard MX record that do not
exist if the server returns NXDOMAIN. For instance, if their SMTP
server is down or unreachable (as it might be from time to time), the
sender will keep retrying to send the message when it should have failed
immediately with NXDOMAIN.

Frankly, your apologies for Verisign's abuse aren't very credible.
The only appropriate response to this situation is to punish Verisign.

Post by Keith Moore
But I do agree that in the general case there are a lot of ports to
worry about. I just don't think the general case is a practical
concern. So perhaps we just disagree?

Perhaps. I actually care about preserving the Internet's ability to
support a wide variety of applications. So arguments of the form
"it works for the web and email, therefore the practical concerns
are taken care of" don't wash. Particularly when it doesn't even
do the right thing for either the web or email. Hint: just because
the protocol is HTTP doesn't mean that the client has a human
typing URLs in and looking at the output.

Post by Keith Moore

Post by Keith Moore
in fact, a 550 response in SMTP is a different condition
from NXDOMAIN, and sometimes the difference is important -
as the spam filter folks have discovered.
Yes and this could be fixed with a new well-defined error code

NO Jim. VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE
CHANGE ON THE INTERNET, not even with advance notice.
I'm not so sure. Others on this list and other lists, some more
qualified than I, have been asserting there are no rules -- technical
or otherwise -- to prevent Verisign and others from doing what they've
done.

Nothing gives VeriSign the right to misrepresent the contents of the
registry. If it's wrong for businesses to register individual
misspelled domain names in the hopes of getting misspelled queries
redirected to their sites, it is surely wrong for VeriSign to do the
same thing for ALL unregistered domains within COM and NET.

Post by Keith Moore
Oh we can certainly debate philosophical positions like "do not
harm," but what exactly is the disruption here?

Have you not been paying attention? When you try to download a web page
that doesn't exist, you don't get a "host does not exist" error, you get
a redirect to a web page. That's fraud. When you try to verify that a
domain is valid, you don't get NXDOMAIN, you get an A record. That's
also fraud. When you try to talk to another port, you get connection
refused, so instead of getting the error that corresponds to "no such
host" you'll probably think it is a temporary error (say, the server is
down) and try again later.

It is a gross protocol violation to take an explicit error indication
that has a very specific meaning and instead map it to what in some
cases looks like valid output, and in other cases looks like a very
different kind of error.

Post by Keith Moore
Correct me if I'm wrong, the principle disruption -- and I want to
emphasize disruption here -- I've seen is that a particular spam
indicator no longer works as expected.

You are wrong.

Post by Keith Moore
Okay, yes, there may be technical DNS issues but it is still not
disruptive to the Internet infrastructure in general as far as I can
tell.

It's broken the ability to detect misspelled domains for every
application and every protocol, for every name under .COM or .NET.

Post by Keith Moore
Yes, let's focus on the issue. But let's not ignore who is doing
it either.
Ignore, no. But let's not start Verisign bashing either.

It's not bashing them to speak the truth about what they are doing.

Keith

[Yakov Shafranovich]

Post by Keith Moore
verisign is masking the difference between a valid domain and
NXDOMAIN for all protocols, all users, and all software.
If you read the Verisign documentation (which is quite excellent by the
way) on what they did and what they recommend you will see that they
thought about this.
In fact, the purpose of the Stubby SMTP daemon is to return a 550 for
non-existent recipient domains.
DNS NXDOMAIN or SMTP 550.

People, have you been reading the posts? The stubby SMTP daemon is not
an SMTP server, it is simply a program that returns the following set of
responses TO ANYTHING THAT IS PASSED TO IT.

----------snip---------
220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready
blah
250 OK
blah
250 OK
blah
550 User domain does not exist.
blh
250 OK
blah
221 snubby2-wceast Snubby Mail Rejector Daemon v1.3 closing transmission
channel
----------snip---------

That means that if the SMTP sender issues a RSET command after HELO,
they will not get a 550 error code for the RCPT TO command, but rather
for the MAIL FROM command as follows:

----------snip---------
220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
EHLO someone.com
250 OK
RSET
250 OK
MAIL FROM:<***@somewhere.com>
550 User domain does not exist.
RCPT TO:<***@somewhere.com>
250 OK
DATA
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission
channel
----------snip---------

[Yakov Shafranovich]

Just to follow up on this - I just spoke to an engineer at Verisign and
he informed me that the SMTP daemon is being replaced in a few hours
with an RFC-compliant one. As for not giving a warning - this came from
a higher policy level at Verisign and he is just an engineer.

Yakov

Post by Yakov Shafranovich

Post by Keith Moore
verisign is masking the difference between a valid domain and
NXDOMAIN for all protocols, all users, and all software.
If you read the Verisign documentation (which is quite excellent by the
way) on what they did and what they recommend you will see that they
thought about this.
In fact, the purpose of the Stubby SMTP daemon is to return a 550 for
non-existent recipient domains.
DNS NXDOMAIN or SMTP 550.

People, have you been reading the posts? The stubby SMTP daemon is not
an SMTP server, it is simply a program that returns the following set of
responses TO ANYTHING THAT IS PASSED TO IT.
----------snip---------
220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready
blah
250 OK
blah
250 OK
blah
550 User domain does not exist.
blh
250 OK
blah
221 snubby2-wceast Snubby Mail Rejector Daemon v1.3 closing transmission
channel
----------snip---------
That means that if the SMTP sender issues a RSET command after HELO,
they will not get a 550 error code for the RCPT TO command, but rather
----------snip---------
220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
EHLO someone.com
250 OK
RSET
250 OK
550 User domain does not exist.
250 OK
DATA
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission
channel
----------snip---------

[Francis Dupont]

In your previous mail you wrote:

People, have you been reading the posts? The stubby SMTP daemon is not
an SMTP server, it is simply a program that returns the following set of
responses TO ANYTHING THAT IS PASSED TO IT.

=> IMHO it should reject SMTP connection from the beginning with
the 521 greeting described in RFC 1846...

Regards

***@enst-bretagne.fr

[Paul Hoffman / IMC]

Post by Francis Dupont
=> IMHO it should reject SMTP connection from the beginning with
the 521 greeting described in RFC 1846...

People are unhappy about VeriSign breaking the rules. But here you
are proposing that they follow an *experimental* RFC whose rules were
not accepted into the later revision of SMTP in RFC 2821. How will
them breaking the rules twice make it better?

--Paul Hoffman, Director
--Internet Mail Consortium

[Keith Moore]

On Thu, 18 Sep 2003 09:22:15 -0700

Post by Paul Hoffman / IMC

Post by Francis Dupont
=> IMHO it should reject SMTP connection from the beginning with
the 521 greeting described in RFC 1846...

People are unhappy about VeriSign breaking the rules. But here you
are proposing that they follow an *experimental* RFC whose rules were
not accepted into the later revision of SMTP in RFC 2821. How will
them breaking the rules twice make it better?

it's sort of missing the point anyway. mail and web aren't the only apps
affected by this. this breaks anything that assumes (quite reasonably)
that query to a a nonexistent domain will return NXDOMAIN.

this does point out something about our standards - they're written assuming
that people want to interoperate and that they're acting in good faith.
while they might try to prohibit harmful behavior that might occur by
accident, they weren't written to dictate the actions of potentially hostile
parties (and I do regard VeriSign as hostile)

[Dean Anderson]

Post by Keith Moore
this breaks anything that assumes (quite reasonably)
that query to a a nonexistent domain will return NXDOMAIN.

That an invalid assumption to make. It was not made "quite reasonably",
but rather was made quite irrationally. In many or most cases, it was made
willfully, knowing and having been warned that such assumptions were
invalid.

I have little sympathy for the claims that this was somehow disruptive.
The people making these assumptions have known about and had been told of
the invalidity of those assumptions for many years. They didn't just learn
of this on Monday. They were warned well in advance. All that happened on
Monday was that the hammer finally fell making those assumptions
operationally untenable.

Post by Keith Moore
this does point out something about our standards - they're written
assuming that people want to interoperate and that they're acting in
good faith. while they might try to prohibit harmful behavior that might
occur by accident, they weren't written to dictate the actions of
potentially hostile parties (and I do regard VeriSign as hostile)

This is also unreasonable. Verisign is not hostile.

--Dean

[bill]

After all two wrongs don't make a right,
But two Wrights make an airplane

In honour of the 100 year aniversary

Bill

-----Original Message-----
From: owner-***@ietf.org [mailto:owner-***@ietf.org] On Behalf Of Paul
Hoffman / IMC
Sent: Thursday, September 18, 2003 9:22 AM
To: ***@ietf.org
Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To
Us]

=> IMHO it should reject SMTP connection from the beginning with the
521 greeting described in RFC 1846...

People are unhappy about VeriSign breaking the rules. But here you
are proposing that they follow an *experimental* RFC whose rules were
not accepted into the later revision of SMTP in RFC 2821. How will
them breaking the rules twice make it better?

--Paul Hoffman, Director
--Internet Mail Consortium

[Paul Vixie]

Post by James M Galvin
It is worth noting that if we are to "pass judgement against" Verisign
there are at least half-dozen other TLDs that blazed the trail. We just
overlooked them because of their size as compared to .NET and .COM.

when people started beating on my phone ringer about wildcards yesterday
evening, and screaming for patches to bind to somehow make it all better,
i asked "but other tld's do this, what's the big deal?" as near as i can
figure it, the problem is one of expectation. if someone signs up for .nu
they know there'll be a wildcard there before they sign, and they can take
appropriate precautions (like only using it for web or e-mail, and not
naming hosts under that tld). the expectations for .com and .net to not
have wildcards were all set many years ago, and it's the violation of those
expectations that's got people angry enough to publish patchware about it.

[Keith Moore]

interesting point. if we created a new gTLD and announced that it would be
wildcarded from day one, it wouldn't be used in the same way as the other
gTLDs.

then again, do we really want different ways of reporting errors for
different zones in the DNS? would apps then want to special-case
certain zones to interpret their results differently than the others?

Keith

Post by Paul Vixie
when people started beating on my phone ringer about wildcards yesterday
evening, and screaming for patches to bind to somehow make it all better,
i asked "but other tld's do this, what's the big deal?" as near as i can
figure it, the problem is one of expectation. if someone signs up for .nu
they know there'll be a wildcard there before they sign, and they can take
appropriate precautions (like only using it for web or e-mail, and not
naming hosts under that tld). the expectations for .com and .net to not
have wildcards were all set many years ago, and it's the violation of those
expectations that's got people angry enough to publish patchware about it.

[V***@vt.edu]

Post by Keith Moore
then again, do we really want different ways of reporting errors for
different zones in the DNS? would apps then want to special-case
certain zones to interpret their results differently than the others?

Blech.

If it's Tuesday, this must be .belgium?

A non-starter. *MAYBE* if it were a different RR with different semantics.

[Bill Manning]

% On Wed, 17 Sep 2003 00:00:14 EDT, Keith Moore said:
%
% > then again, do we really want different ways of reporting errors for
% > different zones in the DNS? would apps then want to special-case
% > certain zones to interpret their results differently than the others?
%
% Blech.
%
% If it's Tuesday, this must be .belgium?
%
% A non-starter. *MAYBE* if it were a different RR with different semantics.
%

This may be exactly what we get w/ a patch from ISC.
If BIND is offically tweeked so that some zone cuts are
allowed to exercise legal protocol options while others
are not... changes based on "mob" rule... not good.

BIND begins to lose its reputation as a reference
implementation of open standards.

Ick.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

[bill]

I've just got to ask... I am seeing news that BIND WILL BE patched with
this kind of support in it.

Is this a sponsored patch, or is it just a random person posting a patch
- that if applied would have this functionality

Bill

-----Original Message-----
From: owner-***@ietf.org [mailto:owner-***@ietf.org] On Behalf Of Paul
Vixie
Sent: Tuesday, September 16, 2003 7:33 PM
To: ***@ietf.org
Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To
Us]

Post by James M Galvin
It is worth noting that if we are to "pass judgement against" Verisign
there are at least half-dozen other TLDs that blazed the trail. We
just overlooked them because of their size as compared to .NET and
.COM.

when people started beating on my phone ringer about wildcards yesterday
evening, and screaming for patches to bind to somehow make it all
better, i asked "but other tld's do this, what's the big deal?" as near
as i can figure it, the problem is one of expectation. if someone signs
up for .nu they know there'll be a wildcard there before they sign, and
they can take appropriate precautions (like only using it for web or
e-mail, and not naming hosts under that tld). the expectations for .com
and .net to not have wildcards were all set many years ago, and it's the
violation of those expectations that's got people angry enough to
publish patchware about it.

[Carl Malamud]

Hi -

http://www.isc.org/products/BIND/delegation-only.html

Carl

Post by bill
I've just got to ask... I am seeing news that BIND WILL BE patched with
this kind of support in it.
Is this a sponsored patch, or is it just a random person posting a patch
- that if applied would have this functionality
Bill
-----Original Message-----
Vixie
Sent: Tuesday, September 16, 2003 7:33 PM
Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To
Us]

Post by James M Galvin
It is worth noting that if we are to "pass judgement against" Verisign
there are at least half-dozen other TLDs that blazed the trail. We
just overlooked them because of their size as compared to .NET and
.COM.

when people started beating on my phone ringer about wildcards yesterday
evening, and screaming for patches to bind to somehow make it all
better, i asked "but other tld's do this, what's the big deal?" as near
as i can figure it, the problem is one of expectation. if someone signs
up for .nu they know there'll be a wildcard there before they sign, and
they can take appropriate precautions (like only using it for web or
e-mail, and not naming hosts under that tld). the expectations for .com
and .net to not have wildcards were all set many years ago, and it's the
violation of those expectations that's got people angry enough to
publish patchware about it.
--
Paul Vixie

[Masataka Ohta]

Carl;

Post by Carl Malamud
http://www.isc.org/products/BIND/delegation-only.html

As I just post to DNSOP WG ML (detailed discussion should be done
there), it is not an effective protection against synthesised (from
wildcared NS, in this case) NS and synthesised (from scratch) child
zone contents.

A protection is to reject NS answers, if it is identical to wildcarded
one, though it has several side effects.

Masataka Ohta

[V***@vt.edu]

Post by Keith Moore
verisign is masking the difference between a valid domain and NXDOMAIN for
all protocols, all users, and all software.

Out of curiosity, where did Verisign get the right to have the advertising monopoly
for all the eyeballs they'll attract with this?

[Anthony Atkielski]

Post by V***@vt.edu
Out of curiosity, where did Verisign get the right
to have the advertising monopoly for all the eyeballs
they'll attract with this?

They didn't.

And there's even a way for individuals to stop it: Type an incorrect
spelling for a famous trademark. When Verisign puts up its own page for the
nonexistent domain, copy it and send it to the trademark owner, asking if he
intends to defend his trademark, or if he is releasing it to the public
domain. In the former case, he'll have to take action against Verisign.
The latter case is unlikely unless he truly doesn't want the trademark,
because undefended trademarks are easily diluted and slip rapidly into the
public domain. After Verisign has a few thousand lawsuits on its hands, it
will change its policy.

[grenville armitage]

Post by Dean Anderson
Is it any worse than IE taking you to msn search when a domain doesn't
resolve?

Look on the bright side - everything now resolves.

cheers,
gja

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Dean> Is it any worse than IE taking you to msn search when a domain
Dean> doesn't
Dean> resolve? Or worse than Mozilla taking you to Netscape, duplicating a
Dean> Google search, and opening a sidebar (and a netscape search) you
Dean> didn't
Dean> want?

Dean> I think it isn't.

I think that it is.
I can:
a) replace IE
b) replace Netscape
c) not run them on my mail server.

This change is unilateral.

Personally, I am considering not renewing any .com or .net that I have.

] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [

[Zefram]

Today VeriSign is adding a wildcard A record to the .com and .net
zones.

This is, as already noted, very dangerous. We in the IETF must work to
put a stop to this attempt to turn the DNS into a directory service,
and quickly. I suggest the following courses of action, to be taken
in parallel and immediately:

0. Urgently publish an RFC ("Wildcards in GTLDs Considered Harmful", or
"DNS Is Not A Directory") to provide a clear statement of the problem
and to unambiguously prohibit the practice.

1. Via ICANN, instruct Verisign to remove the wildcard.

2. Some of us with sufficiently studly facilities should mirror the COM
and NET zones, filtering out the wildcards. Then the root zone can
be modified to point at these filtered COM and NET nameservers.

3. Instruct ICANN to seek another organisation to permanently take over
COM and NET registry services, in the event that Verisign do not
comply with instructions to remove the wildcard.

I believe that the direct action I suggest in point 2 is necessary,
because we have previously seen the failure of the proper channels in
this matter, when Verisign added a wildcard for non-ASCII domain names.
Verisign have shown a disregard for the technical requirements of their
job, as well as displaying gross technical incompetence (particularly
in the wildcard SMTP server). I believe Verisign have forfeit any moral
right to a grace period in which to rectify the situation.

-zefram

[Florian Weimer]

Post by Zefram
1. Via ICANN, instruct Verisign to remove the wildcard.

By the way, what about .museum?

[Paul Vixie]

Post by Florian Weimer
By the way, what about .museum?

.museum does not delegate all of its subdomains.

not all tld's are delegation-only.

[Florian Weimer]

Post by Paul Vixie

Post by Florian Weimer
By the way, what about .museum?

.museum does not delegate all of its subdomains.
not all tld's are delegation-only.

I know. I have to admit that (as someone who grew up under .de) I
would never have thought of the delegation-only approach. 8-)

[Karl Auerbach]

... I suggest the following courses of action, to be taken
1. Via ICANN, instruct Verisign to remove the wildcard.

It isn't clear that this power is vested in ICANN. There is a complicated
arrangement of Cooperative Agreements, MOUs, CRADAs, and Purchase Orders
that exist between various agencies of the US Department of Commerce
(including NTIA, NIST, and others) and ICANN and Verisign/NSI.

This web of agreements is sufficiently complicated that often really isn't
exactly clear who can compel Verisign/NSI on any particular point. In
fact it may well be that the power may not exist. Or it may take a lot of
legal dollars and time to press the issue.

To make the situation even less clear, there is, I believe, no statement
in the relevant Internet Standards docucuments that clearly rules out this
kind of wildcarding. (Yes, I think we can all agree that this particular
use of wildcarding *is* a bad thing, I'm simply pointing out that to those
who are not technically grounded in DNS matters, that without a clear
prohibition in the Internet Standards, the matter isn't so obvious.)

By-the-way, Neulevel (.us and .biz) did an "experiment" along these lines
back in May of this year. It was short lived. At the time I thought it
was a bad thing, and I still do. And at the time I wrote and sent to the
ICANN board an evaluation of the risks of that "experiment."

--karl--

[Iljitsch van Beijnum]

On dinsdag, sep 16, 2003, at 12:25 Europe/Amsterdam, Karl Auerbach

Post by Karl Auerbach

Post by Zefram
1. Via ICANN, instruct Verisign to remove the wildcard.

It isn't clear that this power is vested in ICANN. There is a
complicated
arrangement of Cooperative Agreements, MOUs, CRADAs, and Purchase Orders
that exist between various agencies of the US Department of Commerce
(including NTIA, NIST, and others) and ICANN and Verisign/NSI.
This web of agreements is sufficiently complicated that often really isn't
exactly clear who can compel Verisign/NSI on any particular point. In
fact it may well be that the power may not exist. Or it may take a lot of
legal dollars and time to press the issue.

I think the ICANN has no choice and has to show its teeth here, or just
roll over and die because there no longer is a reason for its existence.

On a related note: so far I have never bothered to move my domains to a
competing registrar before, but now seems a good time to do it. Can
anyone recommend a procedure for select a good quality registrar?
(Off-list if this is more appropriate.)

[Kurt Erik Lindqvist]

Post by Karl Auerbach
By-the-way, Neulevel (.us and .biz) did an "experiment" along these lines
back in May of this year. It was short lived. At the time I thought it
was a bad thing, and I still do. And at the time I wrote and sent to the
ICANN board an evaluation of the risks of that "experiment."

.nu have been doing this for a long time AFAIK.

- kurtis -

[Gene Gaines]

Forwarded with Vittorio Bertola's permission.

I received a similar response from Izumi Aizu.

Gene Gaines
***@gainesgroup.com
Sterling, Virginia USA


This is a forwarded message
From: Vittorio Bertola <***@bertola.eu.org>
To: Gene Gaines <***@gainesgroup.com>
Date: Tuesday, September 16, 2003, 9:17:46 AM
Subject: Verisign attempt to "take" all unpaid addresses
=================Original message text===============

Hello,

we've been working on this since the first rumours started to come up, see
http://forum.icann.org/mail-archive/alac/msg00385.html and following thread.
We will release a statement shortly.

Thanks for your support :-)

Regards,

I have a request of you, and I politely request individual answers
from each of you.
There are many many emails denouncing the new move by VeriSign
to hijack all unregistered addresses in the spaces they manage.
All unregistered domains in .com and .net now resolve to
64.94.110.11, a Verisign-operated web search engine on port 80
which reports advertiser-paid results.
If ICANN will not move immediately and aggressively here,
then it is a clear sign that organization is of no value,
and is in fact what ICANN is what Karl Auerbach has long
suspected the organization to be.
I ask that you immediately and publicly denounce this move
by VeriSign.
I ask that you issue statements both as an individual and as
a member of ICANN. If you do not issue such statements, I
intend publicize widely your failure to do so.
It is time for you to take a stand. Either you support the
Internet as it exists today, are you elect to be part of
the interests that are moving to destroy it.
I would like to know.
Gene Gaines
Sterling, Virginia USA
[phone]

Post by Zefram

Today VeriSign is adding a wildcard A record to the .com and .net
zones.

This is, as already noted, very dangerous. We in the IETF must work to
put a stop to this attempt to turn the DNS into a directory service,
and quickly. I suggest the following courses of action, to be taken
0. Urgently publish an RFC ("Wildcards in GTLDs Considered Harmful", or
"DNS Is Not A Directory") to provide a clear statement of the problem
and to unambiguously prohibit the practice.
1. Via ICANN, instruct Verisign to remove the wildcard.
2. Some of us with sufficiently studly facilities should mirror the COM
and NET zones, filtering out the wildcards. Then the root zone can
be modified to point at these filtered COM and NET nameservers.
3. Instruct ICANN to seek another organisation to permanently take over
COM and NET registry services, in the event that Verisign do not
comply with instructions to remove the wildcard.
I believe that the direct action I suggest in point 2 is necessary,
because we have previously seen the failure of the proper channels in
this matter, when Verisign added a wildcard for non-ASCII domain names.
Verisign have shown a disregard for the technical requirements of their
job, as well as displaying gross technical incompetence (particularly
in the wildcard SMTP server). I believe Verisign have forfeit any moral
right to a grace period in which to rectify the situation.
-zefram

--
vb. [Vittorio Bertola - v.bertola [a] bertola.eu.org]<------
--------> http://bertola.eu.org/ - Archivio FAQ e molto altro... <--------


==============End of original message text===========

[Gene Gaines]

This is a forwarded message
From: Vittorio Bertola <***@bertola.eu.org>
To: Gene Gaines <***@gainesgroup.com>
Date: Tuesday, September 16, 2003, 2:06:02 PM
Subject: Verisign attempt to "take" all unpaid addresses
=================Original message text===============

=====
The At-Large Advisory Committee would like to bring to ICANN's
attention concerns about Verisign's surprising roll-out of the
"SiteFinder" service for .com and .net.

SiteFinder works by re-directing queries for non-existing domain
names to the IP address of a search service that is being run by
Verisign.

This practice raises grave technical concerns, as it de facto
removes error diagnostics from the DNS protocol, and replaces them
by an error handling method that is tailored for HTTP, which is just
one of the many Internet protocols that make use of the DNS. We will
leave it for others to explain the details of these concerns, but
note that returning resource records in a way which is countrary to
the very design of the DNS certainly does not promote the stability
of the Internet.

These concerns are not mitigated by Verisign's efforts to work
around the consequences of breaking the Internet's design on a
service-by-service basis: These workarounds make specific
assumptions on the conclusions that Internet software would be
drawing from nonexisting domain names; these assumptions are not
always appropriate.

When working as intended, the service centralizes error handling
decisions at the registry that are rightly made in application
software run on users' computers. Users are deprived of the
opportunity to chose those error handling strategies best suited for
their needs, by chosing appropriate products available on a
competitive marketplace. Software makers are deprived of the
opportunity to compete by developing innovative tools that best
match the user's needs.

We urge ICANN to take whatever steps are necessary to stop this
"service."

[Bill Sommerfeld]

Post by James M Galvin
If you read the Verisign documentation (which is quite excellent by the
way) on what they did and what they recommend you will see that they
thought about this.

I stopped reading the PDF when I saw the "Verisign Proprietary"
labels.

Post by James M Galvin
DNS NXDOMAIN or SMTP 550.

Semantically they're not equivalent, particularly for the targets of
an MX.

Post by James M Galvin
Would have been nice to get
some advance notice

"would have been nice" doesn't even get close.

IMHO it was irresponsible of them to do this without several months
advance notice to allow authors of automated systems which depended on
NXDOMAIN queries to notice this and without a stable documented way to
reconstitute the NXDOMAIN they're suppressing.

- Bill

[James M Galvin]

On Tue, 16 Sep 2003, Bill Sommerfeld wrote:

IMHO it was irresponsible of them to do this without several months
advance notice to allow authors of automated systems which depended
on NXDOMAIN queries to notice this and without a stable documented
way to reconstitute the NXDOMAIN they're suppressing.

Agreed although some might argue we had several months notice, albeit
quietly. Verisign was far from being first at this. It's just that
their size/scope made us all notice.

Jim

[Keith Moore]

Post by Bill Sommerfeld
IMHO it was irresponsible of them to do this without several months
advance notice to allow authors of automated systems which depended on
NXDOMAIN queries to notice this and without a stable documented way to
reconstitute the NXDOMAIN they're suppressing.

IMHO it would be irresponsible to do this under any circumstances.

[Vernon Schryver]

Post by V***@vt.edu
Out of curiosity, where did Verisign get the right to have the advertising monopoly
for all the eyeballs they'll attract with this?

What eyeballs? I doubt I'm among the first 1,000,000 people to adjust
junk pop-op or other defenses to treat sitefinder.verisign.com and
64.94.110.0/24 like any other noxious web site. If AOL and a lot of
other outfits haven't adjusted their proxies within a few hours, I'll
be surprised.

If AOL and Microsoft don't immediately make releases of IE and Netscape
that treat 64.94.110.11 the same as they treated an NXDOMAIN (and
included an update mechanism), it will only be because Verisign has
given up or they're gettting piece of Verisign's action.


Vernon Schryver ***@rhyolite.com

[Bruce Campbell]

Post by Vernon Schryver
If AOL and Microsoft don't immediately make releases of IE and Netscape
that treat 64.94.110.11 the same as they treated an NXDOMAIN (and

Semantically, you'd want to treat 'arbitarynonexistentdomain.com' as
NXDOMAIN if the 'A' record matches the 'A' record on '*.com'. Hardcoding
arbitary[1] IP addresses into programs is bad.

--==--
Bruce.

[1] Yes yes, lots of people have hard-coded RFC-mentioned addresses into
code.

[Sabharwal, Atul]

Are there just a couple of DNS server(s) per ISP? Do they run VPN's to
sync up with the central DNS servers so that DNS spoofing is limited &
DNS synchronization encrypted?

Should be an easy solution for DNS spoofing except for public IP
addresses which home users get. Again, they would be registered, so
spoofing them would be difficult?

--
Atul

P.S: The opinions are my opinion and my responsibility.

-----Original Message-----
From: Edward Lewis [mailto:***@arin.net]
Sent: Tuesday, September 16, 2003 11:19 AM
To: ***@ietf.org
Cc: Edward Lewis
Subject: Re: [Fwd: [Asrg] Verisign: All Your ...

Post by Keith Moore
I strongly disagree. The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an entry
in the DNS. Making existence of a domain depend on a separate
registry makes no sense and is inconsistent with longstanding practice.

DNS is the ultimate authority on whether there is an DNS answer to a
DNS query, but that's about it. What a DNS server answers is based
on what is in the registry it represents.

To quote what I wrote on the provreg list in
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00164.html:

"DNS names [...] are limited to 255 octets, which is about 2K bits,
and 2^2k possibilities minus special cases. Boom - all names exist."

The point is, before saying that DNS makes any statement about
"existence" you need to define "exists for what purpose." In the
message above, it was "exists so that I can't register it." In the
wcard clarify draft in DNSEXT, it's "exists for the purposes of
ruling out synthesis of the answer."

Post by Keith Moore
that's not the same thing at all. DNS is not the authority for whether
a device is connected to the net. DNS is the authority on whether a

DNS

Post by Keith Moore
name exists.

In engineering the DNS, "com." has been and still is a peculiar case
and there has been the temptation to tailor the DNS protocol to
accommodate it. The community has said time and again not to do so -
not to treat that zone (and the others growing like it) as special
cases. I think turnabout is fair play - that we not restrict "com."
and the others from using what's in DNS protocol.

I'm neither endorsing nor criticizing what has been added to "com."
and "net." Let's just be fair, accurate, and on-topic (like,
protocols) in the discussion.

[Peter Sylvester]

Post by Bill Manning
ok, what about DoC & ICANN agreements w/ VSGN giving them
the authority to continue to register in and publish
the .COM and .NET domains? That looks like an entitlment to me.

Hm, to me publishing all registered entities of a domain
is not the same as publishing that the domain contains everything.

[Dean Anderson]

Post by Bill Manning
ok, what about DoC & ICANN agreements w/ VSGN giving them
the authority to continue to register in and publish
the .COM and .NET domains? That looks like an entitlment to me.

Think it from a set theory perspective for a second. They have been
given the contract to populate a set (*registered* domains in COM. and
NET.) and publish that set (through DNS, ftp-able zone files, whois,
phone calls and so on). For this publication method, this behavior
eliminates the ability to determine whether the item is in or out of the

DNS, Zone files, etc, are not acceptable means to query the set.

1) The different publication methods are out of synch.

DNS is always out of sync with the set. It comes close twice per day. But
even then it is out of sync probably before the zone transfers are
complete. This is why there is only one method (whois) that is acceptable
to query the set.

2) Those parts of the application infrastructure of the Internet which
have protocol processing choices depending on that set membership
response will get the protocol processing wrong.

They were wrong to begin with. They shouldn't be depending on this
behavior. We've told those people that for a long time. We even discussed
removing reverse DNS from IPv6, just because of the substantial damages
caused by this incorrect use.

--Dean

[Dean Anderson]

Post by Dean Anderson
No, that isn't correct. If you want to purchase a domain, you have to
check the registry database via whois.

Why? As you yourself said: "It is in fact reporting that the domain is available
for purchase".

Yes, by pointing you to a netsol server that says so. It is the servers'
web content that says this, not the fact that the wildcard exists. You
cannot use DNS to perform this check.

If there's a nameserver for the domain, and there's an active
mail host for the domain, that indicates an *IN USE* domain, as far as anybody
can tell *ON THE SMTP PORT*.

But you don't look at the SMTP port to find out of the domain is
available. No one has ever used DNS or SMTP to check on whether a domain
is purchasable. This is sophistry.

The people most "disrupted" are those that were misusing reverse DNS.
Now that reverse DNS matches on unused domains, their invalid assumptions
have lost completely whatever operational usefulness they were wrongly
perceived to have once had. But they were invalid previously. So nothing
has been broken.

--Dean

[V***@vt.edu]

Post by Dean Anderson
But you don't look at the SMTP port to find out of the domain is
available. No one has ever used DNS or SMTP to check on whether a domain
is purchasable. This is sophistry.

Oh.. so if you're not actually on port 80, but on any one of the OTHER 65,364

Post by Dean Anderson
You have yet explain how is it misreporting anything. It in fact
reporting that the domain is available for purchase. How is that
misreporting?

It's reporting it's available on port 80, and EVERY OTHER SERVICE can
go take a flying leap.

Internet != HTTP.

[V***@vt.edu]

If you send to more than one recipient, you still only transfer one
message. You've been listening to too many open relay crackpots, instead
of checking into how SMTP works.
When the same message is sent to multiple recipients the SMTP
encourages the transmission of only one copy of the data for all the
recipients at the same destination host.
I don't know of any MTA that doesn't do this.

Right. The point is that the Verisign SMTP responds with a fixed series of
reply codes (220, 250, 250, 550, 221). So let's run that with 3 recipients:

220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
MAIL FROM..
250 OK
RCPT TO...
250 OK
RCPT TO...
550 User domain does not exist.
RCPT TO...
250 OK
DATA
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
<Connection closed by foreign host.>

Now what do you do, absent a 3xx reply to your DATA command?