* George Bonser:
Well, I believe the original poster said that one of his colleagues
swore that BGP multihoming wouldn't work unless both feeds terminated on
the same router. I suppose said colleague has never heard of iBGP
between two routers of the local AS. Those two routers should
* George Bonser:
Does this really work that well? Won't you still get loops or
blackholes unless the eBGP routes on all border routers are identical?
As opposed to what, injecting the entire BGP table into your igp?
As opposed to just injecting defaults.
Maybe there is a reason the legacy
* Stephane Bortzmeyer:
DoS attack, may be?
Looks more like a routing issue. Looks like the .MIL operators put
all their eggs into one basket. 8-(
* Ken Gilmour:
ISP1 is the default gateway, ISP2 is a backup provider but which is always
active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
Client comes in on ISP2's link (non default gateway) but for some reason,
the packets seem to be going back out through the
* Rubens Kuhl:
You need to put a filter on your interfaces that references a
filter later on to not session track a flow. I think you need to
be running Junos-jsr[0] 10.0 or 10.1 to use this :
The same goes for 9.x, just be sure to except traffic to the router
(like BGP session) from the
* Randy Bush:
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
Uhm, is there a way around them when building the iBGP mesh?
* Rubens Kuhl:
On Sun, May 30, 2010 at 1:46 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Randy Bush:
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
Uhm, is there a way around
* Dale Cornman:
I had personally never heard of this and am curious if this is a
common practice as well as if this would potentially create any
problems by 2 Autonomous Systems both originating the same prefix.
The 6to4 anycast gateway RFC practically mandates this, and it does
work when
covering prefix was not
announced. (Arguably, that's two failures.)
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
problems right now. This takedown approach might work
for controllers of non-too-advanced malware, but you need something
better for content which people actually want to access, and which is
indexed by helpful search engines. 8-/
--
Florian Weimerfwei...@bfk.de
BFK edv
.
In this particular case, the copyright infringement seems to have
targeted mainly content created in the U.S., so it's quite natural
that the U.S. authorities take a particular interest in it.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
* Valdis Kletnieks:
(cue weasel-words about those routers using ASICs for most forwarding, but
doing multicast forwarding in software in 5.. 4.. 3..)
There's also the question of IP options (or extension headers). 8-)
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH
on commodity hardware will keep increasing.
Eventually, you'll need special-purpose hardware only for a smallish
portion at the top of the router market, or if you can't get the
software with the required protocol support on other devices.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting
* Roland Dobbins:
On Jul 14, 2010, at 8:38 PM, Florian Weimer wrote:
There's also the question of IP options (or extension headers). 8-)
I know that some modern hardware-based routers have the ability to
either ignore options, or to drop option packets altogether.
There might
for over a year.
They certainly have got infrastructure all over the globe.
The Verizon is probably just a private peering agreement, and someone
misinterpreted that (or deliberately misrepresented it).
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http
* Valdis Kletnieks:
On Sun, 15 Aug 2010 18:14:41 +0200, Florian Weimer said:
What's the current consensus on exempting private network space from
source address validation? Is it recommended? Discouraged?
What you do on your internal networks and internal transit is your business.
BCP38
* Valdis Kletnieks:
On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said:
And that connection that's trying to use PMTU got established across the
commodity internet, how, exactly? ;)
ICMP fragmentation needed, but DF set messages carry the a addresses
of intermediate routers which
* Michael J. Wise:
On Aug 15, 2010, at 9:14 AM, Florian Weimer wrote:
What's the current consensus on exempting private network space from
source address validation?
BCP38-land MUST *never* see RFC1918-space traffic. Ever.
Unless you're using a border router as a NAT device, of course
* Christopher Morrow:
(you are asking your vendors to run full bit sweeps of each protocol
in a regimented manner checking for all possible edge cases and
properly handling them, right?)
The real issue is that both spec and current practice say you need to
drop the session as soon as you
* Randy Bush:
imiho, researchers injecting data into the control plane are
responsible to have tested it at least against major bgp speakers.
Practically, this boils down to don't do that, which is certainly
fine by me.
To carry out such experiments responsibly, you have to conduct so much
* Randy Bush:
a bgp regression suite would not have caught this as it was not a
repeat.
Eh, it was just another corrupt-and-propagate issue combined with the
broken (but RFC-required) session reset policy on malformed updates.
* Claudio Jeker:
I think you blame the wrong people. The vendor should make sure that
their implementation does not violate the very basics of the BGP
protocol.
The curious thing here is that the peer that resets the session, as
required by the spec, causes the actual damage (the session
* Raymond Dijkxhoorn:
Not sure if the link was posted allready ...
http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4411f.shtml
Cisco posts their advisories to the NANOG list.
'The vulnerability manifests itself when a BGP peer announces a prefix
with a specific,
* Randy Bush:
To carry out such experiments responsibly, you have to conduct so much
testing beforehand that the live test on the actual Internet will not
yield new insights (assuming you did your pre-experiment testing
properly).
you seem to assume the purpose of the test was to see if
Mbps or higher plan from their provider.
The interesting question is not so much bandwidth, but if the traffic
counts against your monthly usage cap. For IPTV offered by your ISP,
it won't. Likewise for Internet video platforms where your ISP has
obtained an ad-sharing deal.
--
Florian Weimer
* Wayne E. Bouchard:
Okay, if we go down that road, that makes Starbucks, Borders, a number
of restaurants, and any other place that offers publically accessible
wifi (free or otherwise) an ISP.
The funny thing is that you actually want to be recognized as an ISP
if you have transit traffic
operators will stop filtering at the /32
boundary. So this issue will likely go away pretty soon because you
can use our initial assignment to gain the routing flexibility you
need.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
* Brandon Kim:
Times like this, makes you curious what kind of infrastructure
register.com has? How does one protect against DDOS?
You can outsource your DNS, but you better retain a server locally on
your network, so that you suffer less from that particular shared
toothbrush.
Anyone else get spammed from someone at Afilias?
Yes, I think you were Cc:ed on the message sent to me.
I find it odd that this type of advertising works. I would expect
actual victims to confuse it with extortion. (I have heard that you
were under attack and suffered an outage. For a small
* Saku Ytti:
I think we really need community tool to test BGP implementations against
known/past bugs and unknown (fuzzied) bugs.
Testing is the easy part. Meeting all the requirements for getting
the fix rolled out on the (relevant parts of the) Internet is
impossible because many ISPs have
to raise prices on their customers. This way
they don't.
Level 3 could do some routing tomography and make sure that Comcast
receives the traffic in the most inconvenient way.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
a registrar arm since they spun off Network Solutions
in 2002.
I think Verisign DBMS acts as a registrar for ccTLDs.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax
proper resource
management for the forseeable future.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* Brandon Kim:
I know windows has bitlocker, but I don't know if that is available
for Win2003?
I believe EFS is available in Windows XP and Windows 2003 Server, too.
Software-based solutions have the advantage that they are somewhat
more testable and reviewable. If it's all in the disk, you
* Jay Ashworth:
- Original Message -
From: Matt Larson mlar...@verisign.com
The new KSK will not be published in an authenticated manner outside
DNS (e.g., on an SSL-protected web page). Rather, the intended
mechanism for trusting the new KSK is via the signed root zone: DS
records
-in.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
in Section 2.5.1.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* Simon Lockhart:
On Thu Feb 03, 2011 at 01:11:35PM +, Florian Weimer wrote:
Has RIPE charged a LIR for their independent resources yet? I don't
think so. Therefore, comparisons with ARIN are a bit premature.
Yes - we got charged in our 2011 invoice.
Very interesting. Are you sure
* Ryan Finnesey:
This is one of the reasons we are starting to look at Juniper for a
new network build. It is my understanding we set software updates
for life for free.
My understanding is that it's free for customers who have a service
contract in place. Most downloads are not
* Alexander Maassen:
In most cases the only thing the abuse@ contacts do as hoster, is relay
the mail to the client but do not dare to do anything themself, even if
you provide them with a shitload of logs, even if you call them and say
that the attack from their source is still continueing,
* Jeff Wheeler:
On Sun, Mar 13, 2011 at 7:45 AM, Alexander Maassen
outsi...@scarynet.org wrote:
In most cases the only thing the abuse@ contacts do as hoster, is relay
the mail to the client but do not dare to do anything themself, even if
The RIPE IRR database contains a systemic means for
* Roland Dobbins:
A wider swathe of interested parties would know of their existence,
and their existence would be officially confirmed, which would make
them more valuable.
This is at odds with what happens in other contexts. Disclosure
devalues information.
--
Florian Weimer
* Roland Dobbins:
On Mar 24, 2011, at 6:41 PM, Florian Weimer wrote:
Disclosure devalues information.
I think this case is different, given the perception of the cert as
a 'thing' to be bartered.
Private keys have been traded openly for years. For instance, when
your browser tells you
setup with the customer. Or this
could be some sort of backup procedure (perhaps prompted by the
instability of the BGP link).
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe
, should be
second nature to them, but somehow I doubt that the FPKI (say) issues
certificates for non-federal entities to help with ongoing FBI
investigations. (Same for the German government agencies who actually
managed to get Mozilla approval for their non-CN-checking CAs.)
--
Florian Weimer
* John Levine:
Are there DNS caches that allow you to partition the cache for
subtrees of DNS names? That is, you can say that all entries from
say, in-addr.arpa, are limited to 20% of the cache.
You can build something like that using forwarders and most DNS
caches. But it won't result in
Are there somewhat reputable service providers for Internet-wide TCP
port scans? What's the typical rate per TCP port? (I'm interested in
rather obscure services whose identification may need additional
probing, and this data is unlikely on file already.)
A full scan needs just 0.5 TB of data
* Job Snijders:
In the meantime you could consider setting up an irrd[1], redirect
queries to that instance instead of whois.ripe.net, and keep it kind
of fresh by feeding it ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz on a
daily basis.
RIPE NCC strips all contact information from the bulk
* Andrew Sullivan:
My impression is mostly that people are left feeling uncomfortable
by a massive upgrade of this sort with so little communication about
why and so on.
That's a side effect of Juniper's notification policy. Perhaps
someone should them take them by their word (Security
* Constantine A. Murenin:
And how exactly do they expect end-users clearing the DNS cache? Do
I call ATT, and ask them to clear their cache?
Sure, and also tell them to clear their BGP cache (aka route flap
dampening). 8-)
* Iljitsch van Beijnum:
30 60 isn't a good choice because that means that after 30.1 seconds a
keepalive comes in and then after 60.0 seconds the session will expire
while the second one would be there in 60.1 seconds.
Wouldn't the underlying TCP retry sooner than that?
* Danny McPherson:
On May 25, 2009, at 11:33 AM, Florian Weimer wrote:
* Iljitsch van Beijnum:
30 60 isn't a good choice because that means that after 30.1
seconds a
keepalive comes in and then after 60.0 seconds the session will
expire
while the second one would be there in 60.1 seconds
for diagnostics (one additional run with the
+dnssec flag might be helpful, too).
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
dependency?
That's why the address is in the additional section.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* Anton Zimm:
I can not find the Glue Record. Where is the Glue Record?
It's in the additional section.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49
, essentially defrauding brand owners who are
structurally unable to cope with this situation.)
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
concerns. 8-P
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
such changes.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
standardized, not
implemented, or both, constantly moving the goalposts.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
and
get a fresh stub resolver each time they are restarted.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
with the
other two to report?
0x20 has alleged interoperability issues. It's also not such a simple
upgrade as it was initially thought, so the trade-off is rather poor
for existing resolver code bases.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de
).
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
still can reproduce the issue.
(Perhaps this topic is more suitable for the dns-operations mailing
list, BTW.)
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49
* Scott Morris:
I'm trying really hard to find my paranoia hat, and just to relieve
some boredom I read the entire bill to try to figure out where this was
all coming from
(2) may declare a cybersecurity emergency and order the limitation or
shutdown of Internet traffic to and from any
* Mike Tancsa:
220 as08.bis.na.blackberry.com ESMTP
HELO marble.sentex.ca
250 as08.bis.na.blackberry.com
MAIL From: postmas...@telus.com
451 #4.1.8 Domain of sender address postmas...@telus.com does not resolve
This could just be an SPF failure. Try some sender address you
control.
All the interfaces are forced to 1Gbps and full duplex.
This takes the interface out of spec, IIRC. Try with auto-negotation
enabled.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133
is: Is there any proof that Google does differentiate
between /24s, or even better is there any proof that this isn't the
case?
Good luck. Google doesn't disclose their algorithms. There doesn't
appear to be any Google statement on this matter, either.
--
Florian Weimerfwei
It seems to be down, based on
http://routerproxy.grnoc.iu.edu/internet2/ and trying to get a
traceroute to he.net/2001:470:0:76::2 from the SEAT location. BGP
seems to be up, though.
Shouldn't this cause quite a few problems for Internet2 downstreams?
(We received a report from an academic site
* Florian Weimer:
It seems to be down, based on
http://routerproxy.grnoc.iu.edu/internet2/ and trying to get a
traceroute to he.net/2001:470:0:76::2 from the SEAT location. BGP
seems to be up, though.
I've been told that the looking glass needs some knowledge about
Internet2's routing
* a. harrowell:
It ought to be superfluous to point out that the only effective
action taken against RBN was by the Internet community in getting
all their upstreams to null route them. As is blindingly obvious,
SOCA would never have been granted a warrant by the Russians.
Ugh, in reality,
* Laurent CARON:
I'm currently unable to reach security.debian.org
(2001:8d8:2:1:6564:a62:0:2) through IPv6.
donald:~# traceroute -M tcpconn -p 80 wieck.debian.org -n -6
traceroute to wieck.debian.org (2001:8d8:2:1:6564:a62:0:2), 30 hops max, 80
byte packets
It helps if you mention your
* Laurent CARON:
On Thu, Oct 29, 2009 at 12:52:07PM +0100, Florian Weimer wrote:
It helps if you mention your own IP address. Using 2001:7a8:820:1::1
instead, I get this in the reverse direction (from wieck):
My desktop's IP: 2001:7a8:820:1::31
I can ping it from both locations
boxes didn't even have WAN
links. Part of the problem is that operating systems come with TCP
stacks and web servers which are not very robust, so it's pretty easy
to create something which behaves spectacularly better under certain
attacks.
--
Florian Weimerfwei...@bfk.de
BFK edv
Since people need to *explicitly* choose using the OpenDNS servers, I
can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you
can of course choose to use a different service - for instance your
ISP's name servers.
be cheating. 8-)
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* David Ulevitch:
On 11/11/09 12:48 PM, Florian Weimer wrote:
Since people need to *explicitly* choose using the OpenDNS servers, I
can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you
can of course choose
* Jeffrey Lyon:
Looks like FR-RENATER-ENST is in the wrong:
1708-1728 Assigned by ARINwhois.arin.net
(source: http://www.iana.org/assignments/as-numbers/ )
It could have been ERXed (or whatever the process is called for AS
numbers).
--
Florian Weimer
. A good example in
this area is 53.0.0.0/8, which has a rather interesting history.
Another one is AS702.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721
* Jared Mauch:
The issue of zone signing is going to be interesting as some
nation-states (ccTLD) have been known to speak-up about their issues
with the signing of the zone.
Which ones?
In most cases, ccTLDs don't represent nation states, and vice versa.
--
Florian Weimer
is 23456, and not the AS23456
syntax encoded in multiple tools.
*sigh*
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* Jorge Amodio:
What needs to be done to have ISPs and other service providers stop tampering
with DNS ?
First, stop calling it NXDOMAIN rewriting. These guys are rewriting
everything they want, so that they can respond to your search queries,
or serve different ads to you.
Then try to opt
appear to be uninterested in tracing or blocking
them. Is this the new normal? One of my concerns is that if others
are seeing probe attempts, they will see them from these addresses
and of course, contact us.
What's the distribution of the source addresses and source ports?
--
Florian Weimer
* Rene Wilhelm:
AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at
whois.ripe.net is a user created object in the RIPE routing registry, not
an assignment by RIPE NCC.
How can you tell one from the other? Is the lack of an org: attribute
reliable?
--
Florian Weimer
* Christopher Morrow:
On Fri, Oct 7, 2011 at 3:10 PM, Arturo Servin arturo.ser...@gmail.com wrote:
I agree with Benson.
In fact, for this problem I find irrelevant that IPv4 is running
out. They are just looking for good reputation IP nodes.
isn't this a short-lived problem
smaller
networks per cable interfaces of CMTS.
As far as I understan the IPv6 address architecture, if the network
prefix is longer than /64, you're not running Unicast IPv6.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
in a blackhole,
or will the entire announcement be suppressed? I suspect the latter,
given what we see and what Chris Adams has reported.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133
it? Oh yeah..
Because there's a CPE which acts as a mediator, or the host uses some
dial-up-type protocol which takes care of the IGP interaction.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D
* Paul Vixie:
this seems late, compared to the various commitments made to rpki in
recent years. is anybody taking it seriously?
The idea as such isn't new, this has been floating around for four
years or more, including at least one Internet draft,
* Jeff Kell:
And what about the millions of users unknowingly infected with
something else ??
You have to start somewhere. I received a warning letter, and four or
five very organizations had to cooperate in new ways to make this
happen. This is certainly a welcome development, and
* Alex Band:
I don't know if we can get RPKI to deployment because RIPE and RIPE
NCC have rather serious issues with it. On the other hand, there
doesn't seem to be anything else which keeps RIRs relevant in the
post-scarcity world, so we'll see what happens.
Could you elaborate on what
* Alex Band:
At RIPE 63, six months ago, the RIPE NCC membership got a chance to
vote on RPKI at the general meeting. The result was that the RIPE
NCC has the green light to continue offering the Resource
Certification service, including all BGP Origin Validation related
functionality.
But
* Alex Band:
All in all, for an RPKI-specific court order to be effective in
taking a network offline, the RIR would have to tamper with the
registry, inject false data and try to make sure it's not detected
so nobody applies a local override.
Please keep in mind that this is what's
[Dnschanger substitute server operations]
One thing is clear, Paul is able to tell a great story.
PR for ISC is somewhat limited, it's often attributed to the FBI:
| The effort, scheduled to begin this afternoon, is designed to let
| those people know that their Internet connections will stop
* Barry Greene:
FYI - Two prefixes from the DNS Changer/Rover Digital take down have
been re-allocated. One of the prefixes - 85.255.112.0/20 - was
advertised Friday morning. There is a blog post with some of the
details here:
Wow, that was fast. So the police order actually made sense and
* Suresh Ramasubramanian:
For the mailops is not operational folks.. it involves parsing dns
txt records, so .. well, please grit your teeth and read on, this gets
interesting
By the way, BIND 9 is supposed to throw away this type of malformed
RDATA, so if you run BIND 9, this is only
* Seth Mattinen:
4. Multihome.
Or get upstream from someone who does, and who is small enough to be
able to get additional upstream upon short notice. I know that this
solution isn't always cost-effective. 8-/
(Multihoming alone isn't a solution because it's hard to figure out
how independent
* Patrick W. Gilmore:
1. Neither Sprint nor Cogent have transit
Both Sprint Cogent are transit-free networks. (Notice how I
carefully avoided saying tier one?) Whether one or both _should_
have transit is not a fact, and therefore outside the scope of this e-
mail, but that neither have
* Valdis Kletnieks:
On Mon, 03 Nov 2008 10:26:59 +0100, Florian Weimer said:
* Patrick W. Gilmore:
3. Standard transit contracts do not guarantee full connectivity
If this were true, why would end users (or, more generally, not
significantly multi-homed networks) buy transit from
* Paul Vixie:
if cogent signed a trial peering contract which required payment if sprint
determined after three months that cogent did not qualify, then the court's
open questions are was the contract valid (and thus, does cogent owe sprint
money) and why isn't there some kind of common
1 - 100 of 270 matches
Mail list logo
