Mea culpa, sorry.
[EMAIL PROTECTED] wrote:
On Tue, 16 Sep 2003 01:27:09 EDT, Yakov Shafranovich said:
The SMTP server is fake, take a look at this transaction:
Actually, that was my point.
Adam Roach;
Because this is probably a community of interest for the
topic of DNS, I thought it would be worthwhile mentioning
that Verisign has apparently unilaterally put in place
wildcard DNS records for *.com and *.net. All unregistered
domains in .com and .net now resolve to
Because noone can stop them doing it, apparently...
On Tue, Sep 16, 2003 at 12:43:35AM -0400, Keith Moore wrote:
so now verisign is deliberately misrepresenting DNS results.
why are these people allowed to live?
Adam Roach [EMAIL PROTECTED] writes:
Because this is probably a community of interest for the
topic of DNS, I thought it would be worthwhile mentioning
that Verisign has apparently unilaterally put in place
wildcard DNS records for *.com and *.net. All unregistered
domains in .com and .net
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
Zefram [EMAIL PROTECTED] writes:
1. Via ICANN, instruct Verisign to remove the wildcard.
By the way, what about .museum?
On Tue, 16 Sep 2003, Zefram wrote:
... I suggest the following courses of action, to be taken
in parallel and immediately:
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
On dinsdag, sep 16, 2003, at 12:25 Europe/Amsterdam, Karl Auerbach
wrote:
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
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
Randall,
RRSh Now of course if the application wants to be aware, it can subscribe to
RRSh events that let it know that it happened.
That sounds remarkably like a presence service.
RRSh No, what it is is a socket call you make that subscribes do address
RRSh events on the socket.
oh. ok. I
Now of course if the application wants to be aware, it can
subscribe to events that let it know that it happened.
That sounds remarkably like a presence service.
No, what it is is a socket call you make that subscribes do address
events on the socket. Thus when a peer adds and
Yakov,
there is a currently rather quiet list - [EMAIL PROTECTED] - which was
supposed to discuss, among other things, software tools to support WG
activities.
You might want to ask your question there.
I've heard of people using various sorts of document repositories,
including CVS and
Forwarding from the ASRG list, more anti-spam tools being broken by
Verisign.
Original Message
Subject: [Asrg] 7. Best Practices - Service Providers MTA Authors
(was: Fwd: Verisign's New Change and Outdate RBL's)
Date: Tue, 16 Sep 2003 11:43:03 +0200
From: Brad Knowles [EMAIL
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,
Dean Anderson wrote:
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
Pekka Nikander wrote:
vinton g. cerf wrote:
We would also want to look very carefully at the potential spoofing
opportunity that rebinding would likely introduce.
Randall R. Stewart (home) wrote:
This is one of the reasons the authors of ADD-IP have NOT pushed to
get it done.. some more
work
Randall R. Stewart (home) wrote:
Now as to the applicability in SCTP and ADD-IP...
There is a difference with mobile-ip in that an SCTP association is already
established. Each node CN and MN have connection state. There has
been a 64bit random value exchanged and the ADD-IP which is equivialant
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
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
At 14:18 +0100 9/16/03, Zefram wrote:
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
Forwarded with Vittorio Bertola's permission.
I received a similar response from Izumi Aizu.
Gene Gaines
[EMAIL PROTECTED]
Sterling, Virginia USA
This is a forwarded message
From: Vittorio Bertola [EMAIL PROTECTED]
To:Gene Gaines [EMAIL PROTECTED]
Date: Tuesday, September 16, 2003,
On Tue, 16 Sep 2003, Edward Lewis wrote:
At 14:18 +0100 9/16/03, Zefram wrote:
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
The ORBS lookup is a problem with configuring invalid domains in spam
tools. Someone else could have re-registered orbs.org, and taken control
of your email system.
This is just irresponsible configuration.
--Dean
See, I get feedback from anti-spammers Last night, I got a bunch of
these... Someone in australia is trying to get my address blacklisted by
spamming out emails forging my address. I wonder who that could be?
--Dean
Received: from 61.88.124.155 ([210.124.48.16]) by
On Tue, 16 Sep 2003 09:24:27 EDT, Keith Moore said:
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
Valdis writes:
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
inline
On Tue, 16 Sep 2003, Bruce Campbell wrote:
On Tue, 16 Sep 2003, Edward Lewis wrote:
At 14:18 +0100 9/16/03, Zefram wrote:
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
From: [EMAIL PROTECTED]
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
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
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
Verisign's recent inclusion of wildcard RR's for the .net and .com TLD's
does not violate any standards in the DNS that I can find, although it has
raised some interesting questions with regard to the ethical behavior or
TLD managers.
I think that managers of the TLD's should not be allow to
James M Galvin wrote:
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
Hi David -
An interesting point, but probably one better made to ICANN. Try
[EMAIL PROTECTED] Since its not a standards or protocol issue its probably
not an IETF issue.
Thanks - Mike
At 11:59 9/16/2003, [EMAIL PROTECTED] wrote:
Verisign's recent inclusion of wildcard RR's for the .net
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
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
Yakov
An interesting point, but probably one better made to ICANN. Try
[EMAIL PROTECTED] Since its not a standards or protocol issue its
probably not an IETF issue.
I disagree that this is not a protocol issue, as it certainly affects
operation of protocols. There are probably issues for the DNS
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
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
On Tue, 16 Sep 2003, Bruce Campbell wrote:
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
At 13:12 -0400 9/16/03, Keith Moore wrote:
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
At 11:01 -0400 9/16/03, Dean Anderson wrote in response to Bruce Campbell:
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
Hi Keith -
At 12:56 9/16/2003, Keith Moore wrote:
An interesting point, but
probably one better made to ICANN. Try
[EMAIL PROTECTED] Since its not a standards or protocol issue
its
probably not an IETF issue.
I disagree that this is not a protocol issue, as it certainly
affects
operation of
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.
From: James M Galvin [EMAIL PROTECTED]
...
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
On Tue, 16 Sep 2003 15:19:47 EDT, James M Galvin said:
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
It can be quite reasonable to make wildcard assertions about RRs that
are all within the same administrative domain, but arguably this
condition is not met for the COM or NET zones.
Agreed - but again, unless it breaks the protocol or has an adverse impact
on robustness, (and not just some
Jim writes:
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,
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
At 13:12 -0400 9/16/03, Keith Moore wrote:
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
By the way, what about .museum?
.museum does not delegate all of its subdomains.
not all tld's are delegation-only.
--
Paul Vixie
On Tue, 16 Sep 2003 [EMAIL PROTECTED] wrote:
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
On Tue, 16 Sep 2003, Vernon Schryver wrote:
From: James M Galvin [EMAIL PROTECTED]
...
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
This is a forwarded message
From: Vittorio Bertola [EMAIL PROTECTED]
To:Gene Gaines [EMAIL PROTECTED]
Date: Tuesday, September 16, 2003, 2:06:02 PM
Subject: Verisign attempt to take all unpaid addresses
=Original message text===
=
The At-Large Advisory
I've just submitted an Internet-Draft concerning the wildcard issue.
For those who can't wait for it to appear in the internet-drafts
directory, http://www.fysh.org/~zefram/typo_wcard/.
-zefram
--
Andrew Main (Zefram) [EMAIL PROTECTED]
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
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
Any comment on the attached draft ID?
Abstract
This memo describes actions against broken content of a primary
server of a TLD. Without waiting for an action of some, if any,
central authority, distributed actions TLD server operators and ISPs
can settle the issue, for a short term.
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
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
% 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
% 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
61 matches
Mail list logo
