Re: Root Server Operators (Re: What *are* they smoking?)

[Niels Bakker]

* [EMAIL PROTECTED] (Jack Bates) [Thu 18 Sep 2003, 16:41 CEST]:
> After all, is this the Internet or just the World Wide Web? wildcards at 
> the roots are catering solely to the web and disrupting other protocols 
> which require NXDOMAIN.

Wildcards anywhere are problematic.  I've yet to encounter a situation
where they didn't cause extreme operational brokenness.


-- Niels.

Re: Root Server Operators (Re: What *are* they smoking?)

[Jack Bates]

Paul Vixie wrote:

actually, i had it convincingly argued to me today that wildcards in root
or top level domains were likely to be security problems, and that domains
like .museum were the exception rather than the rule, and that bind's
configuration should permit a knob like "don't accept anything but delegations
unless it's .museum or a non-root non-tld".  i guess the ietf has a lot to
think about now.
Paul,

I would argue as seen in some of my other posts, that the wildcard 
feature of .museum is not always wanted either. Would it not be wise to 
push forward into the future with support for software to request if it 
wants a wildcard or not? While a wildcard bit is ideal, there are 
methods of determining wildcard programatically. Being able to cache and 
handle such information is important as different applications have 
different requirements.

After all, is this the Internet or just the World Wide Web? wildcards at 
the roots are catering solely to the web and disrupting other protocols 
which require NXDOMAIN.

-Jack

Sven-Haegar Koch: Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

forwarding as requested.

--- Begin Message ---
On Thu, 18 Sep 2003, Paul Vixie wrote:

*can't post to nanog, feel free to forward it*

> actually, i had it convincingly argued to me today that wildcards in root
> or top level domains were likely to be security problems, and that domains
> like .museum were the exception rather than the rule, and that bind's
> configuration should permit a knob like "don't accept anything but delegations
> unless it's .museum or a non-root non-tld".  i guess the ietf has a lot to
> think about now.

"don't accept anything but delegations unless it's .museum or a non-root
non-tld" - you need to include for example .de in there too.

They don't have wildcard-records, but lots of domains (mostly from the
biggest website-sellers) don't use own nameservers, but include all
information (mx, a records) directly into the .de-zone.

One example: whois -h whois.denic.de dev0.de

(nsentry records instead of the normal nserver records - available to
everyone who can register domains/change their denic-data)

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
--- End Message ---

Re: public resolver (was: bind patch? (Re: What *are* they smoking?))

[Iljitsch van Beijnum]

On woensdag, sep 17, 2003, at 19:32 Europe/Amsterdam, Paul Vixie wrote:

Just when I thought I had a DNS server I could point my IPv6-only 
hosts
to...

that's the purpose of the f.6to4-servers.net server, and if it's not 
working for you then please send "dig" results and we'll check it out. 
 (not "host", and probably not to "nanog".)
It wouldn't talk to me or some others who were helpful enough to send 
me dig output yesterday. Works fine now, though.

Re: Root Server Operators (Re: What *are* they smoking?)

[bmanning]

amen.  of course the security problems are inherent in the use of wildcards
at all, not just at delegations at/near the root.  One would hope that the 
folks who use wildcards or are IMPACTED by wildcards would review the current 
IETF ID on wildcard clarification that is approching last-call. 


> 
> 
> actually, i had it convincingly argued to me today that wildcards in root
> or top level domains were likely to be security problems, and that domains
> like .museum were the exception rather than the rule, and that bind's
> configuration should permit a knob like "don't accept anything but delegations
> unless it's .museum or a non-root non-tld".  i guess the ietf has a lot to
> think about now.
> 
> re:
> 
> > Date: Wed, 17 Sep 2003 09:58:40 -0500
> > From: Jack Bates <[EMAIL PROTECTED]>
> > User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624
> > To: Paul Vixie <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Root Server Operators (Re: What *are* they smoking?)
> > Sender: [EMAIL PROTECTED]
> > 
> > 
> > Paul Vixie wrote:
> > > no.  not just because that's not how our internal hashing works, but
> > > because "hosted" tld's like .museum have had wildcards from day 1 and
> > > the registrants there are perfectly comfortable with them.  there's
> > > no one-policy-fits-all when it comes to tld's, so we would not want
> > > to offer a knob that tried to follow a single policy for all tld's.
> > 
> > I agree Paul. This is a policy issue and not a technical issue. TLDs that
> > are sponsored or setup with a specific design sometimes do and should be
> > allowed to use the wildcard for the tld. The issue has become that net and
> > com are public trusts and changes were made to them without authorization
> > by the public and damage was caused as a result.
> > 
> > Just as root server operators are subject to operating as IANA dictates, so
> > should Verisign be subject to operating as IAB and ICANN dictate. The
> > Internet as a whole depends on the predictability of TLDs. It is impossible
> > to maintain a security policy based on unpredictable information.
> > 
> > I would recommend that the TLDs which do utilize wildcards setup or
> > restrict such use in a predictable manner. While historically it has not
> > been an issue, such as nonexistant .museum domains being forged in email
> > envelopes, such practices could be exploited at a later time. The ability
> > to recognize that a domain is not registered and should not be used is
> > paramount in basic forgery detection.
> > 
> > One method that might be considered for recursive servers as well as
> > resolvers, is the ability to specify if a wildcard entry will be accepted
> > or not, perhaps at any level or just at the 2nd level. Cached records which
> > are wildcards could be marked as such so that subsequent queries could
> > specify desire of accepting or not accepting the wildcard entry. A web
> > browser, for example, which supports its own redirections for NXDOMAIN,
> > might wish to ignore the wildcard records, as would smtp servers.
> > 
> > While I believe that net and com should never have wildcards, the ability
> > to detect, cache, and override wildcards for tld's such as museum when the
> > application requires it is paramount. I realize that the client software
> > can perform the queries and detection itself, but in many cases, there
> > wouldn't be an effecient way to cache the information without the resolver
> > and recursive cache being aware of the process and performing such
> > detection would require two queries versus one.
> > 
> > 
> > -Jack
> > 
> 

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

actually, i had it convincingly argued to me today that wildcards in root
or top level domains were likely to be security problems, and that domains
like .museum were the exception rather than the rule, and that bind's
configuration should permit a knob like "don't accept anything but delegations
unless it's .museum or a non-root non-tld".  i guess the ietf has a lot to
think about now.

re:

> Date: Wed, 17 Sep 2003 09:58:40 -0500
> From: Jack Bates <[EMAIL PROTECTED]>
> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624
> To: Paul Vixie <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Root Server Operators (Re: What *are* they smoking?)
> Sender: [EMAIL PROTECTED]
> 
> 
> Paul Vixie wrote:
> > no.  not just because that's not how our internal hashing works, but
> > because "hosted" tld's like .museum have had wildcards from day 1 and
> > the registrants there are perfectly comfortable with them.  there's
> > no one-policy-fits-all when it comes to tld's, so we would not want
> > to offer a knob that tried to follow a single policy for all tld's.
> 
> I agree Paul. This is a policy issue and not a technical issue. TLDs that
> are sponsored or setup with a specific design sometimes do and should be
> allowed to use the wildcard for the tld. The issue has become that net and
> com are public trusts and changes were made to them without authorization
> by the public and damage was caused as a result.
> 
> Just as root server operators are subject to operating as IANA dictates, so
> should Verisign be subject to operating as IAB and ICANN dictate. The
> Internet as a whole depends on the predictability of TLDs. It is impossible
> to maintain a security policy based on unpredictable information.
> 
> I would recommend that the TLDs which do utilize wildcards setup or
> restrict such use in a predictable manner. While historically it has not
> been an issue, such as nonexistant .museum domains being forged in email
> envelopes, such practices could be exploited at a later time. The ability
> to recognize that a domain is not registered and should not be used is
> paramount in basic forgery detection.
> 
> One method that might be considered for recursive servers as well as
> resolvers, is the ability to specify if a wildcard entry will be accepted
> or not, perhaps at any level or just at the 2nd level. Cached records which
> are wildcards could be marked as such so that subsequent queries could
> specify desire of accepting or not accepting the wildcard entry. A web
> browser, for example, which supports its own redirections for NXDOMAIN,
> might wish to ignore the wildcard records, as would smtp servers.
> 
> While I believe that net and com should never have wildcards, the ability
> to detect, cache, and override wildcards for tld's such as museum when the
> application requires it is paramount. I realize that the client software
> can perform the queries and detection itself, but in many cases, there
> wouldn't be an effecient way to cache the information without the resolver
> and recursive cache being aware of the process and performing such
> detection would require two queries versus one.
> 
> 
> -Jack
> 

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> > i don't think so.  verisign is on public record as saying that the
> > reason they implemented the wildcard was to enhance the services
> > offered to the internet's eyeball population, who has apparently
> > been clamouring for this.
> 
> My question is, if this was to serve some need of internet users, why
> does port 25 work and not port 80?

i wouldn't speak for verisign on that point even if i knew the facts
(which i don't) but i'm guessing that the internet today has mostly
just got web browsers on it, and verisign is principally concerned
with those people.

> So, I'm curious as to your opinion about the bigger issue. Maybe it
> has been stated somewhere else, and if it has, please direct me to
> it. I've read all of your posts about this on nanog, and you do an
> excellent job of staying neutral. You point out that what Verisign is
> doing is technically valid and therefore shouldn't be addressed with a
> technical "solution", but you also release a patch for Bind to
> accomodate obvious demand (and to save users the hassle of
> implementing half-assed patches with hardcoded A records). However,
> you do so without actually stating whether or not you think the
> wildcards are a (policy) problem or not.

let me be clear on that point, then.  i've now heard some people from
icann's various committees and boards say that they either were not
consulted, or that they were consulted and they advised against this,
and they feel rather strongly that these wildcards should not have
been put in.  so, there is a policy problem, which is that folks don't
agree as to whether verisign is the owner or the steward for .com and
.net, and folks don't agree on whose permission is needed for what.

i would like to see that policy problem resolved, but i have no part
in it, and i don't actually care which way it's resolved, so long as
it is resolved.  we all need to know whether verisign is the owner or
steward, and we all need to know whose permission is needed for what,
and we all need to know what to expect.  resolving the policy problems
will give us all those things.  so, i hope that someone (else) resolves
those policy problems.  (if y'all need me i'll be out washing my cat.)

> You point out that there is high-level ambiguity about the
> relationship between DOC, ICANN, and Verisign, and about whether or
> not Verisign should have the public's interest in mind. 

speaking as an individual, and not as a party to policy discussions
between the people who need to set and follow policies in this arena,
i can say:

> Do you think
> they should have the public's interest in mind?

yes.  because any tld who does not do this gives ammo to the kooks who
want to set up their own alternative namespace.  that would be bad for
the public since it would be even more chaotic than what we have now,
and chaos is expensive and painful.

>  And do you think the
> wildcards are in the public's interest?

no.  i liked it better when vix.com's parent domain (com) had no wildcard,
so that if someone mistyped my domain name they got a hard dns error rather
than a verisign search page or mail error.

> I can certainly empathize with wanting to stay neutral, but I think we
> need somebody who carries substantial influence in the name resolution
> community to have strong opinions about such a poor policy decision.

i sure hope you find her (or him).  good luck with that.  see you all in
san diego (usenix) next month, when i shall joyously lampoon all of this
bitrot during my invited talk on the subject of internet governance.

Re: Root Server Operators (Re: What *are* they smoking?)

[Andy Dills]

On Wed, 17 Sep 2003, Paul Vixie wrote:

> i don't think so.  verisign is on public record as saying that the reason
> they implemented the wildcard was to enhance the services offered to the
> internet's eyeball population, who has apparently been clamouring for this.

My question is, if this was to serve some need of internet users, why does
port 25 work and not port 80?


So, I'm curious as to your opinion about the bigger issue. Maybe it has
been stated somewhere else, and if it has, please direct me to it. I've
read all of your posts about this on nanog, and you do an excellent job of
staying neutral. You point out that what Verisign is doing is technically
valid and therefore shouldn't be addressed with a technical "solution",
but you also release a patch for Bind to accomodate obvious demand (and to
save users the hassle of implementing half-assed patches with hardcoded A
records). However, you do so without actually stating whether or not you
think the wildcards are a (policy) problem or not.

You point out that there is high-level ambiguity about the relationship
between DOC, ICANN, and Verisign, and about whether or not Verisign should
have the public's interest in mind. Do you think they should have the
public's interest in mind? And do you think the wildcards are in the
public's interest?

I can certainly empathize with wanting to stay neutral, but I think we
need somebody who carries substantial influence in the name resolution
community to have strong opinions about such a poor policy decision.

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

Re: public resolver (was: bind patch? (Re: What *are* they smoking?))

[Paul Vixie]

> But I think your patch is working a little too well:
> 
> sequoia# host nanog.org.
> nanog.org has address 198.108.1.50
> nanog.org mail is handled (pri=0) by mail.merit.edu
> sequoia# host nanog.org. F.6TO4-SERVERS.NET
> Using domain server:
> Name: F.6TO4-SERVERS.NET
> Addresses: 2001:4f8:0:2::14 204.152.184.76
> 
> Host not found, try again.

that's certainly not from the patch, since "org" isn't delegation-only there.

> Just when I thought I had a DNS server I could point my IPv6-only hosts 
> to...

that's the purpose of the f.6to4-servers.net server, and if it's not working
for you then please send "dig" results and we'll check it out.  (not "host",
and probably not to "nanog".)
-- 
Paul Vixie

Re: Root Server Operators (Re: What *are* they smoking?)

[Jack Bates]

Aaron Dewell wrote:

The point is, this makes a reasonable backup plan.  Far from ideal, but
we're dealing with a state-supported monopoly who can do whatever they
want.  Get this in place, then think about how to throw the monopolies
out.  This works in the meantime.  They will likely compromise this far,
even if they won't back down.
I'm thinking security for the long term. Even if com and net are 
returned to their non-wildcard states, there are other tld's which will 
continue using wildcards. Subject to a wildcard bit being implemented to 
DNS, my suggested method allows for optimum performance and 
functionality when DNS is being used as part of a security model.

The TTL is 15 minutes, so your hypothetical server would be throwing away
it's cache every 15 minutes.  Then re-querying everything.  You'd have to
have a _lot_ of outgoing email to justify that.
I don't know about you, but I don't want to cache bogus information for 
longer than 15 minutes. If someone sends random-string domains as the 
envelope from to my mail server, I want the cache to purge itself 
quickly. Yet, if they are sending the same bad address to my mail server 
repetitively, I want my cache to hold the record briefly; say 15 
minutes. I'd hate to see a spammer issuing jlkfsjklfsj.com 5,000 times 
to my mail server in rapid succession and my recursor have to ask for it 
every time. On the other side, I would hate to cache 100,000 bogus 
domains for 1 day, wasting cache.

This solution still requires increased overhead, and more modifications
to BIND.  Which has more impact on your server, this BIND overhead, or one
additional query from your MTA?  My guess is the query is cheaper overall.
And you have to convince ISC to implement these changes, or write them
yourself, then you have the potential cost of an unstable nameserver.
Overall, I'd take the one addition query based on the compromise solution.
My mail server doesn't use a bind recursor, so I'll end up making the 
change myself for that particular system. However, a solution needs to 
be devised for the long term. The best solution is a wildcard bit. 
Second to that, smart recursors and resolvers that can detect the wildcard.

-Jack

Re: Root Server Operators (Re: What *are* they smoking?)

[Aaron Dewell]

On Wed, 17 Sep 2003, Jack Bates wrote:
 > Aaron Dewell wrote:
 >
 > > What if there was a requirement to add something that would work as a
 > > wildcard, but also be easily detected as a wildcard with one additional
 > > query?  thisisawildcard.*.com IN A 127.0.0.1 or something.  One additional
 > > query, and applications can decide whether they want a wildcard result or
 > > not.  That could be added to spam filters to make them work again.
 >
 > One additional query is the problem. For example, a mail server running
 > sendmail with a bind recursor. If sendmail has to check for the
 > wildcard, it will have to check for *.com as well as example.com and do
 > a set comparison to see if example.com is a wildcard. For every new
 > process, this has to be repeated, doubling the number of queries on the
 > recusor.

The comparison could be eliminated with the thisisawildcard flag
or similar, but either way, yes, it doubles the number of lookups.
Not ideal, but it works, and given that Verisign is going to continue
to do what they are doing unless DoC or ICANN tells them not to (may or
may not happen), this makes a reasonable backup plan.  If DoC and ICANN
won't tell them to knock it off, they might tell them to make it more
obvious in this way.

Yes, it's more overhead for everyone else to make up for their brilliant
marketing idea, but it would work.  What other plan does everyone have
if ICANN says "Oh, it's ok, we don't mind, whatever they want to do
is fine"?  How many people (realistically) are going to deploy the
ISC patch?  When Paul Vixie says he doesn't really like it?  And it's
only available for BIND 9?

As someone else pointed out, this battle is in a completely different
arena.  MSN and AOL aren't going to implement the patch, guarenteed.
They _might_ redirect traffic to that IP to their own site.  And only
that until a lawsuit gets filed.

The point is, this makes a reasonable backup plan.  Far from ideal, but
we're dealing with a state-supported monopoly who can do whatever they
want.  Get this in place, then think about how to throw the monopolies
out.  This works in the meantime.  They will likely compromise this far,
even if they won't back down.

If the IPv6 specs were modified somewhat, one could assign a prefix to
everyone and every organization, and use a registry to map them, like
the ID system that someone else mentioned (sorry, I don't have the email
in front of me).  Those projects could be combined to solve the problem
for all time.  That's a separate issue that needs more research.

 > If, however, the recursor performed the processes, caching *.com for the
 > TTL and recognizing that all domains resolving to its set is also a
 > wildcard, and caching/marking them as such, then the resolver can
 > request the record, without wildcards, on behalf of sendmail. This means
 > one query to the recursor who has properly cached 1) the domain record,
 > 2) if the domain record is a wildcard, and 3) the wildcard set. This is
 > about the minimal number of queries that can be performed across the
 > board. Applications that want to accept the wildcard would ask the
 > record normally (accepting wildcard).

The TTL is 15 minutes, so your hypothetical server would be throwing away
it's cache every 15 minutes.  Then re-querying everything.  You'd have to
have a _lot_ of outgoing email to justify that.

This solution still requires increased overhead, and more modifications
to BIND.  Which has more impact on your server, this BIND overhead, or one
additional query from your MTA?  My guess is the query is cheaper overall.
And you have to convince ISC to implement these changes, or write them
yourself, then you have the potential cost of an unstable nameserver.
Overall, I'd take the one addition query based on the compromise solution.

Aaron

Re: Root Server Operators (Re: What *are* they smoking?)

[Jack Bates]

Aaron Dewell wrote:

What if there was a requirement to add something that would work as a
wildcard, but also be easily detected as a wildcard with one additional
query?  thisisawildcard.*.com IN A 127.0.0.1 or something.  One additional
query, and applications can decide whether they want a wildcard result or
not.  That could be added to spam filters to make them work again.
One additional query is the problem. For example, a mail server running 
sendmail with a bind recursor. If sendmail has to check for the 
wildcard, it will have to check for *.com as well as example.com and do 
a set comparison to see if example.com is a wildcard. For every new 
process, this has to be repeated, doubling the number of queries on the 
recusor.

If, however, the recursor performed the processes, caching *.com for the 
TTL and recognizing that all domains resolving to its set is also a 
wildcard, and caching/marking them as such, then the resolver can 
request the record, without wildcards, on behalf of sendmail. This means 
one query to the recursor who has properly cached 1) the domain record, 
2) if the domain record is a wildcard, and 3) the wildcard set. This is 
about the minimal number of queries that can be performed across the 
board. Applications that want to accept the wildcard would ask the 
record normally (accepting wildcard).

-Jack

Re: Root Server Operators (Re: What *are* they smoking?)

[Aaron Dewell]

On Wed, 17 Sep 2003, Jack Bates wrote:
 > One method that might be considered for recursive servers as well as
 > resolvers, is the ability to specify if a wildcard entry will be
 > accepted or not, perhaps at any level or just at the 2nd level. Cached
 > records which are wildcards could be marked as such so that subsequent
 > queries could specify desire of accepting or not accepting the wildcard
 > entry. A web browser, for example, which supports its own redirections
 > for NXDOMAIN, might wish to ignore the wildcard records, as would smtp
 > servers.

Verisign is at least using 15 minute ttls on the wildcards.  Not that
I think a wildcard in .com/.net is a great idea, but with the low ttls,
it won't cache that long.

 > While I believe that net and com should never have wildcards, the
 > ability to detect, cache, and override wildcards for tld's such as
 > .museum when the application requires it is paramount. I realize that
 > the client software can perform the queries and detection itself, but in
 > many cases, there wouldn't be an effecient way to cache the information
 > without the resolver and recursive cache being aware of the process and
 > performing such detection would require two queries versus one.

What if there was a requirement to add something that would work as a
wildcard, but also be easily detected as a wildcard with one additional
query?  thisisawildcard.*.com IN A 127.0.0.1 or something.  One additional
query, and applications can decide whether they want a wildcard result or
not.  That could be added to spam filters to make them work again.

I'm not sure if one can use wildcards in that way, but that would solve
the problem and let them keep their wildcards, and put the ball into
the court of the application developers.

Aaron

Re: Root Server Operators (Re: What *are* they smoking?)

[Jack Bates]

Paul Vixie wrote:
no.  not just because that's not how our internal hashing works, but
because "hosted" tld's like .museum have had wildcards from day 1 and
the registrants there are perfectly comfortable with them.  there's
no one-policy-fits-all when it comes to tld's, so we would not want
to offer a knob that tried to follow a single policy for all tld's.
I agree Paul. This is a policy issue and not a technical issue. TLDs 
that are sponsored or setup with a specific design sometimes do and 
should be allowed to use the wildcard for the tld. The issue has become 
that net and com are public trusts and changes were made to them without 
authorization by the public and damage was caused as a result.

Just as root server operators are subject to operating as IANA dictates, 
so should Verisign be subject to operating as IAB and ICANN dictate. The 
Internet as a whole depends on the predictability of TLDs. It is 
impossible to maintain a security policy based on unpredictable information.

I would recommend that the TLDs which do utilize wildcards setup or 
restrict such use in a predictable manner. While historically it has not 
been an issue, such as nonexistant .museum domains being forged in email 
envelopes, such practices could be exploited at a later time. The 
ability to recognize that a domain is not registered and should not be 
used is paramount in basic forgery detection.

One method that might be considered for recursive servers as well as 
resolvers, is the ability to specify if a wildcard entry will be 
accepted or not, perhaps at any level or just at the 2nd level. Cached 
records which are wildcards could be marked as such so that subsequent 
queries could specify desire of accepting or not accepting the wildcard 
entry. A web browser, for example, which supports its own redirections 
for NXDOMAIN, might wish to ignore the wildcard records, as would smtp 
servers.

While I believe that net and com should never have wildcards, the 
ability to detect, cache, and override wildcards for tld's such as 
.museum when the application requires it is paramount. I realize that 
the client software can perform the queries and detection itself, but in 
many cases, there wouldn't be an effecient way to cache the information 
without the resolver and recursive cache being aware of the process and 
performing such detection would require two queries versus one.

-Jack

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> Something like this can be seen on www.airow.com:
> $ dig www.airow.com @a.gtld-servers.net
> ...

looks good to me, man.

; <<>> DiG 8.3 <<>> @f.6to4-servers.net www.airow.com a 
; (2 servers found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUERY SECTION:
;;  www.airow.com, type = A, class = IN

;; ANSWER SECTION:
www.airow.com.  2D IN A 66.82.206.10

;; AUTHORITY SECTION:
airow.com.  2D IN NSns1.rfwwp.com.
airow.com.  2D IN NSwww.airow.com.

;; ADDITIONAL SECTION:
ns1.rfwwp.com.  2D IN A 208.191.129.185

;; Total query time: 37 msec
;; FROM: stick.isc.org to SERVER: f.6to4-servers.net  2001:4f8:0:2::14
;; WHEN: Wed Sep 17 14:31:48 2003
;; MSG SIZE  sent: 31  rcvd: 101

> After delegation-only, they will start to return
> 208.191.129.189. Which is probably an improvement, but a change no
> less.

see above.

> So I'm unsure about ISC's approach.

me too.

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> > : zone "com" { type delegation-only; };
> > : zone "net" { type delegation-only; };
> 
> My first reaction to this was: 'yuck'.

mine also.

> I'm not sure of the side-effects this will introduce. Anyone?

if verisign served a subdomain of com or net on the same server they use
for com or net, and if they issue "minimal responses" (no ns rrs) then
this patch would be a barrier.

Re: Root Server Operators (Re: What *are* they smoking?)

[bert hubert]

On Wed, Sep 17, 2003 at 03:35:31PM +0200, Stefan Baltus wrote:
> On Wed, Sep 17, 2003 at 09:27:13AM -0400, Todd Vierling wrote:
> > On Wed, 17 Sep 2003, Paul Vixie wrote:
> > : > Anyone have a magic named.conf incantation to counter the verisign
> > : > braindamage?
> > : zone "com" { type delegation-only; };
> > : zone "net" { type delegation-only; };
> 
> My first reaction to this was: 'yuck'. I'm not sure of the 
> side-effects this will introduce. Anyone?

The only thing I am slightly worried about is setups that currently "work"
because they rely on glue. Nothing is to stop someone from doing:

yourdomain.com  IN  NS  www.yourdomain.com.
yourdomain.com  IN  NS  yourdomain.com.
www.yourdomain.com  IN  A   1.2.3.4
yourdomain.com  IN  A   1.2.3.4

And not run a nameserver at all and completely rely on glue.

Something like this can be seen on www.airow.com:
$ dig www.airow.com @a.gtld-servers.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24292
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.airow.com. IN  A

;; ANSWER SECTION:
www.airow.com.  172800  IN  A   66.82.206.10


Note the lack of 'aa' bit - but I wonder how many resolvers were accepting
this answer. I know pdns_recursor does, it trusts glue to be right. In this
case, if we actually bother to ask the nameserver www.airow.com for the IP
address of www.airow.com, we don't get an answer. If we ask the other listed
nameserver for airow.com (ns1.rfwwp.com), we get a different IP address,
208.191.129.189.

Different recursors that are publically (130.161.180.1, 195.96.96.97)
available appear to return the first address when currently queried for
www.airow.com, so they trust the glue too.

After delegation-only, they will start to return 208.191.129.189. Which is
probably an improvement, but a change no less.

So I'm unsure about ISC's approach.

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://lartc.org   Linux Advanced Routing & Traffic Control HOWTO

Re: Root Server Operators (Re: What *are* they smoking?)

[Stefan Baltus]

On Wed, Sep 17, 2003 at 09:27:13AM -0400, Todd Vierling wrote:
> 
> On Wed, 17 Sep 2003, Paul Vixie wrote:
> 
> : > Anyone have a magic named.conf incantation to counter the verisign
> : > braindamage?
> :
> : zone "com" { type delegation-only; };
> : zone "net" { type delegation-only; };

My first reaction to this was: 'yuck'. I'm not sure of the 
side-effects this will introduce. Anyone?

Stefan

-- 
Stefan Baltus <[EMAIL PROTECTED]>XB Networks B.V. 
Manager Engineering Televisieweg 2
telefoon: +31 36 54624001322 AC  Almere
fax: +31 36 5462424 The Netherlands

Re: Root Server Operators (Re: What *are* they smoking?)

[Todd Vierling]

On Wed, 17 Sep 2003, Paul Vixie wrote:

: > Anyone have a magic named.conf incantation to counter the verisign
: > braindamage?
:
: zone "com" { type delegation-only; };
: zone "net" { type delegation-only; };

What's to stop VRS from countering with:

*.com.  IN A 
*.com.  IN NS .gtld-servers.net.

?  (Yup, then there's checking SOA, but there's always the chance that they
can synthesize that too, and move the A record inside it.)

Downward spiral, here we come...!  8-)

-- 
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Root Server Operators (Re: What *are* they smoking?)

[Christopher X. Candreva]

On Wed, 17 Sep 2003, Sean Donelan wrote:

> What would it do to website's Keynote performance to eliminate another
> name lookup by having their www.something.com records served directly
> from Verisign's gtld-servers?

Now, that would be a real problem, considdering the person who owns
something.com is a good friend of mine, and hosts it on my servers.

If they start touching actual registered and in-use domains I believe they
will loose their contract.
:-)

(Which also means PLEASE don't use something.com to test !)

-Chris


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

Re: public resolver (was: bind patch? (Re: What *are* they smoking?))

[Iljitsch van Beijnum]

On woensdag, sep 17, 2003, at 06:15 Europe/Amsterdam, Paul Vixie wrote:

I took a look at the Bind 8.3.4 code this afternoon, but couldn't 
readily
find where to do it. I'll take another look later.

isc's patch is running internally.  if anyone wants to try out our 
public
recursive server, it's name is F.6TO4-SERVERS.NET, and it's running 
the patch.
So far so good:

sequoia# host nanog.net.
nanog.net has address 64.94.110.11
sequoia# host nanog.net. F.6TO4-SERVERS.NET
Using domain server:
Name: F.6TO4-SERVERS.NET
Addresses: 2001:4f8:0:2::14 204.152.184.76
Host not found, try again.

But I think your patch is working a little too well:

sequoia# host nanog.org.
nanog.org has address 198.108.1.50
nanog.org mail is handled (pri=0) by mail.merit.edu
sequoia# host nanog.org. F.6TO4-SERVERS.NET
Using domain server:
Name: F.6TO4-SERVERS.NET
Addresses: 2001:4f8:0:2::14 204.152.184.76
Host not found, try again.

Just when I thought I had a DNS server I could point my IPv6-only hosts 
to...

Re: Root Server Operators (Re: What *are* they smoking?)

[Patrick_McAllister]

There is an article on it here:

http://online.wsj.com/article/0,,SB106375269188678100,00.html?mod=technology_main_whats_news

but I think it requires a paid subscription


   

  "Christopher X.  

  Candreva"To:   [EMAIL PROTECTED] 
  
  <[EMAIL PROTECTED]cc:
 
  m>   Subject:  Re: Root Server Operators 
(Re: What *are* they smoking?)  
  Sent by: 

  [EMAIL PROTECTED]

  .edu 

   

   

  09/16/2003 05:21 

  PM   

   






On Tue, 16 Sep 2003, Eric Gauthier wrote:

> On the other hand, a headline of "Internet Providers Worldwide block
access
> to Verisign in Effort to Protect the Public" is very easily understood.

I was contacted a little while ago by a reporter from the Wall Street
Journal, based on my Nanog posts.  We'll see what the headline reads.

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

Re: Root Server Operators (Re: What *are* they smoking?)

[bert hubert]

On Wed, Sep 17, 2003 at 05:13:45AM +, Paul Vixie wrote:

> therefore i believe that while they may have to change the A RR from time to 
> time according to their transit contracts, verisign won't insert an NS RR
> into the sitefinder redirection.  if they do, and if bind's user community
> still wants to avoid sitefinder, they can declare the second server "bogus",
> with no new code changes from isc.  but that all seems terribly unlikely.

I for one expect a small arms race over this - I'm not implementing the
end-all solution quite yet as I expect some further moves by VRSN.

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://lartc.org   Linux Advanced Routing & Traffic Control HOWTO

Re: Root Server Operators (Re: What *are* they smoking?)

[Vadim Antonov]

On Wed, 17 Sep 2003, John Brown wrote:

> speaking as a shareholder of Verisign, I'm NOT HAPPY
> with the way they handled this wildcard deal, nor
> am I happy about them doing it all.  As a *shareholder*
> I'd cast my vote that they *remove* it.

You have no control over operations of the company.  However, you may vote
Verisign officers out of the office... if you can get other shareholders
to see the benefits of giving business ethics preference over short-term
profits.

--vadim 

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> Following Internet Standards and to improve performance for all Internet
> users, what if Verisign decided to start including other A records
> directly in the .COM/.NET zones?
> 
> For example, the A records for the servers for the .COM/.NET zones?

funnily enough, that would work fine, since it would be in-zone glue, and
would arrive in referrals, rather than arriving in answers.  the zone would
still be "delegation-only" according to the functionality we're releasing.

> Or "interesting" sites that Verisign has a relationship with?

that would not work very well for a recursive server who had declared com
or net to be delegation-only.

> I wouldn't be surprised if tomorrow, Verisign is the playing the victim
> and calling ISC the out-of-control hooligans.

that's doubtful.  i've seen people here today advocate "wet teams", null
routing, patches that hard coded A RR values, cutting off uncooperative
root name server operators from internet connectivity, and even writing
letters to congress.  isc's actions are at best a minor sideshow here.

the question you should be asking yourselves is, what will aol and uSoft
do?  will microsoft add "delegation-only" features to its recursive dns
implemenation?  will aol or msn enable this in the recursive servers that
face their customers?  i guess what i'm trying to say is, the folks who
are complaining about this wildcard on nanog, are not the ones verisign
was probably hoping would buy stuff.  "these aren't the eyeballs you're
looking for."  the real action is occuring somewhere else entirely.

Re: Root Server Operators (Re: What *are* they smoking?)

[John Brown]

On Wed, Sep 17, 2003 at 01:39:56AM -0400, Sean Donelan wrote:
>
> I wouldn't be surprised if tomorrow, Verisign is the playing the victim
> and calling ISC the out-of-control hooligans.

Paul an out of control hooligan, say it isn't so ! :)  

Actually I'd trust ISC/Vixie/ to always do the real
right thing when it comes to root-ops and global DNS.

and I'd trust the Verisign people that run A and J to
do reasonable things with those boxes.  They are good
people, when they wear those hats.

I'd almost never trust Verisign to do whats right for
the public / internet when it comes to dealing with
.COM, .NET and such.  Thats their cash cow and they
will milk it for all its worth, and then some.

speaking as a shareholder of Verisign, I'm NOT HAPPY
with the way they handled this wildcard deal, nor
am I happy about them doing it all.  As a *shareholder*
I'd cast my vote that they *remove* it.

Re: Root Server Operators (Re: What *are* they smoking?)

[Sean Donelan]

On Wed, 17 Sep 2003, Paul Vixie wrote:
> > So, Verisign just returns a NS pointer to another name server Verisign
> > controls which then answers the queries with Verisign's "helpful" web
> > site.
> >
> > Half-life of the patch: 1 day?
>
> i don't think so.  verisign is on public record as saying that the reason
> they implemented the wildcard was to enhance the services offered to the
> internet's eyeball population, who has apparently been clamouring for this.

Verisign is on public record as saying many things over the years.

Following Internet Standards and to improve performance for all Internet
users, what if Verisign decided to start including other A records
directly in the .COM/.NET zones?

For example, the A records for the servers for the .COM/.NET zones?  Or
"interesting" sites that Verisign has a relationship with?

What would it do to website's Keynote performance to eliminate another
name lookup by having their www.something.com records served directly
from Verisign's gtld-servers?

Of course, ISC's non-standard BIND change will break Verisign's
attempt to "improve" the Internet's performance by including A records
in the .COM/.NET zones.


Verisign's lobbyists are 3,000 miles closer to Washington DC than
ISC's lobbyists.  And history has demonstrated what Verisign lacks
in Internet clue, they make up for in Washington clue.


I wouldn't be surprised if tomorrow, Verisign is the playing the victim
and calling ISC the out-of-control hooligans.

Re: Root Server Operators (Re: What *are* they smoking?)

[Declan McCullagh]

Yep, it went up around 6 pm ET on Tuesday. The list was a tremendous
help, BTW. I don't think any folks who have followed these threads will
find anything especially new in the article, but it may serve as a decent
summary.

ICANN's Mary Hewitt did tell me that they'd have a statement out in a
few days. After a few hours of back and forth, Commerce decided to
refer calls to ICANN and Verisign, though I've sent them a list of
followup questions that, just maybe, they'll answer on Wednesday.

Best,
Declan


On Wed, Sep 17, 2003 at 08:23:40AM +0200, Hank Nussbacher wrote:
> 
> At 05:26 PM 16-09-03 -0400, Damian Gerow wrote:
> 
> >Declan (of news.com) has indicated that he's working on something, and I'm
> >waiting to hear back from the editors at lightreading.com.  I have full
> >faith that Declan will not only put out a technically accurate piece, but
> >one that is easily digestible by the public at large.
> 
> http://news.com.com/2100-1032_3-5077530.html
> 
> -Hank
> 
> 

Re: Root Server Operators (Re: What *are* they smoking?)

[E.B. Dreger]

SD> Date: Wed, 17 Sep 2003 00:48:09 -0400 (EDT)
SD> From: Sean Donelan


SD> So, Verisign just returns a NS pointer to another name server
SD> Verisign controls which then answers the queries with
SD> Verisign's "helpful" web site.

Queries for random zones make a nice starting point.


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: Root Server Operators (Re: What *are* they smoking?)

[Hank Nussbacher]

At 05:26 PM 16-09-03 -0400, Damian Gerow wrote:

Declan (of news.com) has indicated that he's working on something, and I'm
waiting to hear back from the editors at lightreading.com.  I have full
faith that Declan will not only put out a technically accurate piece, but
one that is easily digestible by the public at large.
http://news.com.com/2100-1032_3-5077530.html

-Hank

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> So, Verisign just returns a NS pointer to another name server Verisign
> controls which then answers the queries with Verisign's "helpful" web
> site.
> 
> Half-life of the patch: 1 day?

i don't think so.  verisign is on public record as saying that the reason
they implemented the wildcard was to enhance the services offered to the
internet's eyeball population, who has apparently been clamouring for this.

in this story, for example...

http://story.news.yahoo.com/news?tmpl=story&u=/ap/20030916/ap_on_hi_te/internet_typos_4

...it was thus spake:

   VeriSign spokesman Brian O'Shaughnessy said Tuesday that individual
   service providers were free to configure their systems so customers 
   would bypass Site Finder. But he questioned whether releasing a patch
   to do so would violate Internet standards.
   
   Vixie acknowledged that it could -- standards call for operators like
   VeriSign to have complete control over their directories -- but he
   said not releasing a patch would create greater chaos.

therefore i believe that while they may have to change the A RR from time to 
time according to their transit contracts, verisign won't insert an NS RR
into the sitefinder redirection.  if they do, and if bind's user community
still wants to avoid sitefinder, they can declare the second server "bogus",
with no new code changes from isc.  but that all seems terribly unlikely.

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> Can you also program something to do this for all root zones,
> i.e. something like 'zone ".*" { type deligation-only; };'

no.  not just because that's not how our internal hashing works, but
because "hosted" tld's like .museum have had wildcards from day 1 and
the registrants there are perfectly comfortable with them.  there's
no one-policy-fits-all when it comes to tld's, so we would not want
to offer a knob that tried to follow a single policy for all tld's.

> And make it default configuration for new bind releases...

never.  not for your example, nor for any set of tld's.  the default for
bind will be what it's always been -- to respect the autonomy of the
zone administrator/publisher.  overriding that autonomy has to be a
local act by a local name server administrator who is fully conscious of
the impact of their configuration change.  once, with "check-names", isc
was accused of "legislating from the bench".  never again.

Re: Root Server Operators (Re: What *are* they smoking?)

[william]

Can you also program something to do this for all root zones, i.e. something 
like 'zone ".*" { type deligation-only; };'

And make it default configuration for new bind releases...

On 17 Sep 2003, Paul Vixie wrote:

> 
> > Anyone have a magic named.conf incantation to counter the verisign 
> > braindamage?
> 
> zone "com" { type delegation-only; };
> zone "net" { type delegation-only; };
> 
> > Or does this require a patch to bind?
> 
> yes, it does.  to be released shortly.

Re: Root Server Operators (Re: What *are* they smoking?)

[Sean Donelan]

On 17 Sep 2003, Paul Vixie wrote:
> > Anyone have a magic named.conf incantation to counter the verisign
> > braindamage?
>
> zone "com" { type delegation-only; };
> zone "net" { type delegation-only; };
>
> > Or does this require a patch to bind?
>
> yes, it does.  to be released shortly.

With enough levels of indirection any computing problem can be solved.

So, Verisign just returns a NS pointer to another name server Verisign
controls which then answers the queries with Verisign's "helpful" web
site.

Half-life of the patch: 1 day?

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> Anyone have a magic named.conf incantation to counter the verisign 
> braindamage?

zone "com" { type delegation-only; };
zone "net" { type delegation-only; };

> Or does this require a patch to bind?

yes, it does.  to be released shortly.
-- 
Paul Vixie

Re: Root Server Operators (Re: What *are* they smoking?)

[Paul Vixie]

> [dot-net, dot-com] is arguably not a valid zone file.  Therefore, any
> root server operators should refuse the improper zone file.

that's nonsequitur.  root server operators do not carry the dot-com or
dot-net zone files.  therefore there will never be an opportunity to
refuse (or accept) it.  root server operators (see www.root-servers.org
for details) include verisign as one of 11 organzations worldwide.  the
dot-com and dot-net zones, by comparison, are only served by verisign's
own servers, and i do not think that verisign will refuse to accept them.
-- 
Paul Vixie

bind patch? (Re: What *are* they smoking?)

[Paul Vixie]

> I took a look at the Bind 8.3.4 code this afternoon, but couldn't readily
> find where to do it. I'll take another look later.

isc's patch is running internally.  if anyone wants to try out our public
recursive server, it's name is F.6TO4-SERVERS.NET, and it's running the patch.
(we'll release it as soon as we get done with some release engineering goo.)
((no fair declaring a forward zone for com/net pointing at us, by the way.))

> (Last time I tried it Bind 9 sucked up twice as much server CPU as 8.x)

we run bind9 on f-root, and it's fine.  you should give it another try,
since it has gotten faster of late, and so have cpus/memory/motherboards.
-- 
Paul Vixie

Re: Root Server Operators (Re: What *are* they smoking?)

[E.B. Dreger]

DL> Date: Tue, 16 Sep 2003 21:20:08 -0400 (EDT)
DL> From: David Lesher


DL> Verisign Move to Mean More Spam
DL>
DL> Will that do for a hook?

s,to,could, and I'll bite.  Gotta keep it factual.


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: Root Server Operators (Re: What *are* they smoking?)

[David Lesher]

Speaking on Deep Background, the Press Secretary whispered:
> 
> Right now, I really can't think of a headline that
> the NY Times or CNN could run that would make ordinary people understand
> what's going on and encourage them to bring pressure on Verisign.  


Verisign Move to Mean More Spam


Will that do for a hook?



-- 
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433

Re: What *are* they smoking?

[bdragon]

> Here is one solution - replace all of your root.cache files with:

1) it doesn't solve the problem of the .com and .net registry handing out
addresses
2) It creates whole new sets of problems

Please continue to go off and skulk in a corner

Re: Root Server Operators (Re: What *are* they smoking?)

[Christopher X. Candreva]

On Tue, 16 Sep 2003, Damian Gerow wrote:

> Declan (of news.com) has indicated that he's working on something, and I'm
> waiting to hear back from the editors at lightreading.com.  I have full
> faith that Declan will not only put out a technically accurate piece, but
> one that is easily digestible by the public at large.

One other thing to do -- call the technology writer for your local paper, if
you know who that is. Which you should.

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

Re: Root Server Operators (Re: What *are* they smoking?)

[Damian Gerow]

Thus spake Christopher X. Candreva ([EMAIL PROTECTED]) [16/09/03 17:24]:
> > On the other hand, a headline of "Internet Providers Worldwide block access
> > to Verisign in Effort to Protect the Public" is very easily understood.
> 
> I was contacted a little while ago by a reporter from the Wall Street
> Journal, based on my Nanog posts.  We'll see what the headline reads.

Declan (of news.com) has indicated that he's working on something, and I'm
waiting to hear back from the editors at lightreading.com.  I have full
faith that Declan will not only put out a technically accurate piece, but
one that is easily digestible by the public at large.

Re: Root Server Operators (Re: What *are* they smoking?)

[Christopher X. Candreva]

On Tue, 16 Sep 2003, Eric Gauthier wrote:

> On the other hand, a headline of "Internet Providers Worldwide block access
> to Verisign in Effort to Protect the Public" is very easily understood.

I was contacted a little while ago by a reporter from the Wall Street
Journal, based on my Nanog posts.  We'll see what the headline reads.

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

Re: What *are* they smoking?

[Ben Browning]

At 12:07 PM 9/16/2003, Rich Braun wrote:
VeriSign stands to gain financially, take a look at this excerpt from an AP
news blurb published yesterday:
...

Anyone find out any details of the contracts which VeriSign has apparently
signed to profit from this little venture?
No, but check this out:

http://sitefinder.verisign.com/spc?sb=bulk+email&searchboxtype=2
http://sitefinder.verisign.com/spc?sb=bulk+mailers&searchboxtype=2
Not that I am shocked.

~Ben

---
   Ben Browning <[EMAIL PROTECTED]>
  The River Internet Access Co.
 WA Operations Manager
1-877-88-RIVER  http://www.theriver.com

Re: What *are* they smoking?

[alex]

> > $ host does.really-not-exist.net
> > does.really-not-exist.net has address 64.94.110.11
> > 
> > $ host 64.94.110.11
> > 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com
> 
> Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it 
> to a box and alias it on eth0. Put up a 404 not found and let Verisign
> rot in hell until such time as they regain their consiousness.

No, no, no. Here is what you do - you redirect this traffic to your own
server and monetize it. 

Alex
 

Re: Root Server Operators (Re: What *are* they smoking?)

[Ben Crosby]

Damian,

You wrote:

Damian>  But any journalists snooping around sure could help out
Damian> a bit, at least by indicating that there /is/ a
Damian> problem with this decision,
Damian> and that Operators are still trying to figure out a) *why* it happened, and
Damian> b) the best way to 'fix' it.

How about writing up a simple explanation and sending it to some folks
over at lightreading. That'll get some coverage.

Ben.

Root Server Operators (Re: What *are* they smoking?)

[John Neiberger]

 <[EMAIL PROTECTED]> 9/16/03 2:18:58 PM >>>
>
>
>Just came across this: 
>
>http://www.washingtonpost.com/wp-dyn/articles/A996-2003Sep12.html 
>

Interesting and well-written. And ICANN had no comment.

John
--

Re: Root Server Operators (Re: What *are* they smoking?)

[Mike Lewinski]

http://www.iab.org/Documents/icann-vgrs-response.html

Re: Root Server Operators (Re: What *are* they smoking?)

[John Neiberger]

 "Robert A. Hayden" <[EMAIL PROTECTED]> 9/16/03 2:07:08 PM >>>
>
>On Tue, 16 Sep 2003, Damian Gerow wrote:
>> How about, 'Internet Operators Across North America Struggle to Deal
with
>> Impact of Business Decision: Internet Functionality Worldwide
>> Tampered With by Verisign'?  There doesn't really appear to be a
unified
>> decision to do one thing, there's a lot of bandying ideas around,
and
>> 'wouldn't-it-be-cool-if's being thrown out.

Given the technical nature of the issue perhaps someone from the list
with excellent writing skills could author the 'press release'. Then, if
someone else has some media or press contacts they could simply pass the
release along to them. To be sure, that idea has a few problems but at
least you have a chance to make sure the release contains factual
information while still conveying the importance of the issue, two
things that wouldn't be guaranteed if this were written up by a
non-technical member of the press.

Anybody know someone that works for AP or Reuters?  Or maybe Wall
Street Journal? :-)

John
--

Re: What *are* they smoking?

[Aaron Hopkins]

On Tue, 16 Sep 2003, Rich Braun wrote:

> VeriSign stands to gain financially, take a look at this excerpt from an AP
> news blurb published yesterday:
> [...]
> Anyone find out any details of the contracts which VeriSign has apparently
> signed to profit from this little venture?

It looks like Overture is doing the paid listings:

Compare http://sitefinder.verisign.com/spc?kw=Travel
withhttp://www.overture.com/d/search/?Keywords=travel

You can also see this by looking at the links on the results page.
"www.expedia.com" is actually http://www3.overture.com/d/sr/?...

And Inktomi is the provider of non-paid listings:

Compare http://sitefinder.verisign.com/spc?sb=verisign+sucks
withhttp://www.hotbot.com/default.asp?query=verisign+sucks

Both Overture and Inktomi are now owned by Yahoo.

Anyone with an Overture account can see what the high bids on the keywords
Travel, Entertainment, Gambling, Shopping, Gifts, Computers, Autos,
Insurance, Small Business, and Investing are now.  From a SEC filing a while
ago, I seem to recall that something near half of the money from each click
goes back to the "search engine" in question, in this case Verisign.

-- Aaron

Root Server Operators (Re: What *are* they smoking?)

[joej]

Just came across this: 

http://www.washingtonpost.com/wp-dyn/articles/A996-2003Sep12.html

Re: Root Server Operators (Re: What *are* they smoking?)

[Dan Hollis]

Anyone have a magic named.conf incantation to counter the verisign 
braindamage? Or does this require a patch to bind?

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: Root Server Operators (Re: What *are* they smoking?)

[David B Harris]

On Tue, 16 Sep 2003 22:48:43 +0300 (IDT)
Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> > Verisign is a business and its goal is to make money.More importantly,
> > its a publically traded company whose goal is to make its stock value go up.
> > So, if we're interested in having them listen, we should be targeting
> > their stock value.Right now, I really can't think of a headline that
> > the NY Times or CNN could run that would make ordinary people understand
> > what's going on and encourage them to bring pressure on Verisign.Besides, 
> > Verisign would obviously counter with the junk in their release.
> > 
> 
> So far up 1.7% today:
> http://finance.yahoo.com/q/bc?s=VRSN&t=1d
> 
> Looks like they are winning.

Please take heart in the fact that the performance of IT stocks these
days is not in any way a reflection of the company in question. That
stock performance became meaningless during the dot-com bubble and
to this day it remains impossible to draw any sort of substantive
conclusion based on it.


pgp0.pgp
Description: PGP signature

Re: Root Server Operators (Re: What *are* they smoking?)

[Robert A. Hayden]

On Tue, 16 Sep 2003, Damian Gerow wrote:
> How about, 'Internet Operators Across North America Struggle to Deal with
> Impact of Business Decision: Internet Functionality Worldwide
> Tampered With by Verisign'?  There doesn't really appear to be a unified
> decision to do one thing, there's a lot of bandying ideas around, and
> 'wouldn't-it-be-cool-if's being thrown out.

I'm partial to "Verisign Hijacks Internet" as a good headline.

- Robert
"ip route 64.94.110.11 255.255.255.255 null0"

Re: Root Server Operators (Re: What *are* they smoking?)

[Hank Nussbacher]

On Tue, 16 Sep 2003, Eric Gauthier wrote:

> Verisign is a business and its goal is to make money.More importantly,
> its a publically traded company whose goal is to make its stock value go up.
> So, if we're interested in having them listen, we should be targeting
> their stock value.Right now, I really can't think of a headline that
> the NY Times or CNN could run that would make ordinary people understand
> what's going on and encourage them to bring pressure on Verisign.Besides, 
> Verisign would obviously counter with the junk in their release.
> 

So far up 1.7% today:
http://finance.yahoo.com/q/bc?s=VRSN&t=1d

Looks like they are winning.

-Hank

Re: Root Server Operators (Re: What *are* they smoking?)

[Damian Gerow]

Thus spake Eric Gauthier ([EMAIL PROTECTED]) [16/09/03 13:49]:
> I'm sure that 5, 10, or 50 phone calls from Nanog-ers to the FTC, Congress,
> Dept of Commerce, ICANN, the US Post Office, or any other large organization 
> will be completely ignored in the likely wash of everyday phone calls.  We can 
> talk about violations of RFCs and ask them to cease this stupidity, but I 
> doubt that will work because there doesn't appear to be any consequences.

I think this goes for /anything/.

If five, ten, or fifty of any of us do any one thing, it's not going to have
an impact.  So a handful of ISP's null route the IP address.  And a few
others hack their recursor code to return NXDOMAIN if a response returns
with a given IP address, or even if it matches a wildcard gTLD lookup.  And
maybe a few more of us call ICANN, and some more call the FTC.  It may solve
it for you, but it doesn't necessarily fix the source of the problem.

(And these hacks really should make it back into the CVS tree if they're
going to be effective.)

> On the other hand, a headline of "Internet Providers Worldwide block access
> to Verisign in Effort to Protect the Public" is very easily understood.  

How about, 'Internet Operators Across North America Struggle to Deal with
Impact of Business Decision: Internet Functionality Worldwide
Tampered With by Verisign'?  There doesn't really appear to be a unified
decision to do one thing, there's a lot of bandying ideas around, and
'wouldn't-it-be-cool-if's being thrown out.

At this point, there isn't a concerted enough effort to warrant a title like
the one you suggest.  But any journalists snooping around sure could help out
a bit, at least by indicating that there /is/ a problem with this decision,
and that Operators are still trying to figure out a) *why* it happened, and
b) the best way to 'fix' it.

My $0.02.

Re: What *are* they smoking?

[Greg Maxwell]

On Tue, 16 Sep 2003, Mark Jeftovic wrote:

> > It's very amusing to see people on *this* list asking *who* gave control
> > to them. Who else configures your customers DNS settings?
>
> My customers.

End users don't figure out DNS settings on their own, either a network
operator picks what roots they use (by say accepting a default root cache
in a resolver package) or they obtain configuration directives from an
upstream network.

Re: What *are* they smoking?

[Rich Braun]

VeriSign stands to gain financially, take a look at this excerpt from an AP
news blurb published yesterday:

> Ben Turner, VeriSign's vice president for naming services, described the
service
> as a way to "improve overall usability of the Internet."
>
> People mistype ".com" and ".net" names some 20 million times daily, Turner
said,
> and internal studies show "the vast majority of users prefer a page like this
> than what they are getting today."
>...
> Currently, Site Finder sends lost Web surfers to both regular search results
and
> pay-for-placement listings, which are marked as such. Turner said VeriSign was
> partnering with two search companies he would not name.
>
> He would not disclose how much VeriSign would earn from those companies, with
> which it has revenue-sharing arrangements.

Anyone find out any details of the contracts which VeriSign has apparently
signed to profit from this little venture?

-rich

Re: Root Server Operators (Re: What *are* they smoking?)

[Valdis . Kletnieks]

On Tue, 16 Sep 2003 13:31:19 EDT, Eric Gauthier said:

> it.  I'm a stupid network engineer that typically leaves the money stuff up 
> to my finance geek friends, but even I know that (well most of the time):
> 
>   Bad Press == Stock Go Down

I wish this explained SCO's stock price... ;)


pgp0.pgp
Description: PGP signature

Re: Root Server Operators (Re: What *are* they smoking?)

[Lars Erik Gullerud]

On Tue, 2003-09-16 at 18:50, William Allen Simpson wrote:

> > Please note that the people running the root nameservsers are a different
> > set from the people who run the .com and .net nameservers.
> > 
> True, these days, at least in part.
> 
> Since the latest zone for .net (and maybe .com according to the 
> announcement) contains data that 
>  * indicates existance for domains that actually do not exist, and 
>  * incorrect addresses for domains that exist, but are not using the 
>name service of netSOL cum verisign, 
> it is arguably not a valid zone file.  Therefore, any root server 
> operators should refuse the improper zone file.

Whether the .net and .com zone files are valid or not is really
irrelevant for your argument - since the zone file served by the root
servers is only for the . zone, not the .net or .com zones any more. The
zone file the _root servers_ hold IS therefore a valid zone file.
Whatever junk Verisign puts into the com. and net. zones does not
implicate the . zone servers at all. 

/leg

Re: Root Server Operators (Re: What *are* they smoking?)

[Eric Gauthier]

> Since the latest zone for .net (and maybe .com according to the 
> announcement) contains data that 
>  * indicates existance for domains that actually do not exist, and 
>  * incorrect addresses for domains that exist, but are not using the 
>name service of netSOL cum verisign, 
> it is arguably not a valid zone file.  Therefore, any root server 
> operators should refuse the improper zone file.
> 
> We are about to empirically determine the independence of the root 
> server operators.

I'm sure that 5, 10, or 50 phone calls from Nanog-ers to the FTC, Congress,
Dept of Commerce, ICANN, the US Post Office, or any other large organization 
will be completely ignored in the likely wash of everyday phone calls.  We can 
talk about violations of RFCs and ask them to cease this stupidity, but I 
doubt that will work because there doesn't appear to be any consequences.

Verisign is a business and its goal is to make money.  More importantly,
its a publically traded company whose goal is to make its stock value go up.
So, if we're interested in having them listen, we should be targeting
their stock value.  Right now, I really can't think of a headline that
the NY Times or CNN could run that would make ordinary people understand
what's going on and encourage them to bring pressure on Verisign.  Besides, 
Verisign would obviously counter with the junk in their release.

On the other hand, a headline of "Internet Providers Worldwide block access
to Verisign in Effort to Protect the Public" is very easily understood.  
Verisign can say anything that they want, but the public gets the idea that 
people in the know think this is such a bad idea that they took action against 
it.  I'm a stupid network engineer that typically leaves the money stuff up 
to my finance geek friends, but even I know that (well most of the time):

Bad Press == Stock Go Down

So, if collectively we think this is determinental to the stability and
security of the Internet, then we should either take steps to block it 
or, more importantly, issue press releases and statements to reporters stating
that we will.  I think this is the only way to effectively reverse
Verisign's poor decision.

I think its time for the Root Server operators to step up or at least say
that they are going to step up.

Eric :)

Re: What *are* they smoking?

[Chris Adams]

Once upon a time, John Palmer <[EMAIL PROTECTED]> said:
> Here is one solution - replace all of your root.cache files with:
> 
> (root)  nameserver = C.ROOT-SERVERS.ORSC

Since the ORSC servers still refer com and net to the GTLD servers, this
will have no impact on the issue at hand.

-- 
Chris Adams <[EMAIL PROTECTED]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Root Server Operators (Re: What *are* they smoking?)

[William Allen Simpson]

Bruce Campbell wrote:
> 
> On Tue, 16 Sep 2003, Matthew Kaufman wrote:
> 
> > record. Great. Just what we need... To be in an escalating war with the
> > people running the root nameservers.
> 
> Please note that the people running the root nameservsers are a different
> set from the people who run the .com and .net nameservers.
> 
True, these days, at least in part.

Since the latest zone for .net (and maybe .com according to the 
announcement) contains data that 
 * indicates existance for domains that actually do not exist, and 
 * incorrect addresses for domains that exist, but are not using the 
   name service of netSOL cum verisign, 
it is arguably not a valid zone file.  Therefore, any root server 
operators should refuse the improper zone file.


> Please use the slightly more accurate term 'gTLD nameservers' instead of
> tarring the 'root' nameservers with the same brush.
> 
We are about to empirically determine the independence of the root 
server operators.
-- 
William Allen Simpson
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: What *are* they smoking?

[Mark Jeftovic]

On Tue, 16 Sep 2003, Greg Maxwell wrote:

>
> On Tue, 16 Sep 2003, Haesu wrote:
>
> > I must ask the subject again. What in the name of < censored > *are* they smoking? 
> > Who exclusively gave them the right to own the 'net and decide which domain points 
> > to where?
> > Completely unacceptable.
>
> It's very amusing to see people on *this* list asking *who* gave control
> to them. Who else configures your customers DNS settings?
>

My customers.

-mark

-- 
Mark Jeftovic <[EMAIL PROTECTED]>
Co-founder, easyDNS Technologies Inc.
ph. +1-(416)-535-8672 ext 225
fx. +1-(416)-535-0237

Re: What *are* they smoking?

[John Palmer]

Here is one solution - replace all of your root.cache files with:

(root)  nameserver = C.ROOT-SERVERS.ORSC
(root)  nameserver = D.ROOT-SERVERS.ORSC
(root)  nameserver = E.ROOT-SERVERS.ORSC
(root)  nameserver = F.ROOT-SERVERS.ORSC
(root)  nameserver = H.ROOT-SERVERS.ORSC
(root)  nameserver = I.ROOT-SERVERS.ORSC
(root)  nameserver = K.ROOT-SERVERS.ORSC
(root)  nameserver = L.ROOT-SERVERS.ORSC
(root)  nameserver = M.ROOT-SERVERS.ORSC
(root)  nameserver = A.ROOT-SERVERS.ORSC
C.ROOT-SERVERS.ORSC internet address = 199.166.28.10
D.ROOT-SERVERS.ORSC internet address = 204.80.125.130
E.ROOT-SERVERS.ORSC internet address = 195.117.6.25
F.ROOT-SERVERS.ORSC internet address = 199.166.31.3
H.ROOT-SERVERS.ORSC internet address = 199.5.157.128
I.ROOT-SERVERS.ORSC internet address = 204.57.55.100
K.ROOT-SERVERS.ORSC internet address = 199.166.27.4
L.ROOT-SERVERS.ORSC internet address = 199.166.29.2
M.ROOT-SERVERS.ORSC internet address = 195.206.104.13
A.ROOT-SERVERS.ORSC internet address = 199.166.24.12

- Original Message - 
From: "Greg Maxwell" <[EMAIL PROTECTED]>
To: "Haesu" <[EMAIL PROTECTED]>
Cc: "Marius Strom" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, September 16, 2003 11:23
Subject: Re: What *are* they smoking?


>
> On Tue, 16 Sep 2003, Haesu wrote:
>
> > I must ask the subject again. What in the name of < censored > *are* they smoking? 
> > Who exclusively gave them the right to own
the 'net and decide which domain points to where?
> > Completely unacceptable.
>
> It's very amusing to see people on *this* list asking *who* gave control
> to them. Who else configures your customers DNS settings?
>
>
>
>

Re: What *are* they smoking?

[Greg Maxwell]

On Tue, 16 Sep 2003, Haesu wrote:

> I must ask the subject again. What in the name of < censored > *are* they smoking? 
> Who exclusively gave them the right to own the 'net and decide which domain points 
> to where?
> Completely unacceptable.

It's very amusing to see people on *this* list asking *who* gave control
to them. Who else configures your customers DNS settings?

RE: What *are* they smoking?

[Bruce Campbell]

On Tue, 16 Sep 2003, Matthew Kaufman wrote:

> record. Great. Just what we need... To be in an escalating war with the
> people running the root nameservers.

Please note that the people running the root nameservsers are a different
set from the people who run the .com and .net nameservers.

Please use the slightly more accurate term 'gTLD nameservers' instead of
tarring the 'root' nameservers with the same brush.

--==--
Bruce.

Re: What *are* they smoking?

[Marius Strom]

Just noticed this: verisign is redirecting queries for dorkslayers.com's
old RBL, even though dorkslayers.com is a registered and active domain.
It just has no name servers. 

So it seems they're doing this to billing-active domains as well.

On Tue, 16 Sep 2003, Sabri Berisha wrote:
> 
> On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote:
> > 
> > A wildcard A record in the net TLD.
> > 
> > $ host does.really-not-exist.net
> > does.really-not-exist.net has address 64.94.110.11
> > 
> > $ host 64.94.110.11
> > 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com
> 
> Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it 
> to a box and alias it on eth0. Put up a 404 not found and let Verisign
> rot in hell until such time as they regain their consiousness.
> 
> -- 
> Sabri Berisha "I route, therefore you are"
> 
> "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
> 

-- 
   /->
Marius Strom   | Always carry a short length of fibre-optic cable.
Professional Geek  | If you get lost, then you can drop it on the
System/Network Admin   | ground, wait 10 minutes, and ask the backhoe
http://www.marius.org/ | operator how to get back to civilization.
   \-| Alan Frame |-->

Re: What *are* they smoking?

[Haesu]

> Just noticed this: verisign is redirecting queries for dorkslayers.com's
> old RBL, even though dorkslayers.com is a registered and active domain.
> It just has no name servers. 

I must ask the subject again. What in the name of < censored > *are* they smoking? Who 
exclusively gave them the right to own the 'net and decide which domain points to 
where?

Completely unacceptable.

-hc

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

On Tue, Sep 16, 2003 at 10:37:35AM -0500, Marius Strom wrote:
> 
> 
> So it seems they're doing this to billing-active domains as well.
> 
> On Tue, 16 Sep 2003, Sabri Berisha wrote:
> > 
> > On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote:
> > > 
> > > A wildcard A record in the net TLD.
> > > 
> > > $ host does.really-not-exist.net
> > > does.really-not-exist.net has address 64.94.110.11
> > > 
> > > $ host 64.94.110.11
> > > 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com
> > 
> > Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it 
> > to a box and alias it on eth0. Put up a 404 not found and let Verisign
> > rot in hell until such time as they regain their consiousness.
> > 
> > -- 
> > Sabri Berisha   "I route, therefore you are"
> > 
> > "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
> > 
> 
> -- 
>/->
> Marius Strom   | Always carry a short length of fibre-optic cable.
> Professional Geek  | If you get lost, then you can drop it on the
> System/Network Admin   | ground, wait 10 minutes, and ask the backhoe
> http://www.marius.org/ | operator how to get back to civilization.
>\-| Alan Frame |-->

RE: What *are* they smoking?

[Matthew Kaufman]

And then Verisign starts using multiple IP addresses and rotating through
them. And then they stop giving any other clues that it is a wildcard
record. Great. Just what we need... To be in an escalating war with the
people running the root nameservers.

Since it is clearly in Verisign's business interest to make it impossible
for you to tell when you've been handed one of the wildcard replies, I don't
see this stopping any time soon.

Matthew Kaufman
[EMAIL PROTECTED]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Tomas Lund
> Sent: Monday, September 15, 2003 6:14 PM
> To: Chris Adams
> Cc: [EMAIL PROTECTED]
> Subject: Re: What *are* they smoking?
> 
> 
> 
> On Mon, 15 Sep 2003, Chris Adams wrote:
> 
> > It appears that the most reliable way to detect a wildcard response 
> > for 'somedomain.tld' is to query for '*.tld'; if the results match, 
> > then 'somedomain.tld' doesn't really exist.
> 
> Just make up a number of fake domains and resolve them. If 
> they return the same answer, thats the answer to change back 
> into NXDOMAIN.
> 
> //tlund
> 

Re: What *are* they smoking?

[Sabri Berisha]

On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote:
> 
> A wildcard A record in the net TLD.
> 
> $ host does.really-not-exist.net
> does.really-not-exist.net has address 64.94.110.11
> 
> $ host 64.94.110.11
> 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com

Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it 
to a box and alias it on eth0. Put up a 404 not found and let Verisign
rot in hell until such time as they regain their consiousness.

-- 
Sabri Berisha   "I route, therefore you are"

"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.

Re: What *are* they smoking?

[Mike Tancsa]

At 12:46 AM 16/09/2003, [EMAIL PROTECTED] wrote:
On Tue, 16 Sep 2003 14:31:53 +1000, Matthew Sullivan said:

> Worse than that - it's a fixed sequence of responses...
>
> $ telnet akdjflasdf.com 25
> Trying 64.94.110.11...
> Connected to akdjflasdf.com.
> Escape character is '^]'.
> 220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
> sdfg
> 250 OK
Well.. at least now we know how they *intended* to only affect HTTP traffic.
I am sure they will never create a list of email addresses based of the 
From: address to share with select partners.  After all, Verisign is an 
honorable company.

---Mike 

Re: What *are* they smoking?

[Karsten W. Rohrbach]

Miquel van Smoorenburg([EMAIL PROTECTED])@2003.09.16 08:43:26 +:
> 
> Oh yes, top of the line:
> 
[...]

Mike, even better: it's answering in an unconditional mode!

---
[EMAIL PROTECTED]:datasink[2]% telnet jhsdfajjkasfjkjkasf.net 25
Trying 64.94.110.11...
Connected to jhsdfajjkasfjkjkasf.net.
Escape character is '^]'.
220 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 ready
ehlo sucker
250 OK
mail from: [EMAIL PROTECTED]
250 OK
rcpt to: [EMAIL PROTECTED]
550 User domain does not exist.
data
250 OK
bla
221 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

[EMAIL PROTECTED]:datasink[2]% telnet jhsdfajjkasfjkjkasf.net 25
Trying 64.94.110.11...
Connected to jhsdfajjkasfjkjkasf.net.
Escape character is '^]'.
220 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 ready

250 OK

250 OK

550 User domain does not exist.

250 OK

221 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.
---

At least it leads to momentary amusement. Mad scientists or
propellerheads at work there?

/k

-- 
> Beware of bugs in the above code; I have only proved it correct, not
> tried it. --Donald Knuth
webmonster.de -- InterNetWorkTogether -- built on the open source platform
http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/
GnuPG:   0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4  A113 B393 6BF4 DEC9 48A6
Please do not remove my address from To: and Cc: fields in mailing lists. 10x

Fwd: Re: Patching BIND (Re: What *are* they smoking?)

[Mark Vevers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 16 Sep 2003 6:41 am, John Brown wrote:
> we've burned a AS for this, ICK

Yup - and 2 /24's 

#show ip bgp regexp _30060$
   Network  Next HopMetric LocPrf Weight Path
*>i12.158.80.0/24   xxx.xxx.xxx.xxx 305100  0 1239 7018 26134
 30060 ? *>i64.94.110.0/24   xxx.xxx.xxx.xxx   305100  0 1239
 7018 26134 30060 ?

> based on the ASNAME, its seems a nice little route-map
> /dev/null will be real easy.  As long as they keep prefixs
> used in this really dumb idea for this idea.

If you have a full table (i.e. no default) just drop inbound routes with a
AS path _30060$

Also 

@dns0:/var/named/verisignwildcard#host 64.94.110.11
Host 11.110.94.64.in-addr.arpa not found: 3(NXDOMAIN)

Oh dear, I wonder what happened to the reverse . looks like that doesn't
resolve any more from here ;-)  ... so we can still do reverse DNS checks

Mark
- -- 
Mark Vevers.[EMAIL PROTECTED] / [EMAIL PROTECTED]
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
- --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB08F3CA3
Fingerprint: 85BA 30C4 9EC8 1792 4C8C   C31E 58B5 3D1C B08F 3CA3
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/ZtFGWLU9HLCPPKMRApqHAJwJAxEbkUmKfUsuK4lOrrs5izPaRgCfePsT
b0klVYOObpWZqQZIUd3TrJk=
=gb31
-END PGP SIGNATURE-

Re: What *are* they smoking?

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Christopher X. Candreva <[EMAIL PROTECTED]> wrote:
>This also blows away the whole idea of rejeting mail from non-existant
>domains -- never mind all the bounces to these non-existant domains when the
>spammers get ahold of them. Boy, I hope they have a good mail server
>responding with the 550 on that IP !

Oh yes, top of the line:

$ telnet ariekanariebla.net 25
Trying 64.94.110.11...
Connected to sitefinder-idn.verisign.com.
Escape character is '^]'.
220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready
syntaxerror
250 OK
quit
221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

Mike.
-- 
The big problem with blacksmithing resumes is that most of them are forged.
-- Joe Marshall

Re: What *are* they smoking?

[Mans Nilsson]

Subject: Re: What *are* they smoking? Date: Tue, Sep 16, 2003 at 03:13:49AM +0200 
Quoting Tomas Lund ([EMAIL PROTECTED]):
> 
> On Mon, 15 Sep 2003, Chris Adams wrote:
> 
> > It appears that the most reliable way to detect a wildcard response for
> > 'somedomain.tld' is to query for '*.tld'; if the results match, then
> > 'somedomain.tld' doesn't really exist.
> 
> Just make up a number of fake domains and resolve them. If they return the
> same answer, thats the answer to change back into NXDOMAIN.

More precise: 

dig @ns.nic.nu. '*.nu' ANY

The quotes mean that the string '*.nu' will be passed straight to
the name server.
-- 
Måns Nilsson Systems Specialist
+46 70 681 7204 KTHNOC
MN1334-RIPE

I'm EMOTIONAL now because I have MERCHANDISING CLOUT!!


pgp0.pgp
Description: PGP signature

Re: What *are* they smoking?

[Nathan J. Mehl]

In the immortal words of Wayne E. Bouchard ([EMAIL PROTECTED]):
> So then now instead of mail to misspelled domains, instead of
> bouncing, now goes to /dev/null and you have no idea that your
> critically important piece of information didn't get through?

You _hope_ it goes to /dev/null.

It might be interesting to seed a few pieces of "accidentally" typo'ed
mail to .net domains and see how many of the "From" addresses get
sales email from Verisign in the coming year.

And I'm sure that the Department of Homeland Security would not be
even slightly interested in performing signal analysis on the vast
majority of mis-typed emails in this and most other countries.

Interesting times.

-n

---<[EMAIL PROTECTED]>
 "So perhaps the factor constraining the Internet's growth is "good taste."
   (--Paul Vixie)
---

Re: Patching BIND (Re: What *are* they smoking?)

[E.B. Dreger]

EBD> Date: Tue, 16 Sep 2003 05:32:50 + (GMT)
EBD> From: E.B. Dreger


EBD> I'd actually go for keeping the A RR for '*.net.' and
EBD> '*.com.' in an authoritative NS's cache.  If any other A RR

s,authoritative,resolver,


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: Patching BIND (Re: What *are* they smoking?)

[John Brown]

On Tue, Sep 16, 2003 at 05:32:50AM +, E.B. Dreger wrote:
> 
> Until then, I guess it's time to null route and check for
> circumvention.  Is AS30060 used for anything legitimate?

we've burned a AS for this, ICK

based on the ASNAME, its seems a nice little route-map
/dev/null will be real easy.  As long as they keep prefixs
used in this really dumb idea for this idea.



OrgName:VeriSign Infrastructure & Operations
OrgID:  VIO-2
Address:21345 Ridgetop Circle
City:   Dulles
StateProv:  VA
PostalCode: 20166
Country:US
 
ASNumber:   30060
ASName: WILDCARD-VERISIGN
ASHandle:   AS30060
Comment:
RegDate:2003-07-10
Updated:2003-07-10
 
TechHandle: AH678-ARIN
TechName:   Herrmann, Andrew
TechPhone:  +1-703-948-
TechEmail:  [EMAIL PROTECTED]
 
OrgTechHandle: AH678-ARIN
OrgTechName:   Herrmann, Andrew
OrgTechPhone:  +1-703-948-
OrgTechEmail:  [EMAIL PROTECTED]

Patching BIND (Re: What *are* they smoking?)

[E.B. Dreger]

PWG> Date: Mon, 15 Sep 2003 19:40:33 -0400
PWG> From: Patrick W. Gilmore


PWG> Anyone wanna patch BIND such that replies of that IP addy
PWG> are replaced with NXDOMAIN?  That solves the web site and
PWG> the spam problem, and all others, all at once.

I'd actually go for keeping the A RR for '*.net.' and '*.com.' in
an authoritative NS's cache.  If any other A RR matches the
cached IP address(es), nuke the RRSet and replace with NXDOMAIN.

Until then, I guess it's time to null route and check for
circumvention.  Is AS30060 used for anything legitimate?


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: What *are* they smoking?

[Valdis . Kletnieks]

On Tue, 16 Sep 2003 14:31:53 +1000, Matthew Sullivan said:

> Worse than that - it's a fixed sequence of responses...
> 
> $ telnet akdjflasdf.com 25
> Trying 64.94.110.11...
> Connected to akdjflasdf.com.
> Escape character is '^]'.
> 220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
> sdfg
> 250 OK

Well.. at least now we know how they *intended* to only affect HTTP traffic.


pgp0.pgp
Description: PGP signature

Re: What *are* they smoking?

[Matthew Sullivan]

Patrick W. Gilmore wrote:

-- On Tuesday, September 16, 2003 00:56 +0200
-- Niels Bakker <[EMAIL PROTECTED]> supposedly wrote:
A wildcard A record in the net TLD.

$ host does.really-not-exist.net
does.really-not-exist.net has address 64.94.110.11
$ host 64.94.110.11
11.110.94.64.IN-ADDR.ARPA domain name pointer 
sitefinder-idn.verisign.com

It even responds on port 25 (says 550 on every RCPT TO).  Gah.


No, it accepts if the from domain exists - but only if it *REALLY* 
exists.

[...]
rcpt to: [EMAIL PROTECTED]
250 OK
mail from: [EMAIL PROTECTED]
550 User domain does not exist.
mail from: [EMAIL PROTECTED]
250 OK
Nice that their spam filters still work. :(

And I love the 221 close message:

data
221 snubby1-wcwest Snubby Mail Rejector Daemon v1.3 closing 
transmission channel
Connection closed by foreign host.

Worse than that - it's a fixed sequence of responses...

$ telnet akdjflasdf.com 25
Trying 64.94.110.11...
Connected to akdjflasdf.com.
Escape character is '^]'.
220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
sdfg
250 OK
sdfgsdfgsdfgsdf
250 OK
sdfgdfgaegqaergqaergvav
550 User domain does not exist.
asdfgasdfgasdf
250 OK
sdfasdfadsfasdf
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission 
channel
Connection closed by foreign host.

/ Mat

Re: What *are* they smoking?

[David Lesher]

Speaking on Deep Background, the Press Secretary whispered:
> 
> 
> 
> I abandoned them a long time ago, but the big question is, how
> can we get rid of them as root servers operators?  Sounds like
> time to push for more independent servers, and a truly separate
> company to handle the root server portion of .com/.net.  They
> could still exist as a registrar, but with these kind of business
> practices, how long?  Probably not very, so I'd expect them to
> fight it tooth and nail.

Point out to Herr Ashcroft that they are "supporting pron" by
selling domain names. 

Or have pictures of their lobbyist passing out money to
GOP HillCritters.

Failing that, rotsaruck. They have the money to spread around.

Hmm, here's an idea -- can we play them off against the $cientology
Cult somehow? That would be a good T-Rex vs Raptor fight to watch!



-- 
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433

Re: What *are* they smoking?

[Greg Maxwell]

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

> This is sufficiently technically and business slimy that
> I would null-route that IP, personally.

Or direct it to a local server and collect the profit yourself.

Re: What *are* they smoking?

[mike harrison]

> Yep, and it'll be coming soon to .com.  All your typo domain are belong
> to Verisign.

Ever get tempted to have a 'wet ops' NANOG team?

RE: What *are* they smoking?

[John Ferriby]

There was an article, easily overlooked, in the NY Times this
morning.  Link below. (free, registration required.)

http://www.nytimes.com/2003/09/15/technology/15MISS.html

This action does call into question Verisign's ability
to operate with public, nee international, infrastructure
interests.   In my opinion Verisign has demonstrated that
they are no longer capable of maintaining its custody of
of these TLDs.

Re: What *are* they smoking?

[Marc Slemko]

On Mon, 15 Sep 2003, Alex Lambert wrote:

> "The information provided through the VeriSign Services is not
> necessarily complete and may be supplied by VeriSign's commericial
> licensors, advertisers or others."
>
> There's something immoral about *shoving it down our throats*, then,
> VeriSign.

Nice terms of service at http://sitefinder.verisign.com/terms.jsp :

The VeriSign Services are provided only for your personal and
non-commercial use. You are not authorized to modify, copy, display,
transmit, license, create derivative works from, transfer, distribute
or sell any information, software, products or services obtained
from the services VeriSign provides through this web site. You may
not "meta-search" the VeriSign Services. If you want to make
commercial use of the VeriSign Services, you must enter into an
agreement with us to do so in advance.

so... umh... I can't display any information from their website.

And can only use it for non-commercial use.

So... if I make a DNS query for some "commercial" purpose (whatever that
means), and get a response and then connect to that IP on port 80
and send a request, and get a redirect to this sitefinder.verisign.com
site, and follow it...  I'm violating their terms of use.

Does the contract under which NSI is operating .com and .net require that
people be able to use the results of their queries for non-personal and
commercial use?  It is a little fuzzy how directly you can relate the DNS
response to the terms of use on the website you get redirected to on the
legal level, but it seems that since Verisign is operating it with the
intent that people entering unknown domains into a webbrowser get
redirected there, then they are by implication stating that people doing
things for non-personal or commercial purposes must never enter such
names.

Sure, it is a ridiculous terms of use that wouldn't be likely to hold up
very well, but would the fact that they are making that claim have any
implication on if they are meeting the stated or implied terms of their
contract with ICANN?

Re: What *are* they smoking?

[Wayne E. Bouchard]

So then now instead of mail to misspelled domains, instead of
bouncing, now goes to /dev/null and you have no idea that your
critically important piece of information didn't get through?

Neat.

On Mon, Sep 15, 2003 at 08:17:43PM -0500, netmask wrote:
> 
> > - Original Message -
> > From: "Patrick W. Gilmore" <[EMAIL PROTECTED]>
> > Date: Monday, September 15, 2003 7:34 pm
> > Subject: Re: What *are* they smoking?
> >
> > >
> > > No, it accepts if the from domain exists - but only if it *REALLY*
> > > exists.
> >
> > Anyone want to guess what happens to all those from addresses it captures?
> 
> No doubt.. It's unfortunate that they are running a daemon on port 25 on that
> box..  and that it actually lets you helo and mail from.. and not until you
> get to rcpt to  does it reject.. unless you use a domain its now got cached
> in which case it accepts the to: and closes at data. (So, if you rcpt twice,
> it'll accept it.. cuz like everyone else, its own dns server resolves
> everything)
> 
> [EMAIL PROTECTED] netmask]$ telnet www.oisdufoisdufoisuf.com 25
> Trying 64.94.110.11...
> Connected to www.oisdufoisdufoisuf.com.
> 
> 220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready
> 
> helo ishouldntresolvebutthankstoyouido.com
> 250 OK
> 
> mail from: <[EMAIL PROTECTED]>
> 250 OK
> 
> rcpt to: <[EMAIL PROTECTED]>
> 550 User domain does not exist.
> 
> rcpt to: <[EMAIL PROTECTED]>
> 250 OK
> 
> data
> 221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission
> channel
> 

---
Wayne Bouchard
[EMAIL PROTECTED]
Network Dude
http://www.typo.org/~web/


pgp0.pgp
Description: PGP signature

Re: What *are* they smoking?

[Steven M. Bellovin]

It's bad enough now; it could be even worse.  They could respond on 
port 443, too, with a legitimate-seeming certificate -- they're 
*Verisign*, the leading certficate authority.

In the security world, we call this a man- (or monkey-)in-the-middle
attack, for which the standard defense is crypto.  But that doesn't 
work well when your trusted third party is part of the threat model...


--Steve Bellovin, http://www.research.att.com/~smb

Re: What *are* they smoking?

[Aaron Dewell]

I abandoned them a long time ago, but the big question is, how
can we get rid of them as root servers operators?  Sounds like
time to push for more independent servers, and a truly separate
company to handle the root server portion of .com/.net.  They
could still exist as a registrar, but with these kind of business
practices, how long?  Probably not very, so I'd expect them to
fight it tooth and nail.

Or abandon .com/.net entirely, but that would take a long time
and a massive public-education campaign.  See what happens to
them when everyone refuses to use either .com or .net.  I still
use them, by way of OpenSRS, but that could be solved with some
new registrations with a non-hostile TLD operator.

Aaron

On Mon, 15 Sep 2003, Alex Lambert wrote:
 > http://www.verisign.com/corporate/about/contact/index.html
 >
 > Give 'em hell.
 >
 >
 >
 > apl

Re: What *are* they smoking?

[David B Harris]

On Mon, 15 Sep 2003 17:45:26 -0700
Fred Baker <[EMAIL PROTECTED]> wrote:
> At 04:18 PM 9/15/2003, Jeroen Massar wrote:
> >Even worse of this is that you can't verify domain names under .net
> >any more for 'existence' as every .net domain suddenly has a A record
> >and then can be used for spamming...
> 
> so, every spammer in the world spams versign. The down side of this is ... 
> what? I don't remember... 

The problem is the (common) method of invalidating spam mails by
checking that the originating domain exists. If said domain is .net (and
soon .com), that check will no longer be useful.


pgp0.pgp
Description: PGP signature

RE: What *are* they smoking?

[Tomas Lund]

On Tue, 16 Sep 2003, Johnny Eriksson wrote:

> idea for next virus: after reproducing itself, construct a random domain
> name ending in .net and ddos it at a low rate for a day or so.  if the
> faked up domain is someones real one, you get a small number of packets
> to that domain.  if a large number of domains resolve to the same ip,
> well, too bad for that ip...
>
> that might even be a virus a lot of people want to run.

while [ - ] ; do lynx -dump http://$RANDOM.THIS-QUERY-SHOULD-RETURN-NXDOMAIN.NET > 
/dev/null ; done

//tlund

Re: What *are* they smoking?

[Alex Lambert]

"The information provided through the VeriSign Services is not 
necessarily complete and may be supplied by VeriSign's commericial 
licensors, advertisers or others."

There's something immoral about *shoving it down our throats*, then, 
VeriSign.



apl

Adam 'Starblazer' Romberg wrote:
Can they realistically enforce a TOS on a site like that, and how can they
provide a remedy for it?
I, for one, do not agree to their terms of service.

Thanks

-a-


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

Re: What *are* they smoking?

[Tomas Lund]

On Mon, 15 Sep 2003, Chris Adams wrote:

> It appears that the most reliable way to detect a wildcard response for
> 'somedomain.tld' is to query for '*.tld'; if the results match, then
> 'somedomain.tld' doesn't really exist.

Just make up a number of fake domains and resolve them. If they return the
same answer, thats the answer to change back into NXDOMAIN.

//tlund

Re: What *are* they smoking?

[Kevin Loch]

- Original Message -
From: "Patrick W. Gilmore" <[EMAIL PROTECTED]>
Date: Monday, September 15, 2003 7:34 pm
Subject: Re: What *are* they smoking?

> 
> No, it accepts if the from domain exists - but only if it *REALLY* 
> exists.

Anyone want to guess what happens to all those from addresses it captures?

RE: What *are* they smoking?

[Fred Baker]

At 04:18 PM 9/15/2003, Jeroen Massar wrote:
Even worse of this is that you can't verify domain names under .net
any more for 'existence' as every .net domain suddenly has a A record
and then can be used for spamming...
so, every spammer in the world spams versign. The down side of this is ... 
what? I don't remember... 

Re: What *are* they smoking?

[Chris Adams]

FYI: A quick look shows 14 TLDs that appear to have wildcard records:

ac
cc
com
cx
mp
museum
net
nu
ph
pw
sh
tk
tm
ws

The following TLDs answer for '*.tld' but do not appear to have wildcard
records:

bz
cn
tw

It appears that the most reliable way to detect a wildcard response for
'somedomain.tld' is to query for '*.tld'; if the results match, then
'somedomain.tld' doesn't really exist.

-- 
Chris Adams <[EMAIL PROTECTED]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: What *are* they smoking?

[Alex Lambert]

http://www.verisign.com/corporate/about/contact/index.html

Give 'em hell.



apl

Niels Bakker wrote:
A wildcard A record in the net TLD.

$ host does.really-not-exist.net
does.really-not-exist.net has address 64.94.110.11
$ host 64.94.110.11
11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com
It even responds on port 25 (says 550 on every RCPT TO).  Gah.

	-- Niels.

RE: What *are* they smoking?

[Johnny Eriksson]

"Jeroen Massar" <[EMAIL PROTECTED]> wrote:

> Any kiddie group already planning to "take down" the advert server ?
> It's just 1 IP to take out a *lot* of domains, anything you can mistype ;)
> "Look mommy we took down .net, now you see it now you..."

idea for next virus: after reproducing itself, construct a random domain
name ending in .net and ddos it at a low rate for a day or so.  if the
faked up domain is someones real one, you get a small number of packets
to that domain.  if a large number of domains resolve to the same ip,
well, too bad for that ip...

that might even be a virus a lot of people want to run.

--Johnny

RE: What *are* they smoking?

[Adam 'Starblazer' Romberg]

Can they realistically enforce a TOS on a site like that, and how can they
provide a remedy for it?

I, for one, do not agree to their terms of service.

Thanks

-a-


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