Thus spake "Gordon Cook" <[EMAIL PROTECTED]>
> The point I am making in my report is NOT that the best effort
> network has technology problems but rather that it has ECONOMIC
> PROBLEMS. That it might support 2 or 3 players not 2 or 3 HUNDRED.
> That until compani
I don't see the correlation between settlements, profitability and
level-of-service.
-joe
Christopher J. Wolff wrote:
Folks,
This is a great discussion. I'm interested in understanding these types of
limitations in the context of HFC cable networks. In my opinion, HDTV
channel bandwidth (30mhz?) , increased demand for voip, and growing demand
for IP connectivity is going to stress the
Folks,
This is a great discussion. I'm interested in understanding these types of
limitations in the context of HFC cable networks. In my opinion, HDTV
channel bandwidth (30mhz?) , increased demand for voip, and growing demand
for IP connectivity is going to stress the cable network model as we
On Sat, 29 May 2004, Eric Kuhnke wrote:
> When 12016s are on ebay for $12,000, even a low budget "tier 3" can
> afford proper routing gear... It's not as if the Internet is still
> powered by 7507s! (Well, a large part still is. :-)
12016 will only do OC48 speeds and the OC48 cards that use
network has technology problems but rather that it has
GC> ECONOMIC PROBLEMS. That it might support 2 or 3 players not
GC> 2 or 3 HUNDRED.
Best effort is cheaper to provide. Cheaper sells. Is there
enough of a market to sustain premium services? IP-based VPNs
haven't replaced FR and Pt
GC> Date: Sat, 29 May 2004 16:53:17 -0400
GC> From: Gordon Cook
GC> The point I am making in my report is NOT that the best
GC> effort network has technology problems but rather that it has
GC> ECONOMIC PROBLEMS. That it might support 2 or 3 players not
GC> 2 or 3 HUNDRE
Tier 1 operators do not do "best effort" really, at least not in their
cores (and they have the SLAs to back it up). They buy hugely expensive
top notch gear (Cisco 12000 (and now CRS:s) and Junipers) to get the big
packet buffers, the fast reroutes and the full routing table lookups for
each pack
On Sat, 29 May 2004, Gordon Cook wrote:
> discussing. We don't pretend that QoS is easy or any kind of mature
> collection of technologies, but increasingly it looks as though the
Tier 1 operators do not do "best effort" really, at least not in their
cores (and they have the SLAs to back it u
etwork has technology problems but rather that it has ECONOMIC
PROBLEMS. That it might support 2 or 3 players not 2 or 3 HUNDRED.
That until companies begin to go chapter seven and vanish, the best
effort net will be a black hole that burns up capital because, for
many players, the OPERATIONAL expen
On Sat, 29 May 2004, Edward B. Dreger wrote:
> Nitpicking: Latency isn't that important with unidirectional
> communication. However, VoIP users seem reasonably happy with
> current latency and jitter -- and the Internet still is _largely_
> xxTP, anyway... particularly if one ignores peer-to-p
MC> Date: Sat, 29 May 2004 14:26:01 -0400
MC> From: Matthew Crocker
MC> The PSTN does guarantee a certain service level, latency,
MC> call completion etc.
As do many Internet providers. (s/call completion/packet loss/)
MC> Latency & Jitter are very important when dealing with sound &
MC> vid
The PSTN doesn't offer guaranteed end-to-end transmission, and
certainly statmuxes based on expected load. Looks like similar
capacity planning.
The PSTN does guarantee a certain service level, latency, call
completion etc.
Perhaps you refer to latency. Most people don't care as long as
HTTP a
GC> Date: Fri, 28 May 2004 15:58:06 -0400
GC> From: Gordon Cook
GC> I published a two month issue last weekend with the bottom
GC> line conclusion that there can be no telecom recovery as
GC> long as the industry relies solely on the best effort
GC> business model which I believe is not economic
On 28-mei-04, at 21:58, Gordon Cook wrote:
I published a two month issue last weekend with the bottom line
conclusion that there can be no telecom recovery as long as the
industry relies solely on the best effort business model which I
believe is not economically sustainable.
I fail to see how t
Greetings Nanogers,
I published a two month issue last weekend with the bottom line
conclusion that there can be no telecom recovery as long as the
industry relies solely on the best effort business model which I
believe is not economically sustainable.
This has led to two articles on my June-J
FYI, might as well be aware
Norton Internet Security has evidently installed a
new feature that pre-scans the inline html images prior to writing the
images to the temp dir and displaying them in the web-browser. This is
a good thing, right? Maybe or maybe not, as it is purportedly to prote
In article <[EMAIL PROTECTED]>, Hank
Nussbacher <[EMAIL PROTECTED]> writes
We are sorry that you are experiencing delay in receiving messages at
your hotmail.com or msn.com email address. Yahoo! has contacted MSN and
has determined that the source of the problem resides on their end.
They are a
On 05/19/04, Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> Anyone know more?
Things looked better today, but past experience shows that they
may get awful again in a few days. While the problem may appear
to be more on our (Hotmail's) end than Yahoo's, the volume of
http://help.yahoo.com/help/us/groups/messages/messages-19.html
Attention Hotmail and MSN users
Hotmail and MSN mail users are currently experiencing delays of up to 1 day
in receiving Groups messages. If delays exceed this, we may begin to not
deliver older messages.
We are sorry that you are ex
Anyone else seeing problems with packets going between ATT and L3? Just
starting a few minutes ago (looks like the problem is in their Dallas
peering point)
If you're in a position to do something about it and need more info,
drop me a line and I'll get you traceroute's, I
[about new cables laid by FLAG and SEA-ME-WE-4]
--
suresh ramasubramanian [EMAIL PROTECTED] gpg EDEDEFB9
manager, security and antispam operations, outblaze ltd
http://www.nytimes.com/2004/05/10/business/10cable.html?th=&pagewanted=all&position=
New Undersea Cable Projects Face Some Old
At 01:26 PM 05/05/2004, [EMAIL PROTECTED] wrote:
On Wed, 05 May 2004 10:59:55 EDT, Mike Tancsa <[EMAIL PROTECTED]> said:
> Anyone else seeing Yahoo mail queue up today ?Some of their servers
> respond in about 10secs with the HELO banner, most others take more than
> 2m. Because of the recen
On Wed, 05 May 2004 10:59:55 EDT, Mike Tancsa <[EMAIL PROTECTED]> said:
> Anyone else seeing Yahoo mail queue up today ?Some of their servers
> respond in about 10secs with the HELO banner, most others take more than
> 2m. Because of the recent increase in SPAM, I was looking to reduce th
Anyone else seeing Yahoo mail queue up today ?Some of their servers
respond in about 10secs with the HELO banner, most others take more than
2m. Because of the recent increase in SPAM, I was looking to reduce the
wait time for the initial HELO to 2m from 5m. However, the RFC calls for 5m
I am not a direct customer of either of them, but have a lot of endpont
sites in Quebec which go through 6543 and 577. Anyone from either of those
networks know whats up ? Since we usually go through Chicago to reach
them, this is the only reason we noticed. There are other prefixes
involv
--On 30 March 2004 07:08 -0500 [EMAIL PROTECTED] wrote:
Yesterday we starting noticing long delays on an ADSL connection
I am betting you are running ping under linux. There is some linux bugette
(I think cosmetic) that occasionally causes Linux to count down
(effectively) 9, 8, 7, 6, 5, 4, 3, 2
On Tue, 30 Mar 2004, Stewart, William C (Bill), RTSLS wrote:
> > ping did _this_
> Ping is not very informative or accurate.
> If you run a traceroute, which is also not very accurate,
Get the best of both tools and use mtr (assuming unix-like platform).
There are similar tools for windows (ping
> ping did _this_
Ping is not very informative or accurate.
If you run a traceroute, which is also not very accurate,
you can get some idea about where the delay appears to be.
Is it the DSL segment? Is it somewhere else that traceroute can show you?
The nice thing about delays that are this l
On Tue, 30 Mar 2004, Joe Maimon wrote:
: [EMAIL PROTECTED] wrote:
: >Greetings NANOGers,
: >
: >Yesterday we starting noticing long delays on an ADSL connection.
:
: Assuming it is not your ISP or that the telco is the ISP.
: Dont believe them. Tell them to reset the port. Tell them to change t
> DSL BENCHMARK:
> ==
> ATU-R (DS) ATU-C (US)
> Capacity Used: 72% 21%
>
> Interleave FastInterleave
Fast
> Speed (kbps): 0 960 0
256
> Reed-Solomon
ilto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, March 30, 2004 6:08 AM
> To: [EMAIL PROTECTED]
> Subject: DSL and/or Routing Problems
>
>
> Greetings NANOGers,
>
> Yesterday we starting noticing long delays on an ADSL connection. I spent most
>
[EMAIL PROTECTED] wrote:
Greetings NANOGers,
Yesterday we starting noticing long delays on an ADSL connection.
Assuming it is not your ISP or that the telco is the ISP.
Dont believe them. Tell them to reset the port. Tell them to change the
pairs. Tell them to switch your line to a diffe
[EMAIL PROTECTED] wrote:
This connection uses a Cisco 827 ADSL router and has several static IPs. All IPs
show identical delays. Using other circuits between the same two locations, we
do not see any delays.
What's the weather like? ;-)
See if you can get the ADSL router to give you upstream/d
restart the ping (that's why I provided 2 samples)?
Despite the fact that Telco says there are not any line problems, we are seeing
a change in DSL performance compared to our benchmark. When we first started
noticing the problem yesterday, both in and out connections were using the Fast
On Wed, 24 Mar 2004 17:18:11 GMT, "Christopher L. Morrow" said:
> sometimes this is OVW going on a discovery rampage, quite a few folks
> forget to set the scope before telling it to discover :(
I did mention the clue-by-four, right? :)
pgp0.pgp
Description: PGP signature
On Mar 24, 2004, at 12:18 PM, Christopher L. Morrow wrote:
On Wed, 24 Mar 2004 [EMAIL PROTECTED] wrote:
On Wed, 24 Mar 2004 17:58:27 +0100, Erik Haagsman said:
It is...and persistently trying a host of SNMP communitie strings on
a
neighbour's router interfaces doesn't make it any better :-)
Try
On Wed, 24 Mar 2004 [EMAIL PROTECTED] wrote:
> On Wed, 24 Mar 2004 17:58:27 +0100, Erik Haagsman said:
>
> > It is...and persistently trying a host of SNMP communitie strings on a
> > neighbour's router interfaces doesn't make it any better :-)
>
> Trying once is one thing. Being persistent abo
On Wed, 24 Mar 2004 17:58:27 +0100, Erik Haagsman said:
> It is...and persistently trying a host of SNMP communitie strings on a
> neighbour's router interfaces doesn't make it any better :-)
Trying once is one thing. Being persistent about it when it didn't work the
first time deserves a smack
On Wed, 2004-03-24 at 16:57, Paul G wrote:
> slightly OT, but it is a sad day when operators stop being responsible
> neighbours and start responding to abuse reports only when their
> {willy,peering} is on the line.
It is...and persistently trying a host of SNMP communitie strings on a
neighbour
- Original Message -
From: "Erik Haagsman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, March 24, 2004 10:55 AM
Subject: Re: Problems with .de abuse
>
>
> > I sent the abuse email 2 days ago and got no res
one who speaks or
> reads/writes English)?
Try and reach them at [EMAIL PROTECTED] or try and contact their admin
Jens Rosenboom at [EMAIL PROTECTED]
I know it's not the regular channel, but and we peer with them at
DE-CIX and had similar problems a while back with IP's from their rang
On Wed, 24 Mar 2004 [EMAIL PROTECTED] wrote:
> over the past couple of days, at least two of our servers have been
> inundated with rather amateurish attempts to login as various priviledged
> users.
I would check out the other roles referenced in the AS5430 object and
failing that perhaps someo
over the past couple of days, at least two of our servers have been
inundated with rather amateurish attempts to login as various priviledged
users. We're talking at least hundreds of attempts, mostly from 62.104.92
and 62.104.82. I whois shows the /16 (which I finally null routed the
whole thi
taking a long time). After a bit of narrowing down, it would seem that
when the traffic comes at me via C&W from Bell (2 of my 3 transit
providers 852 and 6539 talk to parts of Bell this way) the problems are acute.
Looking at traceroutes between C&W and Bell IP space, there does ind
r a bit of narrowing down, it
would seem that when the traffic comes at me via C&W from Bell (2 of
my 3 transit providers 852 and 6539 talk to parts of Bell this way)
the problems are acute.
Looking at traceroutes between C&W and Bell IP space, there does
indeed seem to be some issue between th
ders 852 and
6539 talk to parts of Bell this way) the problems are acute.
Looking at traceroutes between C&W and Bell IP space, there does indeed
seem to be some issue between their exchange point in NY
The 2 snippets being
From bell to cw
6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108
Good question. I've been seeing similar results command line, and
additionally I've noted some problems with the web-based whois as well.
/Alex Kiwerski
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Jon R. Kibler
Sent: Friday, February 20, 200
Anyone know what is up with whois.internic.net? It seems to be having serious problems.
When using a command line whois, it either hangs "forever" or gets a connection
refused.
About 1 time in 5 can I get a query to work. I have tried it from both our local
systems
and a hosted ser
Looks like a problem with the first CW router in the path (hop 10) or
somewhere on it's path back to you, not reproducible this morning.
No congestion between ATDN and CW on that link last night. As for
contacts, it's appropriate you call your RR technical support.
However, ATDN issues can be r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Could a clueful person at ATDN (I've totally given up on Tech Support
who seem to think it's an Internet Explorer issue...) tell me who I'm to
call to get sensible technical support? :)
I don't think this is an issue clearning my IE cache will resolve:
SR> Date: Sat, 17 Jan 2004 08:24:06 +0530
SR> From: Suresh Ramasubramanian
SR> AOL has, since the past several months (over a year I think)
SR> set up their dynamic IP pool *.ipt.aol.com to hijack port 25
I recall seeing this in November 2002, and believe it had already
been in place for a few
Suresh Ramasubramanian wrote:
Sean Donelan [1/17/2004 9:20 AM] :
True, but it appears AOL has cranked something up in the last couple
of weeks or something is choking more often. If you look at various
places where users like to gripe, you'll notice an uptick of queries
and complaints on the su
Sean Donelan [1/17/2004 9:20 AM] :
True, but it appears AOL has cranked something up in the last couple
of weeks or something is choking more often. If you look at various
places where users like to gripe, you'll notice an uptick of queries
and complaints on the subject.
Maybe they finally rolle
On Sat, 17 Jan 2004, Suresh Ramasubramanian wrote:
> You just noticed this now?
>
> AOL has, since the past several months (over a year I think) set up
> their dynamic IP pool *.ipt.aol.com to hijack port 25 outbound requests
> and reroute it through a set of their own mailservers, that do some
>
Christopher X. Candreva [1/17/2004 5:02 AM] :
On Fri, 16 Jan 2004, Ajai Khattri wrote:
I have several users who connect to our mail server from an IP in the
*.ipt.aol.com namespace. All are complaining about intermittent SMTP problems.
I see that outbound SMTP traffic is proxied through AOL
On Fri, 16 Jan 2004, Ajai Khattri wrote:
> I have several users who connect to our mail server from an IP in the
> *.ipt.aol.com namespace. All are complaining about intermittent SMTP problems.
> I see that outbound SMTP traffic is proxied through AOL servers to our mail
> server
I have several users who connect to our mail server from an IP in the
*.ipt.aol.com namespace. All are complaining about intermittent SMTP problems.
I see that outbound SMTP traffic is proxied through AOL servers to our mail
servers. Has there been a change recently causing this to not work?
Our
Never mind; either it fixed itself or someone fixed the routing table.
All is well, nothing to see here, move along.
On Tue, 23 Dec 2003, Marius Strom wrote:
> Any cox.net folks around this evening?
>
> Seems packets from various cox.net terminated sites to AT&T address
> space (12.0.0.0/8) is g
Any cox.net folks around this evening?
Seems packets from various cox.net terminated sites to AT&T address
space (12.0.0.0/8) is going to Singtel.net out of Singapore. Singtel.net
is not permitting transit.
Partial MTR below:
2. bcstbbrc01-vln30.ma.dl.cox-internet0%1111 11
C] [intermediate B]
> / \
> [ISP A] [ISP B]
>
> and if the problems is with intermediate C, I'm probably SOL. Clearly, I
> would want my ISP to insist that his upstream providers not allow such
> unrelia
rovider A] [backbone provider B]
/ \ /\
[intermediate A] [intermediate C] [intermediate B]
/ \
[ISP A] [ISP B]
and if the problems is with intermediate C, I'm probably SOL. Clearly, I
would
On Wed, 26 Nov 2003, Arjan Hulsebos wrote:
> The Netherlands were hit as well. We saw a massive flood of queries for
> lockup.zonelabs.com, too. It performed a nice DoS on our client name
> servers :-(
>
> You'd think that an unresponsive nameserver would be flagged dead, and such
> informatio
On Wed, Nov 26, 2003 at 11:31:32AM -0700, Duane Wessels wrote:
> In my simulations with 100% packet loss, DNS caches running BIND8,
> dnscache, W2000, and W2003 all amplified the user's query rates.
> Only BIND9 attenuated.
pdns_recursor also throttles queries, see http://doc.powerdns.com/x2025.
> You'd think that an unresponsive nameserver would be flagged dead, and such
> information be cached. Does anyone know whether that's actually done in Bind
> 8.3.4? Or perhaps not by default?
This certainly does not happen when all authoritative nameservers
are unresponsive. See http://www.nano
Title: RE: Above.net problems ??
> Is there any relationship between this "europeanwide"
> above.net failure and the huge amount of
> DNS requests to lockup.zonelabs.com which failed that every
> ISP (at least in France) seem to
> have encountered last night ?
&
In a message written on Wed, Nov 26, 2003 at 05:39:33PM +0100, Jerome Fleury wrote:
> Is there any relationship between this "europeanwide" above.net failure and the huge
> amount of
> DNS requests to lockup.zonelabs.com which failed that every ISP (at least in France)
> seem to
> have encountere
Hi there.
Is there any relationship between this "europeanwide" above.net failure and the huge
amount of
DNS requests to lockup.zonelabs.com which failed that every ISP (at least in France)
seem to
have encountered last night ?
The zonelabs.com zone is hosted on Above.net NS servers.
--On mer
In a message written on Wed, Nov 26, 2003 at 09:35:16AM +0100, Laurent Frigault wrote:
> The sessions reset again 35 minutes ago. Missing prefixes are back and
> above.net network seems reachable again.
We did restore full service overnight last night (well, probably early
in the morning for those
On Tue, Nov 25, 2003 at 11:29:32PM +0100, Laurent Frigault wrote:
> > anyone having trouble with above.net at the moment ?
>
> Yes. The problem seems related to the TAT14 failure. Since, around 16h30
> (GMT +0100) our bgp sessions with AS 6461 reset and now they received
> only 82305 prefix.
The
On Tue, Nov 25, 2003 at 05:08:29PM -0500, hostmaster wrote:
> anyone having trouble with above.net at the moment ?
Yes. The problem seems related to the TAT14 failure. Since, around 16h30
(GMT +0100) our bgp sessions with AS 6461 reset and now they received
only 82305 prefix.
Regards,
--
Lauren
On Tue, 25 Nov 2003, hostmaster wrote:
> anyone having trouble with above.net at the moment ?
I'm sure somebody is. I have a problem with the way they filter portions
of the internet (which I'm just assuming has not been resolved internally
yet). Perhaps you're asking about their outage in/t
l" ISP's leaking some of our routes. Maybe it's an
innocent misconfiguration, but if not please stop. In any event,
I'm trying to track that down now and make it better. We're working
as hard as we can to fix the problems.
--
Leo Bicknell - [EMAIL PROTECTED] - C
> anyone having trouble with above.net at the moment ?
>
> cheers
> -Bert
It is unreachable from various european networks for the
last 5-6 hours .
Best regards ,
--
=
Dimitris Zilaskos
Department of
anyone having trouble with above.net at the moment ?
cheers
-Bert
On Thu, 13 Nov 2003 [EMAIL PROTECTED] wrote:
> > We received a 69.144/16 from ARIN and spent the following few months
> > requesting numerous operators to take that space out of their filters.
> > Apparently for various historical reasons many operators filter the entire
> > 69. Block. That coul
On Thu, 13 Nov 2003, Fisher, Shawn wrote:
> We received a 69.144/16 from ARIN and spent the following few months
> requesting numerous operators to take that space out of their filters.
> Apparently for various historical reasons many operators filter the entire
> 69. Block. That could be part o
We received a 69.144/16 from ARIN and spent the following few months
requesting numerous operators to take that space out of their filters.
Apparently for various historical reasons many operators filter the entire
69. Block. That could be part of the problem.
--
Sent from
Some of my users are saying they cannot get to
www.listen-to.com, www.talk-servers.com and
www.electro-tech-online.com
One of them claims he's observed a pattern and that
things hosted by ev1servers.net aren't working.
I can get to them from several different places, but
I notice that e.g. www.
> >>
> >>dig @f.root-servers.net hostname.bind chaos txt
> >>
>
> Joe
>
leads to the question that should occur elsewhere, BUT,
why are there all these different ways to ID DNS servers?
granted, the ISC reference implementation was first
out, with the "vers
> Hard data:
see Subject: ORG was broken with serious customer impact,
and for a while. and it took a while to debug. qed
randy
Thus spake Damian Gerow ([EMAIL PROTECTED]) [17/10/03 11:09]:
> Apologies for using this as a 'Please contact me' list, but can a postmaster
> from AOL please give me a call? Our outbound mail has (again) mysteriously
> started getting bounced, even while having a 30-day temporary whitelist on
>
Apologies for using this as a 'Please contact me' list, but can a postmaster
from AOL please give me a call? Our outbound mail has (again) mysteriously
started getting bounced, even while having a 30-day temporary whitelist on
this server.
Calls to the NOC line receive a fast busy after the auto
On 17 Oct 2003, at 03:47, Randy Bush wrote:
Incidentally, there is a similar mechanism available for the F root
nameserver, in case people are not aware:
dig @f.root-servers.net hostname.bind chaos txt
For most people this will reveal a nameserver hostname with a "PAO" or
an SFO in it. Peopl
On 17.10 09:47, Randy Bush wrote:
>
> but one has little assurance that the response is from the same
> server as the one from which one had the dns response one is debugging.
That is true. However this only matters if the operator of the server
allows them to be inconsistent *and* routing so vo
> Incidentally, there is a similar mechanism available for the F root
> nameserver, in case people are not aware:
>
>dig @f.root-servers.net hostname.bind chaos txt
>
> For most people this will reveal a nameserver hostname with a "PAO" or
> an SFO in it. People within the catchment of a l
At 03:30 PM 10/16/2003, Rodney Joffe wrote:
Bruce Campbell wrote:
[much snipped]
> Also, did the query that I'm debugging really go to the same host that I
> just got the real IP address from?
I believe I covered that in my initial response to Randy which you
snipped. I said:
"> Dan Senie has s
On 16 Oct 2003, at 11:25, Bruce Campbell wrote:
I know to look for 'version.bind', 'id.server', 'version.server' and a
few
others, but I hadn't considered asking for 'whoareyou.arbitary.domain'.
Why would other people consider it?
Incidentally, there is a similar mechanism available for the F r
Bruce Campbell wrote:
>
> On Thu, 16 Oct 2003, Rodney Joffe wrote:
> > However as the dns was walked, if indeed a server had a problem, in a
> > non-anycast implementation you could tell which server ip address had
> > the problem. But you could not always tell which actual machine had a
> > p
On Thu, 16 Oct 2003, Rodney Joffe wrote:
> Randy Bush wrote:
>
> > and what assurance do you have that the traceroute is to the same
> > server to which the original query failed?
> >
> > difficulty debugging anycast dns was the major reason for sceptisim
> > re anycast auth servers.
>
> However
On Wed, 15 Oct 2003, Rodney Joffe wrote:
> Joe sent a note that identified a possible common thread in the version
> of bind the recursive servers were using. Could you perhaps look at that
> and see if there is any commonality?
I'll see what I can do about that. Unfortunately, the folks complai
William Allen Simpson writes on 10/16/2003 7:04 PM:
broke at least 7 Top Level Domains, ISC announced 3 weeks later, after
users started having problems.
Where? I cannot find the announcement.
This bind-announce post -
http://archives.neohapsis.com/archives/bind/2003/0023.html
srs
Sean Donelan wrote:
>
> An "anonymous reader" using almost identical language to Verisign
> Usage of the patch unexpectedly
> broke at least 7 Top Level Domains, ISC announced 3 weeks later, after
> users started having problems.
Where? I cannot find the announce
> it would appear that given the large scale
> ddos attacks against networks, and dns in particular over the last year,
> an anycast implementation is the *only* way that dns has a chance of
> surviving.
It might help but isn't a cure all.
If they can query it they can DoS it and given the spla
Randy Bush wrote:
> and what assurance do you have that the traceroute is to the same
> server to which the original query failed?
>
> difficulty debugging anycast dns was the major reason for sceptisim
> re anycast auth servers.
You're right, Randy. However, things are never black or white.
> If you or any other folks ever see any oddness with the UltraDNS
> nameservers, it would be helpful if you could provide traceroutes.
and what assurance do you have that the traceroute is to the same
server to which the original query failed?
difficulty debugging anycast dns was the major reas
I cannot identify a pattern to where these people who are
> having problems are since I do not have enough information. I am also not
> seeing any unusual behaviour with .org domain resolution from my name
> servers.
Joe sent a note that identified a possible common thread in the version
o
after
users started having problems. The .NAME registry has sent a formal letter
to ICANN's Security and Stability Advisory Comittee to warn against using
the BIND patch, which they will look into in their next meeting. The
intention may have been good, but... Stability? Anyone?"
NSI nego
On Thu, 16 Oct 2003, Joe Abley wrote:
>
> I think I'm seeing problems performing recursive queries for names
> under ORG against tld[12].ultradns.net at the moment, which is causing
> resolvers without cached data to behave as if domains don't exist.
>
> It's no
Hello Joe,
Joe Abley wrote:
>
> I think I'm seeing problems performing recursive queries for names
> under ORG against tld[12].ultradns.net at the moment, which is causing
> resolvers without cached data to behave as if domains don't exist.
>
> It's not trivi
501 - 600 of 960 matches
Mail list logo
