> i've also been thinking that AXFR's known incoherency could be reduced
> by using some kind of in-band embargo that would bring a new zone
> version online synchronously on servers supporting this feature and
> configured to enable it for a particular zone.
>
> Or a different storage
On Tue, 21 Dec 2004, Paul Vixie wrote:
i've also been thinking that AXFR's known incoherency could be reduced by
using some kind of in-band embargo that would bring a new zone version
online synchronously on servers supporting this feature and configured to
enable it for a particular zone
[EMAIL PROTECTED] wrote:
On Thu, 16 Dec 2004 17:18:12 PST, Crist Clark said:
Into a UDP response. A resolver will recieve the first 512 bytes of the
truncated response and may then use TCP to get the complete response...
unless there is a firewall blocking 53/tcp in the way. But how often
does t
On Tue, 21 Dec 2004, Iljitsch van Beijnum wrote:
>
> On 20-dec-04, at 17:32, Paul Vixie wrote:
>
> >>> 1. There should always be non-anycast alternatives
>
> >> I believe there is a strong consensus about that. And therefore a
> >> strong agreement that ".org" is seriously wrong.
>
> > i believe
> bearing in mind there have been issues with org but not . i have
> thought in the past there probably should be mroe than two ns records
> in ns ..
all i can say is:
> > i believe that icann/afilias/ultradns would be very receptive to
> > input from the ietf-dnsop wg on this topic. but it's n
On 20-dec-04, at 17:32, Paul Vixie wrote:
1. There should always be non-anycast alternatives
I believe there is a strong consensus about that. And therefore a
strong agreement that ".org" is seriously wrong.
i believe that icann/afilias/ultradns would be very receptive to input
from the ietf-dnso
> -Original Message-
> From: Gadi Evron [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 20, 2004 3:32 PM
> To: Bill Nash
> Cc: Hannigan, Martin; [EMAIL PROTECTED]
> Subject: Re: Anycast 101
>
>
> > Botnets aren't new. They've been prototyped o
Botnets aren't new. They've been prototyped on various IRC networks for
years. It started with hordes of linked eggdrop bots for Death Star
style privmsg/notice flood attacks on single users (1998? 1999?). When
For history's sake, most people name BO and netbus as the "original"
remote control
On Mon, 20 Dec 2004, Hannigan, Martin wrote:
Look at how the discussions surrounding SPAM have evolved. It went
from "damn abusers", to "damn software", to "where's the money coming
from?". The BotNet problem has already evolved to "where's the money".
Botnets are a new phenomenon. [ Gadi!?]
Botnet
Botnets are a new phenomenon. [ Gadi!?]
hehe, I won't take the bait on that one Martin. :)
I suppose that back in the days when it was "new" they weren't really
called "armies", and _hackers_ would actually set up "real" bots on
pwned boxes. Today we see less and less actual eggdrops/energymechs
> -Original Message-
> From: Bill Nash [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 20, 2004 3:33 PM
> To: Hannigan, Martin
> Cc: John Kristoff; [EMAIL PROTECTED]
> Subject: RE: Anycast 101
>
>
> On Mon, 20 Dec 2004, Hannigan, Martin wrote:
> >
On Mon, 20 Dec 2004, Hannigan, Martin wrote:
there are some million-bot drone armies out there. with
enough attackers
I know I haven't seen any 1MM+ zombie armies out there and I'm
looking for them. Why spend all that time getting 1MM bots when you
only need 100K?
Dormant reinforcements. Multiple
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> John Kristoff
> Sent: Monday, December 20, 2004 1:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Anycast 101
>
>
>
> On Mon, 20 Dec 2004 17:18:30 +
> Pau
there are some million-bot drone armies out there. with enough attackers
I've heard that claim before, but I've yet to be convinced that those
making it were doing more than speculating. It is not unreasonable to
believe there are millions of bot drones, but that is not the same as
an army unde
> > Anycast is a way to make the service generally available to as
> > many end-systems as want/need the service. So is multi-homing.
> > ... long term, what is important is the view that there is a
> > common namespace, not that there are special servers.
>
> sorry, that's just t
On Mon, 20 Dec 2004 17:18:30 +
Paul Vixie <[EMAIL PROTECTED]> wrote:
> there are some million-bot drone armies out there. with enough attackers
I've heard that claim before, but I've yet to be convinced that those
making it were doing more than speculating. It is not unreasonable to
believ
> Since when bad engineering is bad to the big business?
whenever it makes your service less attractive than your competitors.
> The world is full of examples to the contrary.
yes, but only where there's a monopoly of some kind.
> > ... be vulnerable to congestion based attacks, since a congestion
> > based attack is against OPN's (other people's networks) where even
> > infinite point-source provisioning cannot help you.
>
> well, thats practically true, but not theoretically true.
> the DNS is running just
Paul Vixie wrote:
of course it will work. it just won't be particularly fast. specifically,
it won't allow tcp to discover the actual end-to-end bandwidth*delay product,
and therefore tcp won't set its window size advantageously, and some or all
of the links along the path won't run at capacity.
> > With that thought process, an anycast network is only as it's most
> > beefed up node. As the smaller nodes fail the one left standing will
> > be what prevents the attack, not anycast.
>
> i admit that this appears true on the surface... but if you dig into it
> you'll see that even a root
> > but at that point, the only thing anycast would buy you is ddos
> > resistance and the ability to have more than 13 physical
> > servers... which is all the
>
> Is that true? I'm failing to see how anycast helps expand a network's
> DDoS survivability. At best a dumb attacker would attack t
> > Apparently you also didn't get any pointers to RFCs or other
> > authoritative sources that say "each and every packet injected into
> > the internet must be delivered in sequence".
>
> er... please quote chapter/verse here.
> these are "packets" and have sequence numbers
>
> >but so far nobody has said "yes, what Iljitsch is describing should
> >work."
>
> Apparently you also didn't get any pointers to RFCs or other
> authoritative sources that say "each and every packet injected into the
> internet must be delivered in sequence".
er... please quote cha
> [Warning: I've never actually deployed an anycast DNS setup so you are
> free to ignore my message.]
i'm not ignoring you because you raised two important issues.
> > 1. There should always be non-anycast alternatives
>
> I believe there is a strong consensus about that. And therefore a
> str
I don't think PPLB is compatible with anycast esp. in
situation when we consider end-to-end communication
with multiple packets.
As PPLB may derive to out-of-sequence between TCP
pacekets & different DNS server destination of the
same UDP stream, it will broke anycast DNS service in
some situa
Hi,
That's what I want to discuss about. The paper gives a
very detailed explanation on anycast with OSPF_ecmp,
and what I want to know is:
is there anything not included in it but must be
considered carefully when anycast cache server farm is
to be established in MAN ?
Will there be any prob
[Warning: I've never actually deployed an anycast DNS setup so you are
free to ignore my message.]
On Mon, Dec 20, 2004 at 01:28:43PM +0100,
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote
a message of 109 lines which said:
> 1. There should always be non-anycast alternatives
I believe there
On 18-dec-04, at 22:31, Paul Vixie wrote:
i would be interested in hearing from anybody else who thinks that
turning on pplb in a eyeball-centric isp that has multiple upstream
paths is a reasonable thing to do, even if there were no anycast
services deployed anywhere in the world.
so far, no take
[EMAIL PROTECTED] (Paul Vixie) (hey, that's me!) wrote:
> > > as i said the other day, "all power tools can kill." if you turn
> > > on PPLB and it hurts, then turn it off until you can read the
> > > manual or take a class or talk to an expert. PPLB is a link
> > > bundling technology. if you
Hannigan, Martin wrote:
Overall, "fat fingers" account for the larger percentage
of all outages.
Send that man a C-gar!
:)
-M<
Paul Vixie wrote:
since i already know that Iljitsch isn't listening, i'm not interested in
debating him further. i would be interested in hearing from anybody else
who thinks that turning on pplb in a eyeball-centric isp that has multiple
upstream paths is a reasonable thing to do, even if there
On 17-dec-04, at 22:58, Paul Vixie wrote:
since i already know that Iljitsch isn't listening, i'm not interested
in
debating him further.
[...]
but my mind is open, if anyone can speak from experience on the matter.
Right.
> > as i said the other day, "all power tools can kill." if you turn on
> > PPLB and it hurts, then turn it off until you can read the manual or
> > take a class or talk to an expert. PPLB is a link bundling technology.
> > if you turn it on in non-parallel-path situation, it will hurt you, so,
On 17-dec-04, at 19:43, Paul Vixie wrote:
i don't think iljitsch is in a position to teach an "anycast 101"
class.
If anyone feels they can do better, please step up...
here's my evidence:
note-- harald asked us to move this thread off of ietf@, so i've done
that.
ilj
On Fri, Dec 17, 2004 at 02:31:06PM -0500, Hannigan, Martin wrote:
>
>
>
> Link outages are higher than router failures when you
> subtract "human error" RFO's.
>
>
> Overall, "fat fingers" account for the larger percentage
> of all outages.
>
See my preso at the eugene nanog
/vijay
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Richard Irving
> Sent: Friday, December 17, 2004 2:20 PM
> To: Fergie (Paul Ferguson)
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Anycast 101
>
>
>
Fergie (Paul Ferguson) wrote:
I'll go out on a limb here and suggest that the percentage
of link failures over router failures is much, much higher.
- ferg
I'll go out on a limb and suggest...
you weren't working in BGP during 1995-1998.
:P
(Or RIP in 1992-1993, DVMRP in 1997-1999:)
-- Willia
i don't think iljitsch is in a position to teach an "anycast 101" class.
here's my evidence:
From: Paul Vixie <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [dnsop] Re: Root Anycast (fwd)
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Date: Mon,
On 17 Dec 2004, at 06:33, Iljitsch van Beijnum wrote:
On 17-dec-04, at 11:23, Joe Shen wrote:
is there any problem or anything must be taken
care about when anycast is employed within a DNS
server farm within MAN?
What I mean is, if we want to employ anycast in a
cache server farm which is locate
On Thu, 16 Dec 2004 17:18:12 PST, Crist Clark said:
> Into a UDP response. A resolver will recieve the first 512 bytes of the
> truncated response and may then use TCP to get the complete response...
> unless there is a firewall blocking 53/tcp in the way. But how often
> does that happpen?
You'r
I'll go out on a limb here and suggest that the percentage
of link failures over router failures is much, much higher.
- ferg
-- William Allen Simpson <[EMAIL PROTECTED]> wrote:
In 25+ years, I've not found that router failure was a major or even
interesting problem. Link failures are probabl
On Fri, 17 Dec 2004, Iljitsch van Beijnum wrote:
> As for TCP, it would be very useful if someone were to run the
> following experiment:
> +---+
> |router2|
> +---+
> / \
> +--+
Iljitsch van Beijnum wrote:
It doesn't really require that. Redundancy requires that the routers
at the ends of two links both be different. Having one router at one
end and two at the other is a good compromise in many situations.
OK, now I'm sure you don't actually do any engineering.
In 25+
On Fri, 17 Dec 2004 14:16:58 +
[EMAIL PROTECTED] wrote:
>
> > That's not the point. If without anycast this is better than with
> > anycast, then this should go on the "con" list for anycast.
>
> People often confuse two separate technical things
> here. One is the BGP anycast technique wh
On 17-dec-04, at 15:27, William Allen Simpson wrote:
In short: a customer must pplb across two routers at the same ISP,
and each of those routers must have different preferred paths to
different anycast instances. This isn't going to happen often, but
it's not impossible, and it's not bad engine
Iljitsch van Beijnum wrote:
Well, there may be only three "at" the LINX, but from where I'm
sitting, 7 are reachable over the AMS-IX, 4 over ISP #1 and 1 over
ISPs #2 and #3, respectively.
Interestingly enough, b, c, d and f all share this hop:
6 portch1.core01.ams03.atlas.cogentco.com (195.69
Iljitsch van Beijnum wrote:
On 17-dec-04, at 3:06, Steve Gibbard wrote:
under some very
specific circumstances it can also happen with per packet load
balancing.
You're misunderstanding how per-packet load balancing is generally used.
I wasn't saying anything about how per packet load balancing
> That's not the point. If without anycast this is better than with
> anycast, then this should go on the "con" list for anycast.
People often confuse two separate technical things
here. One is the BGP anycast technique which allows
anycasting to be used in an IPv4 network, and the
other is the
On 17-dec-04, at 12:25, Stephane Bortzmeyer wrote:
but even if 5 or 8 or 12 addresses become unreachable the timeouts
get bad enough for users to notice.
We can turn this into a Good Practice: do not put an instance of every
root name server on any given exchange point.
Actually, this is only a t
On 17-dec-04, at 3:06, Steve Gibbard wrote:
under some very
specific circumstances it can also happen with per packet load
balancing.
You're misunderstanding how per-packet load balancing is generally
used.
I wasn't saying anything about how per packet load balancing is
generaly used, the point
On 17-dec-04, at 11:23, Joe Shen wrote:
is there any problem or anything must be taken
care about when anycast is employed within a DNS
server farm within MAN?
What I mean is, if we want to employ anycast in a
cache server farm which is located within a big OSPF
network, is there anything probleme
On Fri, Dec 17, 2004 at 12:31:37AM +0100,
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote
a message of 68 lines which said:
> and then sees an anycast instance for all root servers over
> peering. If then something bad happens to the peering connection
...
> but even if 5 or 8 or 12 addresses b
On Thu, Dec 16, 2004 at 07:59:58PM -0500,
Steven M. Bellovin <[EMAIL PROTECTED]> wrote
a message of 26 lines which said:
> I'll leave the packet layout and arithmetic as an exercise for the
> reader
This has been already done :-)
http://w6.nic.fr/dnsv6/resp-size.html
My question:
I noticed that people always talked about BGP when
they talked about anycast dns server farm.
But, is there any problem or anything must be taken
care about when anycast is employed within a DNS
server farm within MAN?
What I mean is, if we want to employ anycast in a
cache serv
On Fri, 17 Dec 2004, Iljitsch van Beijnum wrote:
>
> I got some messages from people who weren't exactly clear on how
> anycast works and fails. So let me try to explain...
Nice try.
> Anycast is now deployed for a significant number of root and gtld
> servers. Before anycast, most of those ser
To add, there are also a lot of edge appliances (Company C appliances
that start with P) that block 53/tcp >= 512B by default without admins
realizing, hence EDNS gets actively blocked while normal DNS traffic
works (this is a major issue for Enterprise Windows Admins.)
On Fri, 17 Dec 2004 01:54
On Thu, Dec 16, 2004 at 07:59:58PM -0500, Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, Crist Clark writes:
> >
> >Iljitsch van Beijnum wrote:
> >
> >> Due to limitations in the DNS protocol, it's not possible
> >> to increase the number of authoritative DNS servers for a zone beyon
Steven M. Bellovin wrote:
In message <[EMAIL PROTECTED]>, Crist Clark writes:
Iljitsch van Beijnum wrote:
Due to limitations in the DNS protocol, it's not possible
to increase the number of authoritative DNS servers for a zone beyond
around 13.
I believe you misspelled, "Due to people who do not
In message <[EMAIL PROTECTED]>, Crist Clark writes:
>
>Iljitsch van Beijnum wrote:
>
>> Due to limitations in the DNS protocol, it's not possible
>> to increase the number of authoritative DNS servers for a zone beyond
>> around 13.
>
>I believe you misspelled, "Due to people who do not understa
Iljitsch van Beijnum wrote:
Due to limitations in the DNS protocol, it's not possible
to increase the number of authoritative DNS servers for a zone beyond
around 13.
I believe you misspelled, "Due to people who do not understand the DNS
protocol being allowed to configure firewalls..."
--
Crist
I got some messages from people who weren't exactly clear on how
anycast works and fails. So let me try to explain...
In IPv6, there are three ways to address a packet: one-to-one
(unicast), one-to-many (multicast), or one-to-any (anycast). Like
multicast addresses, anycast addresses are shared
61 matches
Mail list logo
