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
* [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
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
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
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.
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
]
[EMAIL PROTECTED]cc:
m Subject: Re: Root Server Operators
(Re: What *are* they smoking?)
Sent
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
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 ipaddr
*.com. IN NS
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
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 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
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
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
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
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
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
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
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
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
]
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
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
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
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
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... ;)
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
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
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. [-]
Just came across this:
http://www.washingtonpost.com/wp-dyn/articles/A996-2003Sep12.html
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
http://www.iab.org/Documents/icann-vgrs-response.html
[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
--
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.
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.
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
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
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
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,
[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.
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
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
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
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
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
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
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
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
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
48 matches
Mail list logo
