Subject: RE: [Fwd: [Asrg] Verisign: All Your ...

From: "Sabharwal, Atul" <[email-masked]>
Date: Tue, 16 Sep 2003 14:16:57 -0700

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:[email-masked]] 
Sent: Tuesday, September 16, 2003 11:19 AM
To: [email-masked]
Cc: Edward Lewis
Subject: Re: [Fwd: [Asrg] Verisign: All Your ...

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 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."

>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.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 18 Sep 2003 18:11:02 +0200 (MEST)

> 
> 	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.

---

From: John C Klensin <[email-masked]>
Date: Sat, 20 Sep 2003 16:08:38 -0400

--On Saturday, 20 September, 2003 11:02 -0600 Doug Royer 
<[email-masked]> wrote:

> Dean Anderson wrote:

>> RFC 2821 (proposed standard) sheds some light on that: (This
>> isn't a replacement to STD0010, but reveals the disagreement
>> on the roles of MTAs and MUAs)
>>
> Your quote talks about conventions that may be used. It does
> not support your view
> that the MUA and MTA have to be separate pieces of code. And
> what your ISP does
> for your does not have to be what other ISPs do for their
> customers.
>
>> 2.3.3 Mail Agents and Message Stores
>>
>>   Additional mail system terminology became common after RFC
>>   821 was published and, where convenient, is used in this
>>   specification. ....

Sigh.  I had hoped to just avoid this discussion, but...  There 
is no disagreement at all, certainly no intentional 
disagreement, between 821 and 2821 on this point other than on 
matters of terminology.  That is exactly what 2.3.3 is intended 
to say: new terminology has come into use, and 2821 was, to the 
degree it was reasonable, aligned to that terminology.  821 
talks about "SMTP Senders" and "SMTP Receivers" and not about 
MUAs and MTAs, mostly because those latter terms weren't common 
yet.  And 2821 was mostly shifted to talk about "SMTP Client" 
and "SMTP Servers" in preference to "SMTP Senders" and "SMTP 
Receivers", again, to match contemporary usage -- although there 
are some situations in which the old terminology was retained 
because the client/server version wasn't clear enough.  Frankly, 
I often regret making that change, since it seems to lead to 
discussions like this one.

There is now, nor has there ever been, any requirement that MUAs 
and MTAs be on separate machines or under separate 
administration (or even separate software modules).  Some of the 
language in 2821 was written to make it clear that having a 
local, low-capability, MTA (SMTP client) send all of its mail to 
a higher capability server (acting as an SMTP Receiver to 
collect that mail and then as an SMTP Sender to push it out) 
rather than handling, e.g., general name resolution and queuing 
itself.

But the text was fairly carefully written to not prefer one of 
the following cases over the other:

	(i) SMTP Sender on the originating machine (the one that
	houses the MUA, or an SMTP Sender that is part of the
	same code module as the MUA) does all processing,
	sending mail to target destinations as listed in RCPT
	commands, and queuing and retrying if needed.
	
	(ii) SMTP Sender on the originating machine sends all
	traffic, via SMTP, to a mail relay that takes care of
	processing, distribution to individual recipients, and
	queuing.  In this case, the destination to which the
	SMTP Sender delivers the mail is a function of
	configuration, not of the addresses in the RCPT commands.
	
	(iii) SMTP Sender on the originating machine examines
	the RCPT commands and tries to send the mail out
	directly, using MX resolution, etc.  If it cannot
	successfully establish a connection and deliver the mail
	on the first try, it forwards it to a pre-configured
	relay, as in (ii).
	
	(iv) The originating MUA, and associated code, hands the
	message off to an MTA for further processing using some
	non-SMTP means.  That means could be RFC 2746 SUBMIT or
	virtually anything else (even some batch process running
	over a non-TCP network).  2821 is quite deliberately
	agnostic (as was 821) about how the message reaches the
	first-hop MTA (SMTP Sender).

If the text of 2821 is not clear on that subject, suggestions of 
specific improved text would be welcomed.

    john

---

From: "Laird, James" <[email-masked]>
Date: Tue, 23 Sep 2003 12:15:46 +1000

Dean Anderson wrote:
>Clearly, DNS doesn't indicate anything about whether a domain is
>registered, as you demonstrate.

DNS indicates whether there is a server serving that domain. Verisign broke
that quite effectively.

>However, we know that the registration will eventually be reflected in
>DNS. The reverse does not happen.

There is no requirement for me ever to delegate my domain. It need not ever
be reflected in DNS.

--James

Disclaimer: Whilst every attempt has been made to ensure that material
contained in this email is free from computer viruses or other defects, the
attached files are provided, and may only be used, on the basis that the
user assumes all par responsibility for the use of the material transmitted.
The email is intended only for the use of the individual or entity named
above and may contain information, distribution or copying that is
confidential and privileged. If you are not the intended recipient please
note that any dissemination, distribution or copying of this email is
strictly prohibited. If you have received this email in error, please notify
us immediately by return email and destroy the original message.

---

From: "Laird, James" <[email-masked]>
Date: Wed, 24 Sep 2003 14:59:02 +1000

Dean wrote:
>Specifically, you insist that DNS queries, via DNS _protocol_
>can be used to check if a domain exists.

You are pointedly ignoring the fact that there are two "planes of
existence". There is the "conceptual" plane - the registry records, saying
you have control over the name. Then there is the "concrete" plane - the DNS
records, saying which servers belong to which domains. Domains have to EXIST
in DNS to be useful. We don't give a flying rat's rear end about whether the
domain has been registered with a registrar.

Really, all you're doing is twisting the discussion away from the topic.

--James

---

From: Dean Anderson <[email-masked]>
Date: Wed, 24 Sep 2003 02:55:20 -0400 (EDT)

Ok, one last message. This removes some apparent confusion between
"reverse DNS abuse" and the current Verisign complaints.

The people who have "problems with Verisign" expect to do a forward lookup
on a domain name, and if they don't get NXDOMAIN, they want to do a
reverse lookup on the address, and if they match, they assume that the
sender is not a spammer.  This is known as reverse DNS abuse, or reverse
DNS test.  Of course, it never worked. But people believe with religious
fervor that it does.

These people are upset because now the unregistered .com and .net domains
don't return NXDOMAIN, but give the address of Verisign. The next step in
their "test" will check the reverse address of Verisign, and find it to
match.  Thus, they are upset that their "test" doesn't work.  It didn't
work to begin with.

The premises on which this "test" was based, are false, and have always
been false. The DNS working groups have discussed the issue, and have
considered removing Reverse DNS because of these abuses due to a long and
well documented history of harms due to this abuse, and the comparatively
small positive value of Reverse DNS in proper usage.  IPv6 has host
identification facilities which replace Reverse DNS.  I think that Reverse
is presently broken in IPv6 due to recent changes in IPv6 work.  I forget
if it has been fixed.  It seems likely that IPv6 won't have reverse DNS,
so if we ever get it deployed, the problem will go away.

But, obviously, you are unfamiliar with the history of the problem, which
is why you don't recognize the "reverse DNS abuse" and what the term
signifies.  I should have realized that earlier.

		--Dean

On Wed, 24 Sep 2003, Laird, James wrote:

> Dean wrote:
> >It is you who is struggling in vain. You and the rest of the reverse DNS
> >abusers are confused.
>
> REVERSE DNS? Abusers? Give me a break.
>
> Looking up an IP (or getting an NXDOMAIN) from a domain name is FORWARD dns.
> Where's the reverse? (Where's the abuse?)

---

From: "Laird, James" <[email-masked]>
Date: Wed, 24 Sep 2003 17:32:54 +1000

Sorry, this is actually WRONG.

Dean wrote:
>match.

--snip--

nslookup
>www.thisdomaindoesnotexist.com

Name:    www.thisdomaindoesnotexist.com
Address:  64.94.110.11

>64.94.110.11

Address:  64.94.110.11
Name:    sitefinder-idn.verisign.com

--snip--

So you're saying that reverse DNS programs will match
www.thisdomaindoesnotexist.com with sitefinder-idn.verisign.com?

Hopeless.

--James