Re: Change to .com/.net behavior

[Paul Vixie]

> > i'm not sure how many people inside verisign, us-DoC, and icann agree
> > that COM and NET are a public trust, or that verisign is just a caretaker.
> 
> If there's a disagreement on this concept, we have *BIGGER* problems than
> just DNS b0rkage.

yes.  i'm sorry, i thought you knew that.  well, come to san diego for usenix
next month and i'll tell you all about it in my invited talk there.

Re: Change to .com/.net behavior

[Paul Vixie]

> How about rewriting all DNS responses to your liking? :-)
> 
> Like if you ask for www.register.com, you would get the A record for
> www.verisign.com ?

done.

#fh:i386# ping -c 1 www.register.com
PING www.register.com (216.21.229.101): 56 data bytes
64 bytes from 216.21.229.101: icmp_seq=0 ttl=234 time=79.703 ms
--- www.register.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 79.703/79.703/79.703/0.000 ms
#fh:i386# echo 65.205.249.60 www.register.com >>/etc/hosts
#fh:i386# ping -c 1 www.register.com
PING www.register.com (65.205.249.60): 56 data bytes
^C
--- www.register.com ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

next?  the point i'm illustrating is, as an end user, i'm in charge of
my own name->address translations.

> Responses for the highest bidder!

that would be an interesting form of symbol democracy, if it scaled to
all end users.  instead we have a relatively nondemocratic namespace.

Re: Change to .com/.net behavior

[Valdis . Kletnieks]

On Wed, 17 Sep 2003 17:55:32 -, Paul Vixie <[EMAIL PROTECTED]>  said:

> i'm not sure how many people inside verisign, us-DoC, and icann agree
> that COM and NET are a public trust, or that verisign is just a caretaker.

If there's a disagreement on this concept, we have *BIGGER* problems than
just DNS b0rkage.


pgp0.pgp
Description: PGP signature

Re: Change to .com/.net behavior

[John Palmer]

It may be unclear who they are supposed to represent, but they 
do the bidding of their funders. I'm going to go out on a limb
here and postulate that their decisions, therefore, are not 
always in the best interests of the Internet Community.


- Original Message - 
From: "David Schwartz" <[EMAIL PROTECTED]>
To: "Paul Vixie" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 14:30
Subject: RE: Change to .com/.net behavior 


> 
> 
> > > > ...  shouldn't they get to decide this for themselves?
> 
> > > Returning NXDOMAIN when a domain does not exist is a basic
> > > requirement.  Failure to do so creates security problems. It is
> > > reasonable to require your customers to fix known breakage that
> > > creates security problems.
> 
> > that sounds pretty thin.  i think you stretched your reasoning too far.
> 
> Feel free to point out the step that's stretching too far. There definitely
> do exist security validation schemes that rely upon domain existence that
> are fooled by Verisign's bogus reply.
> 
> > > VeriSign has a public trust to provide accurate domain
> > > information for the COM and NET zones. They have decided to put their
> > > financial interest in obscuring this information ahead of their public
> > > trust.
> 
> > i'm not sure how many people inside verisign, us-DoC, and icann agree
> > that COM and NET are a public trust, or that verisign is just a caretaker.
> > but, given that this is in some dispute, it again seems that your
> > customers
> > should decide for themselves which side of the dispute they weigh in on.
> 
> Then who does ICANN represent? Doesn't ICANN operate under the authority of
> the DOC? Doesn't Verisign operate pursuant to a contract with ICANN? Aren't
> we all intended third party beneficiaries of those contracts? Is this really
> in dispute?
> 
> > > Microsoft, for example, specifically designed IE to behave in a
> > > particular way when an unregistered domain was entered. Verisigns
> > > wildcard record is explicitly intended to break this detection. The
> > > wildcard only works if software does not treat it as if the domain
> > > wasn't registered even though it is not.
> 
> > then microsoft should act.  and if it matters to you then you should act.
> 
> I would hope that Microsoft would respond with a lawsuit rather than a
> patch. Otherwise, Verisign will respond with a 'technical solution' and
> we'll be in a war with the people we have to trust.
> 
> > but this is not sufficient justification to warrant a demand by
> > you of your
> > customers that they install a patch (what if they don't run bind?) or that
> > they configure delegation-only for particular tld's (which ones
> > and why not
> > others?)
> 
> It really depends upon the specifics of the contractual situation. What if
> one of your customer's customers lets through some spam because Verisign
> broke their validation check? And what if that person is sued? Now, where
> does that leave you, aware of the problem and having not taken actions to
> correct it that you could have taken?
> 
> > > Verisign has created a business out of fooling software through
> > > failure to return a 'no such domain' indication when there is no such
> > > domain, in breach of their public trust. As much as Verisign was
> > > obligated not to do this, others are obligated not to propogate the
> > > breakage. ISPs operate DNS servers for their customers just as
> > > Verisign operates the COM and NET domains for the public.
> 
> > the obligations you're speaking of are much less clear than
> > you're saying.
> 
> Yes, oviously they are much less clear to Verisign. I want to hear from
> IANA how they feel about a.net being pointed to Verisign. Simply put,
> Verisign is telling me that 'a.net' has address '64.90.110.11' and it does
> not.
> 
> DS
> 
> 
> 
> 

Re: Change to .com/.net behavior

[Joe Maimon]

Paul Vixie wrote:

...  shouldn't they get to decide this for themselves?
 



	Verisign has created a business out of fooling software through
failure to return a 'no such domain' indication when there is no such
domain, in breach of their public trust. As much as Verisign was
obligated not to do this, others are obligated not to propogate the
breakage. ISPs operate DNS servers for their customers just as
Verisign operates the COM and NET domains for the public.
   

the obligations you're speaking of are much less clear than you're saying.
 

In my eyes that is the whole issue. I believe that Verisign is holding 
the zones for the public internet and that they do have obligations to 
the public. Verisign does not.

Without the "for the public" justification, there is absolutely no 
moral  ground for IANA,ICANN and Verisign to maintain this three way 
stranglehold on the contents/structure of the DNS system for the entire 
world population.

 

Re: Change to .com/.net behavior

[Ross Wm. Rader]

On 9/17/2003 1:55 PM Paul Vixie noted that:

but this is not sufficient justification to warrant a demand by you of your
customers that they install a patch (what if they don't run bind?) or that
they configure delegation-only for particular tld's (which ones and why not
others?)
I was with you up to this point. Behaviorally speaking, what Dave is 
doing is no different, in my mind, than what Verisign did when they 
rolled out their required upgrade this week. At least Dave's customers 
have the option of applying his "required upgrade" whereas those that 
don't are forced into Verisign's worldview.

It all works both ways - or should at least. This, as you pointed out in 
your "expectations" post is a big part of the "problem" we are trying to 
sort out.

--

   -rwr

RE: Change to .com/.net behavior

[David Schwartz]

> > > ...  shouldn't they get to decide this for themselves?

> > Returning NXDOMAIN when a domain does not exist is a basic
> > requirement.  Failure to do so creates security problems. It is
> > reasonable to require your customers to fix known breakage that
> > creates security problems.

> that sounds pretty thin.  i think you stretched your reasoning too far.

Feel free to point out the step that's stretching too far. There definitely
do exist security validation schemes that rely upon domain existence that
are fooled by Verisign's bogus reply.

> > VeriSign has a public trust to provide accurate domain
> > information for the COM and NET zones. They have decided to put their
> > financial interest in obscuring this information ahead of their public
> > trust.

> i'm not sure how many people inside verisign, us-DoC, and icann agree
> that COM and NET are a public trust, or that verisign is just a caretaker.
> but, given that this is in some dispute, it again seems that your
> customers
> should decide for themselves which side of the dispute they weigh in on.

Then who does ICANN represent? Doesn't ICANN operate under the authority of
the DOC? Doesn't Verisign operate pursuant to a contract with ICANN? Aren't
we all intended third party beneficiaries of those contracts? Is this really
in dispute?

> > Microsoft, for example, specifically designed IE to behave in a
> > particular way when an unregistered domain was entered. Verisigns
> > wildcard record is explicitly intended to break this detection. The
> > wildcard only works if software does not treat it as if the domain
> > wasn't registered even though it is not.

> then microsoft should act.  and if it matters to you then you should act.

I would hope that Microsoft would respond with a lawsuit rather than a
patch. Otherwise, Verisign will respond with a 'technical solution' and
we'll be in a war with the people we have to trust.

> but this is not sufficient justification to warrant a demand by
> you of your
> customers that they install a patch (what if they don't run bind?) or that
> they configure delegation-only for particular tld's (which ones
> and why not
> others?)

It really depends upon the specifics of the contractual situation. What if
one of your customer's customers lets through some spam because Verisign
broke their validation check? And what if that person is sued? Now, where
does that leave you, aware of the problem and having not taken actions to
correct it that you could have taken?

> > Verisign has created a business out of fooling software through
> > failure to return a 'no such domain' indication when there is no such
> > domain, in breach of their public trust. As much as Verisign was
> > obligated not to do this, others are obligated not to propogate the
> > breakage. ISPs operate DNS servers for their customers just as
> > Verisign operates the COM and NET domains for the public.

> the obligations you're speaking of are much less clear than
> you're saying.

Yes, oviously they are much less clear to Verisign. I want to hear from
IANA how they feel about a.net being pointed to Verisign. Simply put,
Verisign is telling me that 'a.net' has address '64.90.110.11' and it does
not.

DS

Re: Change to .com/.net behavior

[John Palmer]

Don't know, but I cannot get to the VSGN wildcard site. DNS is still returning the IP, 
but port 80
is not responding or is very slow. Bet they didn't allocate enough servers to this  
(hehehehe) or 
its being DOS'ed.

- Original Message - 
From: "Sam Hayes Merritt, III" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 13:53
Subject: RE: Change to .com/.net behavior


> 
> 
> 
> On Wed, 17 Sep 2003, David Schwartz wrote:
> 
> > Microsoft, for example, specifically designed IE to behave in a
> > particular way when an unregistered domain was entered. Verisigns
> > wildcard record is explicitly intended to break this detection.
> 
> Has Microsoft responded to this yet? Seems like Verisign's scam is
> running over Microsoft's scam.
> 
> 
> sam
> 
> 
> 

RE: Change to .com/.net behavior

[Sam Hayes Merritt, III]

On Wed, 17 Sep 2003, David Schwartz wrote:

>   Microsoft, for example, specifically designed IE to behave in a
> particular way when an unregistered domain was entered. Verisigns
> wildcard record is explicitly intended to break this detection.

Has Microsoft responded to this yet? Seems like Verisign's scam is
running over Microsoft's scam.


sam

Re: Change to .com/.net behavior

[William Devine, II]

Kandra didn't say that they CANNOT modify DNS responses, just that they were
not going to.

william

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 1:13 PM
Subject: Re: Change to .com/.net behavior


>
> > While I too am outraged by the actions of Verisign, I've decided to NOT
> > modify my servers in any way.
> > I might decide to block the sitefinder IP, but I will not change my
> > nameservers into modifying DNS responses. Doing so would be to break
things,
>
> *You* cannot modify DNS responses, but it's okay for Verisign to do so?
>
> Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
>

Re: Change to .com/.net behavior

[Kandra Nygårds]

From: <[EMAIL PROTECTED]>

> > While I too am outraged by the actions of Verisign, I've decided to NOT
> > modify my servers in any way.
> > I might decide to block the sitefinder IP, but I will not change my
> > nameservers into modifying DNS responses. Doing so would be to break
things,
>
> *You* cannot modify DNS responses, but it's okay for Verisign to do so?

No. However they are NOT modifying DNS responses. The responses are
perfectly valid results of having a wildcard in the zone.

The thing is, they have decided to make ALL second level domains in the com
and net zones exist, regardless of wether they are registred or not. This is
a policy breakage that I'm not pleased with at all.

It is, however, very important to realise the difference between breaking
policy and breaking technology.


- Kandra

Re: Change to .com/.net behavior

[Petri Helenius]

Paul Vixie wrote:

I've implemented the official ISC Bind hack on every single one of my
name servers and am pushing it and the configuration changes out to my
customers as a *required* upgrade.
   

that seems a bit extreme.  shouldn't they get to decide this for themselves?
 

How about rewriting all DNS responses to your liking? :-)

Like if you ask for www.register.com, you would get the A record for 
www.verisign.com ?

Responses for the highest bidder!

Pete

Re: Change to .com/.net behavior

[sthaug]

> While I too am outraged by the actions of Verisign, I've decided to NOT
> modify my servers in any way.
> I might decide to block the sitefinder IP, but I will not change my
> nameservers into modifying DNS responses. Doing so would be to break things,

*You* cannot modify DNS responses, but it's okay for Verisign to do so?

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]

Re: Change to .com/.net behavior

[Kandra Nygårds]

From: "David Schwartz" <[EMAIL PROTECTED]>

> Returning NXDOMAIN when a domain does not exist is a basic requirement.
> Failure to do so creates security problems. It is reasonable to require
your
> customers to fix known breakage that creates security problems.

I agree completely. However, this is a policy breakage, not a technial one.
Strictly speaking, the com and net zones are perfectly valid, as far as DNS
is concerned.

While I too am outraged by the actions of Verisign, I've decided to NOT
modify my servers in any way.
I might decide to block the sitefinder IP, but I will not change my
nameservers into modifying DNS responses. Doing so would be to break things,
and that is not an acceptable fix even if the other thing is in itself
broken. Of course, YMMV.


- Kandra

Re: Change to .com/.net behavior

[Paul Vixie]

> > ...  shouldn't they get to decide this for themselves?
> 
>   Returning NXDOMAIN when a domain does not exist is a basic
> requirement.  Failure to do so creates security problems. It is
> reasonable to require your customers to fix known breakage that
> creates security problems.

that sounds pretty thin.  i think you stretched your reasoning too far.

>   VeriSign has a public trust to provide accurate domain
> information for the COM and NET zones. They have decided to put their
> financial interest in obscuring this information ahead of their public
> trust.

i'm not sure how many people inside verisign, us-DoC, and icann agree
that COM and NET are a public trust, or that verisign is just a caretaker.
but, given that this is in some dispute, it again seems that your customers
should decide for themselves which side of the dispute they weigh in on.

>   Microsoft, for example, specifically designed IE to behave in a
> particular way when an unregistered domain was entered. Verisigns
> wildcard record is explicitly intended to break this detection. The
> wildcard only works if software does not treat it as if the domain
> wasn't registered even though it is not.

then microsoft should act.  and if it matters to you then you should act.
but this is not sufficient justification to warrant a demand by you of your
customers that they install a patch (what if they don't run bind?) or that
they configure delegation-only for particular tld's (which ones and why not
others?)

>   Verisign has created a business out of fooling software through
> failure to return a 'no such domain' indication when there is no such
> domain, in breach of their public trust. As much as Verisign was
> obligated not to do this, others are obligated not to propogate the
> breakage. ISPs operate DNS servers for their customers just as
> Verisign operates the COM and NET domains for the public.

the obligations you're speaking of are much less clear than you're saying.

RE: Change to .com/.net behavior

[David Schwartz]

> > I've implemented the official ISC Bind hack on every single one of my
> > name servers and am pushing it and the configuration changes out to my
> > customers as a *required* upgrade.

> that seems a bit extreme.  shouldn't they get to decide this for
> themselves?

Returning NXDOMAIN when a domain does not exist is a basic requirement.
Failure to do so creates security problems. It is reasonable to require your
customers to fix known breakage that creates security problems.

VeriSign has a public trust to provide accurate domain information for the
COM and NET zones. They have decided to put their financial interest in
obscuring this information ahead of their public trust.

Microsoft, for example, specifically designed IE to behave in a particular
way when an unregistered domain was entered. Verisigns wildcard record is
explicitly intended to break this detection. The wildcard only works if
software does not treat it as if the domain wasn't registered even though it
is not.

Verisign has created a business out of fooling software through failure to
return a 'no such domain' indication when there is no such domain, in breach
of their public trust. As much as Verisign was obligated not to do this,
others are obligated not to propogate the breakage. ISPs operate DNS servers
for their customers just as Verisign operates the COM and NET domains for
the public.

DS

Re: Change to .com/.net behavior

[William Devine, II]

Why not just make your users use your servers for forwarding DNS and block
outbound DNS requests @ your router for anything but your servers.
I mean, if you're going to go to the extreme & force your users to not have
access to something they might like (for some unknown reason), might as well
go way overboard.

william

- Original Message - 
From: "Justin Shore" <[EMAIL PROTECTED]>
To: "Christopher X. Candreva" <[EMAIL PROTECTED]>
Cc: "Vadim Antonov" <[EMAIL PROTECTED]>; "Matt Larson"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 12:12 PM
Subject: Re: Change to .com/.net behavior


>
> On Mon, 15 Sep 2003, Christopher X. Candreva wrote:
>
> >
> > On Mon, 15 Sep 2003, Vadim Antonov wrote:
> >
> > > I'm going to hack my BIND so it'll discard wildcard RRs in TLDs, as a
> > > matter of reducing the flood of advertising junk reaching my desktop.
> >
> > Please share your hack !
>
> I've implemented the official ISC Bind hack on every single one of my name
> servers and am pushing it and the configuration changes out to my
> customers as a *required* upgrade.
>
> Justin
>
>

Re: Change to .com/.net behavior

[Paul Vixie]

> I've implemented the official ISC Bind hack on every single one of my
> name servers and am pushing it and the configuration changes out to my
> customers as a *required* upgrade.

that seems a bit extreme.  shouldn't they get to decide this for themselves?
-- 
Paul Vixie

Re: Change to .com/.net behavior

[Justin Shore]

On Mon, 15 Sep 2003, Christopher X. Candreva wrote:

> 
> On Mon, 15 Sep 2003, Vadim Antonov wrote:
> 
> > I'm going to hack my BIND so it'll discard wildcard RRs in TLDs, as a
> > matter of reducing the flood of advertising junk reaching my desktop.
> 
> Please share your hack !

I've implemented the official ISC Bind hack on every single one of my name 
servers and am pushing it and the configuration changes out to my 
customers as a *required* upgrade.

Justin

Re: [Re: Change to .com/.net behavior]

[E.B. Dreger]

JS> Date: Mon, 15 Sep 2003 21:50:42 -0400
JS> From: Joshua Sahala


JS> i'm not sure if it could be cached, but i still see verisign
JS> pretending to 0wn the net...

No, it's not cached.  Try

dig +norec @a.gtld-servers.net '*.net.' any

to confirm.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Re: [Re: Change to .com/.net behavior]

[just me]

On Mon, 15 Sep 2003, Joshua Sahala wrote:

  as is usually suggested on this list, do your talking with your money,
  pull your zones from verisign, and never do business with them again,


Ah, if you own any domains in .com or .net; you are doing business
with Verisign. Sorry...

matto

[EMAIL PROTECTED]<
   Flowers on the razor wire/I know you're here/We are few/And far
   between/I was thinking about her skin/Love is a many splintered
   thing/Don't be afraid now/Just walk on in. #include 

Re: Change to .com/.net behavior

[George William Herbert]

I would like to make a few evolving observations
about the wildcard DNS entries which Verisign
initiated in .net and .com earlier today.

1) By all reasonable interpretations, Verisign is now
operating in violation of the .com and .net Registry
Agreements.  Specifically, Sect 24 of the main agreement
for .com and Sect 3.5.3, 3.5.5, and 3.6, 3.8 of the main
agreement for .net, and the rather blank Appendix X.
I believe it to be trivial to demonstrate that even
if Verisign issued an ammended Appendix X, such a wildcard
entry will exceed the numerical limits specified of 5000
domains, and that the anti-competitive and code of conduct
sections will still apply and prohibit this behaviour.
Explicitly.

2) By any reasonable interpretation this sort of change
should have been clearly announced beforehand to technical
communities that would be affected, including but not
limited to NANOG, and was not.

3) By any reasonable interpretation this sort of change
should have been clearly announced beforehand to policy
communities that would be affected, and was not.

4) By any reasonable interpretation of safe and conservative
operational procedure, when the various technical and policy
issues which were raised over the course of today were
made public, Verisign should have rolled the changes back
out and announced so until such time as at least *proper*
and extensive announcements were made, preferably until such
time as Verisign obtained technical community and policy
community approval.  Verisign has not done so as of when this
email was being prepared, at least not querying A.GTLD...

5) An organization which displays this sort of behaviour
is not a reasonable candidate from an operational standpoint
to stand as the manager of any GTLD.

6) An organization which displays this sort of behaviour
is not a reasonable candidate from a legal standpoint to
stand as the manager of any GTLD.

7) An organization which displays this sort of behaviour
is not a reasonable candidate from a technical standpoint
to stand as technical manager of any GTLD or the registrar
coordination processes.

8) An organization which displays these sorts of behaviours
clearly calls into question the operating assumptions about
fair registrar behaviour in the .com and .net registry
agreements and thus the entire validity of allowing one
company to both manage and act as a registrar for those
domains.  

9) The apparent complete lack of clue on Verisigns'
part as to the magnitude of the hornets nest that
this change would kick over, and its lack of any appropriate
responses even simply better wider information releases,
calls into question the suitability of Verisign's staff
and management structure for operating the key central
registry functions.

10) Given items 1-9, I call upon ICANN to immediately
launch an investegation into the validity and legality
of Verisign's wildcard DNS entries; into the operational
procedures Verisign is using; into the apparent material breach
of Verisign's .com and .net management contracts; and into
the suitability of Verisign to remain the .com and .net
manager in the future and in pariticular the suitability
of the current Verisign management team for participation
in that key neutral operational role.  I specifically
request that ICANN initiate community policy discussions
as to whether the GTLD management functions should be
required to be spun off into a separate entity from
Verisign and not sharing any ownership or management
structure.

11) Given items 1-9, I call upon the Department of Commerce
to immediately investigate whether Verisign is in material
breach of its cooperative agreements and whether Verisign
in its current form and with its current staff are suitable
to remain manager of the .com and .net GTLDs, and the same
set of questions I pose to ICANN, in such areas as DOC
is engaged in policymaking regarding Internet Domain Names.


-george william herbert
[EMAIL PROTECTED]

Re: Change to .com/.net behavior

[David B Harris]

On Tue, 16 Sep 2003 09:50:07 +0300 (IDT)
Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> Don't you think this kind of change should have been discussed first?  Or
> at the *very* least - a 3 day pre-change notice?  Or did mgmt think a
> pre-notice would have caused a firestorm of sufficient size to make you
> backoff such a plan?  Once done - things are harder to undo.

"It's much easier to ask for forgiveness than it is to ask for
permission."

 -- Unknown


pgp0.pgp
Description: PGP signature

Re: Change to .com/.net behavior

[Neil J. McRae]

> 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
> wildcard implementation, which is available here:

This is an insane idea and the other registries doing this
should remove this "feature" also. Goodbye network security.

Neil.

Re: Change to .com/.net behavior

[Hank Nussbacher]

On Mon, 15 Sep 2003, Matt Larson wrote:

Don't you think this kind of change should have been discussed first?  Or
at the *very* least - a 3 day pre-change notice?  Or did mgmt think a
pre-notice would have caused a firestorm of sufficient size to make you
backoff such a plan?  Once done - things are harder to undo.

-Hank

> 
> 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
> wildcard implementation, which is available here:
> 
> 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
> community, is available here:
> 
> http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf
> 
> Matt
> --
> Matt Larson <[EMAIL PROTECTED]>
> VeriSign Naming and Directory Services
> 

Hank Nussbacher

Re: Change to .com/.net behavior

[Duane Wessels]

On Mon, 15 Sep 2003, Matt Larson wrote:

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

The Web Proxy Auto-discovery Protocol (WPAD) is another reason to
fear and loathe this change.  If your host has a bogus name and
makes a WPAD request, they can send your browser a proxy config
function and take full control of your browsing.

Not that they would ever stoop so low...  *cough*

Duane W.

Re: Change to .com/.net behavior

[dani-nanog]

A couple things come to mind --

1) Does this increase the RAM needed on a caching resolver? I.e. does it take
more RAM to cache the 15-minute positive reply, than an NXDOMAIN negative
reply?

2) In the "bestpractices.pdf" file, it states the following:
  "A response server should be configured to return an indication
   that the provided services were reached as a result of wildcard
   processing when the server returns a response to connection
   requests sent by end user applications."

Can Verisign explain how the following transaction is consistent with the
above guideline (where is the indication of wildcard processing):

$ telnet mx.no-suchdomain-yadda-yadda.com 25
Trying 64.94.110.11...
Connected to mx.no-suchdomain-yadda-yadda.com.
Escape character is '^]'.
220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
helo example.com
250 OK
mail from: [EMAIL PROTECTED]
250 OK
rcpt to: [EMAIL PROTECTED]
550 User domain does not exist.

Oh well -- here's to looking out for the BIND patch...

- Dani

Re: Change to .com/.net behavior

[wayne]

In <[EMAIL PROTECTED]> Matt Larson <[EMAIL PROTECTED]> writes:

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

Well, I hope you have the worlds most secure server running on this IP
address as it is going to be a prime target for crackers.

And, just to give you some idea how carefully VeriSlim considered this
aspect, I saw this link on /.

http://sitefinder.verisign.com/lpc?url='%3E%3Ch1%3Ehi%20mom%3C/h1%3E



-wayne

Re: Change to .com/.net behavior

[Dr. Jeffrey Race]

On Mon, 15 Sep 2003 19:24:29 -0400, Matt Larson wrote:
>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
>wildcard implementation, which is available here:
>
>http://www.verisign.com/resources/gd/sitefinder/implementation.pdf 

The file is mutilated by the ColorSpace Error which will cause
difficulties for persons on some platforms in reading it.  You
may wish to recreate it without this error.  See 
.

Thanks for making this file available.

Jeffrey Race

Re: Change to .com/.net behavior

[David B Harris]

Sorry for the double-post folks, I got a bounce and didn't look closely
at it.

If somebody could check the subscriber list for an address that might
result in [EMAIL PROTECTED] filtering really innocent emails (I know
this has happened to others too), and contacting the owner, that would
be great.

Thanks.


pgp0.pgp
Description: PGP signature

Re: Change to .com/.net behavior

[David B Harris]

On Mon, 15 Sep 2003 17:29:43 -0700
Roy <[EMAIL PROTECTED]> wrote:
> 
> It looks like it broke.  Your web server (64.94.110.11) is inoperative. 
>   How about backing out the change

Chances are your ISP has null-routed that IP address. Two of the larger
ISPs in my area (Ontario, Canada) have, as well as the upstreams for a
number of incidental networks I have access to.

Re: Change to .com/.net behavior

[Gregory (Grisha) Trubetskoy]

On Mon, 15 Sep 2003, George William Herbert wrote:

> Did it occur to Verisign that perhaps this needed some external policy
> and technical review before you just went ahead and did this?

I wouldn't be surprised if the real motivation is to get the attention of
(at least the US) government and to set a precedent for regulating DNS,
which will probably be to Verisign's advantage.

Grisha

Re: Change to .com/.net behavior

[Mark Radabaugh]

>
> In other news, Verisign has a press release on their website announcing
> something called "Next Registration Rights Service," where you can place
> an order to have somebody else's domain transferred to you if they ever
> don't pay their bill.  The press release goes on to say that this is a
> great way for holders of existing domain names to buy insurance to protect
> themselves from the loss of their domain names if their bill doesn't get
> paid, but apparrently only if nobody beats them to it.
>
> -Steve

If you make the mistake of letting a domain reach the 'redemption' period
Verisign holds it hostage and dead for a couple of weeks unless you pay them
a $150 extortion fee to get it back.  Apparently ICANN approved the
redemption period and allows the registrar to set whatever fee they like.

I can not prove but I suspect that Verislime is now leaving expired domain
in the GTLD servers until they reach the redemption period in the hope that
people will not notice the domain not resolving until it reaches the
extortion period.

Why are we still putting up with this garbage from Verisign and ICANN?

Mark Radabaugh
Amplex
(419) 720-3635

Re: [Re: Change to .com/.net behavior]

[Joshua Sahala]

i'm not sure if it could be cached, but i still see verisign pretending
to 0wn the net...

as is usually suggested on this list, do your talking with your money,
pull your zones from verisign, and never do business with them again,
file complaints with all relevant state and federal authorities, and let
the l33t Kiddi35 and spammers have some fun ;)  of course, the dept of
greed^Wcommerce will likely give verisign an 'attaboy' for coming up 
with this stunt

while i am sure all of us (excepting the netsol/verisign lurkers) would
like to null route everything attached to them, it will do nothing but
make us look like the 'bad guys'.  this is not the time for knee-jerk
reactions...but damn it would be nice to descend upon verisign's 
corporate hq with clue-by-fours in hand ;)

/joshua


; <<>> DiG 9.2.1 <<>> jklkwekcie.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25772
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;jklkwekcie.com.IN  A

;; ANSWER SECTION:
jklkwekcie.com. 900 IN  A   64.94.110.11

; <<>> DiG 9.2.1 <<>> jklkwekcie.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11930
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;jklkwekcie.net.IN  A

;; ANSWER SECTION:
jklkwekcie.com. 900 IN  A   64.94.110.11

[cut]


"Walk with me through the Universe,
 And along the way see how all of us are Connected.
 Feast the eyes of your Soul,
 On the Love that abounds.
 In all places at once, seemingly endless,
 Like your own existence."
 - Stephen Hawking -

Re: Change to .com/.net behavior

[Steve Gibbard]

On Mon, 15 Sep 2003, Jared Mauch wrote:

>
>   I also typed a bit too quickly.
>
>   I'm guessing due to the uprising they've pulled this.
>
>   I was just going to call the dept of commerce tomorrow and
> file a complaint myself.  perhaps I still will.

It appears GTLD servers A-D are running a serial number of 2003091501 and
contain the wildcard record in .com.  The other GTLD servers are running
2003091500 and don't have the wildcard record.  So, unless there's a
2003091502 floating around out there somewhere that I haven't seen, it
doesn't look to me like they pulled it.

For .net, I'm now seeing 2003091501 everywhere, with the wildcard record.
It doesn't look like they pulled that either.

In other news, Verisign has a press release on their website announcing
something called "Next Registration Rights Service," where you can place
an order to have somebody else's domain transferred to you if they ever
don't pay their bill.  The press release goes on to say that this is a
great way for holders of existing domain names to buy insurance to protect
themselves from the loss of their domain names if their bill doesn't get
paid, but apparrently only if nobody beats them to it.

-Steve


Steve Gibbard   [EMAIL PROTECTED]
+1 510 528-1035 http://www.gibbard.org/~scg

Re: Change to .com/.net behavior

[David B Harris]

On Mon, 15 Sep 2003 17:29:43 -0700
Roy <[EMAIL PROTECTED]> wrote:
> 
> It looks like it broke.  Your web server (64.94.110.11) is inoperative. 
>   How about backing out the change

Chances are your ISP has null-routed that IP address. Two of the larger
ISPs in my area (Ontario, Canada) have, as well as the upstreams for a
number of incidental networks I have access to.


pgp0.pgp
Description: PGP signature

Re: Change to .com/.net behavior

[Joe Maimon]

I want my root servers back

Matt Larson wrote:

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
wildcard implementation, which is available here:
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
community, is available here:
http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf

Matt
--
Matt Larson <[EMAIL PROTECTED]>
VeriSign Naming and Directory Services
 

Re: Change to .com/.net behavior

[Jared Mauch]

On Mon, Sep 15, 2003 at 07:39:20PM -0500, Adam 'Starblazer' Romberg wrote:
> Yeah, speaking too quickly.
> 
> *hides*

I also typed a bit too quickly.

I'm guessing due to the uprising they've pulled this.

I was just going to call the dept of commerce tomorrow and
file a complaint myself.  perhaps I still will.

- jared

% dig any rarrarrarrarblah.com. @f.gtld-servers.net.

; <<>> DiG 8.4 <<>> any rarrarrarrarblah.com. @f.gtld-servers.net. 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43204
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;  rarrarrarrarblah.com, type = ANY, class = IN

;; AUTHORITY SECTION:
com.2D IN SOA   a.gtld-servers.net. nstld.verisign-grs.com. (
2003091500  ; serial
30M ; refresh
15M ; retry
1W  ; expiry
1D ); minimum


;; Total query time: 213 msec
;; FROM: puck.nether.net to SERVER: 192.35.51.30
;; WHEN: Mon Sep 15 20:39:47 2003
;; MSG SIZE  sent: 38  rcvd: 111


> 
> Thanks
> 
> -a-
> 
> 
> 
> Adam 'Starblazer' Romberg Appleton: 920-738-9032
> System Administrator
> ExtremePC LLC-=-  http://www.extremepcgaming.net
> 
> On Mon, 15 Sep 2003, Jared Mauch wrote:
> 
> > On Mon, Sep 15, 2003 at 07:28:51PM -0500, Adam 'Starblazer' Romberg wrote:
> > >
> > > Looks like they pulled it now.
> > >
> > > [EMAIL PROTECTED]:/var/log$ host rarrarrarrarblah.com
> > > rarrarrarrarblah.com does not exist (Authoritative answer)
> >
> > ; <<>> DiG 8.4 <<>> any rarrarrarrarblah.com.
> > ;; res options: init recurs defnam dnsrch
> > ;; got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58435
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13
> > ;; QUERY SECTION:
> > ;;  rarrarrarrarblah.com, type = ANY, class = IN
> >
> > ;; ANSWER SECTION:
> > rarrarrarrarblah.com.   15M IN A64.94.110.11
> >
> >
> > --
> > Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
> > clue++;  | http://puck.nether.net/~jared/  My statements are only mine.
> >

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: Change to .com/.net behavior

[Michael Tokarev]

Adam 'Starblazer' Romberg wrote:
Looks like they pulled it now.

[EMAIL PROTECTED]:/var/log$ host rarrarrarrarblah.com
rarrarrarrarblah.com does not exist (Authoritative answer)
Nah, just zone propagation issues.  Some gtld servers still
have old zone data.
/mjt

Re: Change to .com/.net behavior

[Jay Hennigan]

On Mon, 15 Sep 2003, Adam 'Starblazer' Romberg wrote:

>
> Looks like they pulled it now.
>
> [EMAIL PROTECTED]:/var/log$ host rarrarrarrarblah.com
> rarrarrarrarblah.com does not exist (Authoritative answer)

They haven't implemented it on .com, only .net .

-- 
Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED]
WestNet:  Connecting you to the planet.  805 884-6323  WB6RDV
NetLojix Communications, Inc.  -  http://www.netlojix.com/

Re: Change to .com/.net behavior

[Adam 'Starblazer' Romberg]

Yeah, speaking too quickly.

*hides*

Thanks

-a-



Adam 'Starblazer' Romberg Appleton: 920-738-9032
System Administrator
ExtremePC LLC-=-  http://www.extremepcgaming.net

On Mon, 15 Sep 2003, Jared Mauch wrote:

> On Mon, Sep 15, 2003 at 07:28:51PM -0500, Adam 'Starblazer' Romberg wrote:
> >
> > Looks like they pulled it now.
> >
> > [EMAIL PROTECTED]:/var/log$ host rarrarrarrarblah.com
> > rarrarrarrarblah.com does not exist (Authoritative answer)
>
> ; <<>> DiG 8.4 <<>> any rarrarrarrarblah.com.
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58435
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13
> ;; QUERY SECTION:
> ;;  rarrarrarrarblah.com, type = ANY, class = IN
>
> ;; ANSWER SECTION:
> rarrarrarrarblah.com.   15M IN A64.94.110.11
>
>
> --
> Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
> clue++;  | http://puck.nether.net/~jared/  My statements are only mine.
>

Re: Change to .com/.net behavior

[Jared Mauch]

On Mon, Sep 15, 2003 at 07:28:51PM -0500, Adam 'Starblazer' Romberg wrote:
> 
> Looks like they pulled it now.
> 
> [EMAIL PROTECTED]:/var/log$ host rarrarrarrarblah.com
> rarrarrarrarblah.com does not exist (Authoritative answer)

; <<>> DiG 8.4 <<>> any rarrarrarrarblah.com. 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58435
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13
;; QUERY SECTION:
;;  rarrarrarrarblah.com, type = ANY, class = IN

;; ANSWER SECTION:
rarrarrarrarblah.com.   15M IN A64.94.110.11


-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: Change to .com/.net behavior

[Simon Lyall]

On Tue, 16 Sep 2003, Michael Tokarev wrote:
> Haesu wrote:
> > Before I figure out this BIND thing, for now..
> >
> > box02jp5-cr01.twdx.net# set routing-options static route 64.94.110.11/32 di$
>
> Please do no do that.  You, or your users, will end up having
> TONS of undeliverable bounces for forged/bogus domains sitting
> in mail spools...

On the other hand, what happens to those people who have one of their MX
records pointing to  host at an invalid domain. eg

IN  MX  5 mail.example.com.
IN  MX  10 mail.iforgottodelete.net

Now the previously non-existent host will resolve and bounce your email
instead of being skipped.

-- 
Simon J. Lyall.  |   Very  Busy   |   Mail: [EMAIL PROTECTED]
"To stay awake all night adds a day to your life" - Stilgar | eMT.

Re: Change to .com/.net behavior

[Adam 'Starblazer' Romberg]

Looks like they pulled it now.

[EMAIL PROTECTED]:/var/log$ host rarrarrarrarblah.com
rarrarrarrarblah.com does not exist (Authoritative answer)


thanks,
-a-



Adam 'Starblazer' Romberg Appleton: 920-738-9032
System Administrator
ExtremePC LLC-=-  http://www.extremepcgaming.net

On Tue, 16 Sep 2003, Michael Tokarev wrote:

>
> Haesu wrote:
> []
> > Before I figure out this BIND thing, for now..
> >
> > box02jp5-cr01.twdx.net# set routing-options static route 64.94.110.11/32 discard;
>
> Please do no do that.  You, or your users, will end up having
> TONS of undeliverable bounces for forged/bogus domains sitting
> in mail spools...
>
> /mjt
>
>

Re: Change to .com/.net behavior

[Roy]

It looks like it broke.  Your web server (64.94.110.11) is inoperative. 
 How about backing out the change

Matt Larson wrote:
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
wildcard implementation, which is available here:
http://www.verisign.com/resources/gd/sitefinder/implementation.pdf 

.

Re: Change to .com/.net behavior

[Michael Tokarev]

Haesu wrote:
[]
Before I figure out this BIND thing, for now..

box02jp5-cr01.twdx.net# set routing-options static route 64.94.110.11/32 discard;
Please do no do that.  You, or your users, will end up having
TONS of undeliverable bounces for forged/bogus domains sitting
in mail spools...
/mjt

Re: Change to .com/.net behavior

[Haesu]

You mean you have been studying a way for more people to buy domain through you.

I also am modifying BIND to convert your wildcard #$%^^% to NXDOMAIN.

Between the domains that I have with you and all the problems we've had with it
each time you 'change' your web interface, I've already made my decision to
avoid VeriSign/NetworkSolutions for rest of my life.

Before I figure out this BIND thing, for now..

box02jp5-cr01.twdx.net# set routing-options static route 64.94.110.11/32 discard;

-hc

-- 
Sincerely,
  Haesu C.
  TowardEX Technologies, Inc.
  WWW: http://www.towardex.com
  E-mail: [EMAIL PROTECTED]
  Cell: (978) 394-2867

On Mon, Sep 15, 2003 at 07:24:29PM -0400, Matt Larson wrote:
> 
> 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
> wildcard implementation, which is available here:
> 
> 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
> community, is available here:
> 
> http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf
> 
> Matt
> --
> Matt Larson <[EMAIL PROTECTED]>
> VeriSign Naming and Directory Services

Re: Change to .com/.net behavior

[Christopher X. Candreva]

On Mon, 15 Sep 2003, Vadim Antonov wrote:

> I'm going to hack my BIND so it'll discard wildcard RRs in TLDs, as a
> matter of reducing the flood of advertising junk reaching my desktop.

Please share your hack !

==
Chris Candreva  -- [EMAIL PROTECTED] -- (914) 967-7816
WestNet Internet Services of Westchester
http://www.westnet.com/

Re: Change to .com/.net behavior

[George William Herbert]

Did it occur to Verisign that perhaps this needed 
some external policy and technical review before
you just went ahead and did this?

Have you formally or informally asked ICANN, the US DOC,
etc. for policy approval?  If so, where and when?

Did you consider that nonexistent domains returning
an error was a feature in use by a wide number of security
authentication mechanisms in email and other applications?

Did you consider that major network operators might
want to know about things like this beforehand?
Have you notified any major network operators prior
to this email to NANOG?

Were the root servers apprised of this prior to it
being implimented? [Paul et al, any comments on this one?]

It is nice that Verisign at least documented what you
are doing and why, however, the documentation is not
ipso facto reasonable procedure and community approval.
WiFrom what I can see here and today, you don't have
community approval and don't appear to have followed
anything vaguely like reasonable procedure in getting here.

.com and .net are not your private playthings,
and to be frank Verisign's position in control
of the zones is dependent on it not being the
sort of company to pull stunts of this nature
without appropriate warning and discussion.


-george william herbert
[EMAIL PROTECTED]

Re: Change to .com/.net behavior

[Vadim Antonov]

I'm going to hack my BIND so it'll discard wildcard RRs in TLDs, as a
matter of reducing the flood of advertising junk reaching my desktop.

I think BIND & resolver developers would do everyone a service by adding
an option having the same effect.

Thank you, VeriSign, I will never do business with you again. You are as
bad as any spammer lowlife simply because you leave everyone with no
choice to opt out of your advertising blitz.

--vadim

On Mon, 15 Sep 2003, Matt Larson wrote:

> 
> 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
> wildcard implementation, which is available here:
> 
> 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
> community, is available here:
> 
> http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf
> 
> Matt
> --
> Matt Larson <[EMAIL PROTECTED]>
> VeriSign Naming and Directory Services
>