RE: [sitefinder-tech-discuss] Technical issues encountered by a k12 site

[Jeremy_Powell@sbcss.k12.ca.us]

First off I would like to point out that there are 2 obvious
solutions that would not require Verisign to get involved in
other vendors product implementation decisions:

1) Do not put a wildcard in the .COM and .NET TLD zones
2) Find a way to redirect only web traffic to the site
finder service which is what it was designed for.

I did not write the spam filter software that I use nor
do I have access to the source code to maintain it.  I 
can and will forward your comments to my spam filter
software vendor.  Will Verisign be educating all spam
filter vendors in regards to how to make their spam
filtering software wildcard friendly?

In terms of item (2) your suggestions certainly would fix
the problem as would my original suggestion.  There are
probably individual solutions to all the products and
implementations that expect an NXDOMAIN responses, but

1) Why should every vendor that has implemented a 
reasonable expectation of an NXDOMAIN response into
their software change so that Verisign can launch its
site finder service?
2) Is Verisign willing to commit the resources to
educating software vendors about how to deal with
wildcards?
3) Will Verisign provide a reasonable schedule to
allow software vendors to change their software to
support wildcards?
4) Will Verisign give the Internet community valid
notice of a future wildcard readdition?
5) Why doesn't Verisign participate in the IETF 
standards process to produce an rfc detailing these
issues, wait for its publication, wait for its
widespread adoption, and then add the site finder
service?

Jeremy Powell
	
> -----Original Message-----
> From: Andrew Newton [mailto:anewton@verisignlabs.com]
> Sent: Tuesday, October 07, 2003 7:08 PM
> To: Jeremy Powell
> Cc: sitefinder-tech-discuss@lists.elistx.com
> Subject: Re: [sitefinder-tech-discuss] Technical issues 
> encountered by a
> k12 site
> 
> 
> Jeremy,
> 
> My response is in-line:
> 
> Jeremy_Powell@sbcss.k12.ca.us wrote:
> 
> > 1) Our spam filter utilizes an NXDOMAIN response to recognize
> > non-existent domains and therefore does not allow mail from
> > them.  Some spam is sent this way.  Whois is not an acceptable
> > replacement for this because it is massively inaccurate.
> 
> I agree that nicname/whois is not the correct solution for 
> your problem. 
>   One method this type of check is to compare the result of 
> the forward 
> domain query against the result of a query for the wildcard (e.g. if 
> example.com == *.com).
> 
> > 2) Microsoft name resolution on newer operatin systems goes
> > through the stages of file, DNS, NetBIOS.  For a school district
> > that has implemented a Windows domain that does not exist in DNS
> > and is therefore resolved in the NetBIOS stage, 
> > the wildcard causes resolution of names to cease at the
> > DNS stage because that stage never returns the expected NXDOMAIN.
> > Implementation of a local DNS for the non-existent domain will
> > resolve this.
> 
> There are two solutions for picking a non-existant name for such 
> purposes.  The first is to pick a non-existant name within a domain 
> delegation for which you have control (e.g. if you have been 
> delegated 
> example.com, then use does-not-exist.example.com).  The 
> second solution 
> is to pick a name within the reserved TLD's specified in BCP 32 / RFC 
> 2606.  These TLD's are .example, .test, .invalid, and .localhost.
> 
> -andy
> 
> 
> 


_________________________________________________________________________________

Statement of Confidentiality:  The contents of this e-mail message and any attachments are intended solely for the addressee.  The information may also be confidential and/or legally privileged.  This transmission is sent for the sole purpose of delivery to the intended recipient.  If you have received this transmission in error, any use, reproduction, or dissemination of this transmission is strictly prohibited.  If you are not the intended recipient, please immediately notify the sender by reply e-mail, send a copy to postmaster@sbcss.k12.ca.us and delete this message and its attachments, if any.

E-mail is covered by the Electronic Communications Privacy Act, 18 USC SS 2510-2521 and is legally privileged.  

Date Sent (d/m/yy): 7/10/2003  -  Sender: Jeremy_Powell@sbcss.k12.ca.us