http://it.slashdot.org/article.pl?sid=08/09/22/1253201&from=rss
nice to see a wholesale DNSSEC rollout underway (I must confess to
being a little surprised at the source, too!). Granted, it's a much
more manageable problem set than, say, .com - but if one US-controlled
TLD can do it, hope i
On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote:
> nice to see a wholesale DNSSEC rollout underway (I must confess to being a
> little surprised at the source, too!). Granted, it's a much more manageable
> problem set than, say, .com - but if one US-controlled TLD can do i
* Jason Frisvold:
> On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote:
>> nice to see a wholesale DNSSEC rollout underway (I must confess to being a
>> little surprised at the source, too!). Granted, it's a much more manageable
>> problem set than, say, .com - but if one US
On Mon, 22 Sep 2008 10:52:42 -0400
"Jason Frisvold" <[EMAIL PROTECTED]> wrote:
> I'm not much up on DNSSEC, but don't you need to be using a resolver
> that recognizes DNSSEC in order for this to be useful?
You do -- and last time I checked few native resolvers actually did :
glibc doesn't, and I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 22, 2008, at 9:59 AM, Simon Vallet wrote:
On Mon, 22 Sep 2008 10:52:42 -0400
"Jason Frisvold" <[EMAIL PROTECTED]> wrote:
I'm not much up on DNSSEC, but don't you need to be using a resolver
that recognizes DNSSEC in order for this to be use
Florian Weimer wrote:
> * Jason Frisvold:
>
>> On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote:
>>> nice to see a wholesale DNSSEC rollout underway (I must confess to being a
>>> little surprised at the source, too!). Granted, it's a much more manageable
>>> problem set t
* Colin Alston:
>> Correct, you need a validating, security-aware stub resolver, or the
>> ISP needs to validate the records for you.
> In public space like .com, don't you need some kind of central
> trustworthy CA?
No, why would you? You need to trust the zone operator, and you need
some trus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 22 Sep 2008 10:02:21 -0500
Chris Owen <[EMAIL PROTECTED]> wrote:
> Chicken, meet egg.
>
> I think the point of the original post is that one end or the other
> has to start things. At least we have one US zone doing something on
> the se
> Correct, you need a validating, security-aware stub resolver, or the
> ISP needs to validate the records for you.
That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to
actually provide any improvement in security whatsoever, the ROOT ZONE (.)
needs to be signed, and ev
* Simon Vallet:
>> I'm not much up on DNSSEC, but don't you need to be using a resolver
>> that recognizes DNSSEC in order for this to be useful?
>
> You do -- and last time I checked few native resolvers actually did :
> glibc doesn't, and I'd be surprised if the Windows resolver does
Windows do
DNSSEC is not a PKI. There are no CAs and no X.509 certificates. It's a chain
of trust that can be validated using public/private key pairs. OK, that's
oversimplification but you get the idea.
While we wait for applications to become DNSSEC-aware, if your local DNS server
can be trusted (a b
On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <[EMAIL PROTECTED]> wrote:
> Chicken, meet egg.
>
> I think the point of the original post is that one end or the other has to
> start things. At least we have one US zone doing something on the server
> end of things.
Oh, agreed, absolutely. And it's
* Keith Medcalf:
>> Correct, you need a validating, security-aware stub resolver, or the
>> ISP needs to validate the records for you.
>
> That would defeat the entire purpose of using DNSSEC. In order for
>DNSSEC to actually provide any improvement in security whatsoever,
>the ROOT ZONE (.) need
On Mon, Sep 22, 2008 at 10:52:42AM -0400, Jason Frisvold wrote:
> On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote:
> > nice to see a wholesale DNSSEC rollout underway (I must confess to being a
> > little surprised at the source, too!). Granted, it's a much more manageable
* marcus sachs:
> While we wait for applications to become DNSSEC-aware,
Uhm, applications shouldn't be DNSSEC-aware. Down that road lies
madness. What should an end user do when the browser tells him,
"Warning: Could not validate DNSSEC signature on www.example.com,
signature has expired. Con
On Mon, Sep 22, 2008 at 11:11:40AM -0400, Keith Medcalf wrote:
>
> > Correct, you need a validating, security-aware stub resolver, or the
> > ISP needs to validate the records for you.
>
> That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to
> actually provide any improv
On Mon, Sep 22, 2008 at 05:24:00PM +0200, Florian Weimer wrote:
> * marcus sachs:
>
> > While we wait for applications to become DNSSEC-aware,
>
> Uhm, applications shouldn't be DNSSEC-aware. Down that road lies
> madness. What should an end user do when the browser tells him,
> "Warning: Could
Jason Frisvold wrote:
On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <[EMAIL PROTECTED]> wrote:
Chicken, meet egg.
I think the point of the original post is that one end or the other has to
start things. At least we have one US zone doing something on the server
end of things.
Oh, agre
> nice to see a wholesale DNSSEC rollout underway (I must confess to
> being a little surprised at the source, too!). Granted, it's a much
> more manageable problem set than, say, .com - but if one US-controlled
> TLD can do it, hope is buoyed for a .com rollout sooner rather than
> later (although
On Mon, Sep 22, 2008 at 8:16 AM, Jason Frisvold <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <[EMAIL PROTECTED]> wrote:
>> Chicken, meet egg.
>>
>> I think the point of the original post is that one end or the other has to
>> start things. At least we have one US zone
> > That would defeat the entire purpose of using DNSSEC. In order for
> >DNSSEC to actually provide any improvement in security whatsoever,
> >the ROOT ZONE (.) needs to be signed, and every delegation up the
> >chain needs to be signed. And EVERY resolver (whether recursive or
> >local on host
On Mon, Sep 22, 2008 at 8:49 AM, Keith Medcalf <[EMAIL PROTECTED]> wrote:
>> > If even one delegation is unsigned or even one resolver does not
>> > enforce DNSSEC, then, from an actual security perspective, you will
>> > be far worse off than you are now.
>
>> Why?
>
> If the local resolver does
Emil,
If you've actually shut off the RBN, you should have no problem
finding some new transit to turn up, right?
We're in a buyer's market, and there are dozens of vendors on-net at
200 Paul who'd love a piece of your business.
Drive Slow,
Paul Wall
On Sun, Sep 21, 2008 at 3:20 PM, Emil Kacper
> > Just because YOU check the digital signature on an email
> and forward that email to me (either with or without the
> > signature data), if I do not have the capability to verify
> the signature myself, I sure as hell am not going to trust your
> > mere say-so that the signature is valid!
> >
At 15:30 + 9/22/08, [EMAIL PROTECTED] wrote:
data. We never finished the discussion on fail/open
fail/closed wrt DNSSEC.
And I'd bet a dollar we never will finish that discussion.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
>
> The end-stage is secure only if at that stage you also set all DNS
> infrastructure to refuse to talk to any DNS client/server/resolver that DOES
> NOT validate and enforce DNSSEC. Up until that point in time, there is NO
> CHANGE in the security posture from what we have today with no DNS
On Mon, Sep 22, 2008 at 12:06:57PM -0400, Edward Lewis wrote:
> At 15:30 + 9/22/08, [EMAIL PROTECTED] wrote:
>
> > data. We never finished the discussion on fail/open
> > fail/closed wrt DNSSEC.
>
> And I'd bet a dollar we never will finish that discussion.
> --
> -=-=-=-=-=-=-=-=-=
On Mon, Sep 22, 2008 at 12:14:53PM -0400, Keith Medcalf wrote:
>
> > > If I cannot authenticate the data myself, then it is simply
> > untrusted and untrustworthy -- exactly the same as it is now.
>
> > so I guess PGP web of trust is right out, then?
>
[elided]
>
> If there is a piece of data
> Date: Mon, 22 Sep 2008 11:42:33 -0400
> From: "Goltz, Jim (NIH/CIT) [E]" <[EMAIL PROTECTED]>
>
> > nice to see a wholesale DNSSEC rollout underway (I must confess to
> > being a little surprised at the source, too!). Granted, it's a much
> > more manageable problem set than, say, .com - but if o
On Sep 22, 2008, at 7:56 AM, Florian Weimer wrote:
I'm not much up on DNSSEC, but don't you need to be using a resolver
that recognizes DNSSEC in order for this to be useful?
Yes, and you also need the trust anchors for the zones you want to
validate configured.
Correct, you need a validat
On Sep 22, 2008, at 8:11 AM, Keith Medcalf wrote:
Correct, you need a validating, security-aware stub resolver, or the
ISP needs to validate the records for you.
That would defeat the entire purpose of using DNSSEC. In order for
DNSSEC to actually provide any improvement in security whatsoev
Kevin Oberman wrote:
Date: Mon, 22 Sep 2008 11:42:33 -0400
From: "Goltz, Jim (NIH/CIT) [E]" <[EMAIL PROTECTED]>
Remember, they've also "mandated" IPv6 support on all backbones.
Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actua
> Subject: RE: hat tip to .gov hostmasters
> Date: Mon, 22 Sep 2008 11:49:50 -0400
> From: "Keith Medcalf" <[EMAIL PROTECTED]>
>
> If I cannot authenticate the data myself, then it is simply untrusted and u=
> ntrustworthy -- exactly the same as it is now.
"Speak for yourself, John" applies.
In
To digress on IPv6 momentarily.
The airline magazine engineering memorandum* from OMB left two terms
undefined in the mandate; "backbone network" and "IPv6 compatible." The
Intra-agency IPv6 Federal Working Group wisely defined "backbone
network" as (paraphrasing) the wire exiting the first publi
Hi all,
Anybody have a preferred supplier for 10GE XFPs, multimode and
singlemode?
These are to be installed in Force10 and Juniper hardware in Toronto,
so a Canadian supplier would be fabulous although I won't hold my
breath.
Joe
Just to add my $0.02 to this discussion and a disclaimer - I've known
Emil for years, I've seen his shop and even the controversy.
200 Paul is a small community, and most of the folks in there know
eachother, I've been in there since 2001 or so.
Intercage is not a big shop, there are very few peo
On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote:
Intercage is not a big shop, there are very few people involved in
running
it
I have no dog in this fight, but I would comment on the "small shop"
issue as it relates to handling abuse complaints.
I own a small colo
On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote:
Basically is what it boils down to for me - its easy to blame
an NSP/ISP/Hoster for what their clients do, it takes real
dedication to
find out whats *actually* going on.
Tom,
Atrivo is not just a spammer, and Intercage ha
On Mon, Sep 22, 2008 at 04:48:16PM -0400, Drew Linsalata wrote:
> I have no dog in this fight, but I would comment on the "small shop"
> issue as it relates to handling abuse complaints.
>
> I own a small colo/hosting shop too. We don't have many employees.
> If we had to deal with so many a
So... apparently AS27595 is back on the air, with aspath's like:
6461 23342 27595
6539 23342 27595
8075 23342 27595
23342 == UnitedLayer, Tom isn't that you or is that another Tom I'm remembering?
-Chris
On Mon, Sep 22, 2008 at 5:17 PM, Christopher Morrow
<[EMAIL PROTECTED]> wrote:
> So... apparently AS27595 is back on the air, with aspath's like:
>
> 6461 23342 27595
> 6539 23342 27595
> 8075 23342 27595
>
> 23342 == UnitedLayer, Tom isn't that you or is that another Tom I'm
> remembering?
ah! s
On Mon, Sep 22, 2008 at 05:17:42PM -0400, Christopher Morrow wrote:
> So... apparently AS27595 is back on the air, with aspath's like:
> 6461 23342 27595
> 6539 23342 27595
> 8075 23342 27595
>
> 23342 == UnitedLayer, Tom isn't that you or is that another
> Tom I'm remembering?
Yep, same Tom, I
We are seeing some issues w/ XO/Savvis peering..
Trace from XO to Savvis IP space (64.75.10.151)
Keys: Help Display mode Restart statistics Order of fields quit
Packets
On 2008-09-22-15:01:35, Joe Abley <[EMAIL PROTECTED]> wrote:
> Anybody have a preferred supplier for 10GE XFPs, multimode and
> singlemode?
Fluxlight (www.fluxlightinc.com) is good source for 10GBASE-SR and LR
XFPs. They tend to keep an inventory, often able to ship on the day
of order; their w
yeah, we noticed it as well. looks like they're back now. i noticed
their routes drop off at about 14:16 PT and come back just after 14:30 PT.
+m
Justin Sharp wrote:
> We are seeing some issues w/ XO/Savvis peering..
>
> Trace from XO to Savvis IP space (64.75.10.151)
>
> Keys: Help Display
Also seeing some issues with XO out here:
Tracing route to yahoo.com [68.180.206.184]
over a maximum of 30 hops:
1 2 ms 1 ms 1 ms 10.100.20.1
2 2 ms 1 ms 2 ms sjcisr01-int.wyse.com [10.100.1.15]
3 3 ms 2 ms 2 ms 132.237.245.1
4 3 ms 3 ms
On Mon, Sep 22, 2008 at 5:25 PM, Tom Sparks (Applied Operations)
<[EMAIL PROTECTED]> wrote:
> On Mon, Sep 22, 2008 at 05:17:42PM -0400, Christopher Morrow wrote:
>> So... apparently AS27595 is back on the air, with aspath's like:
>> 6461 23342 27595
>> 6539 23342 27595
>> 8075 23342 27595
>>
>> 233
Seems like Savvis/XO routes have been restored, albeit through an
unusual Dallas route (usually takes an XO Los Angeles route)..
1. scrubbed
0.0% 2040.4 0.7 0.3 7.0 0.9
2.
ip65-44-114-97.z114-44-65.customer.al
I am seeing it on my end also:
traceroute: Warning: www.cnn.com has multiple addresses; using
157.166.224.25
traceroute to www.cnn.com (157.166.224.25), 64 hops max, 40 byte packets
1 hq-rtr1.genius.local (64.244.66.1) 0.891 ms 0.429 ms 0.449 ms
2 ip65-46-253-157.z253-46-65.customer.algx
On Mon, Sep 22, 2008 at 5:48 PM, Christopher Morrow
<[EMAIL PROTECTED]> wrote:
> On Mon, Sep 22, 2008 at 5:25 PM, Tom Sparks (Applied Operations)
> <[EMAIL PROTECTED]> wrote:
>> I also noticed AS paths like this:
>> * 69.22.162.0/23 701 2914 32335 6461 23342 27595 i
>>
>> I'm not sure whats going
On Mon, Sep 22, 2008 at 05:50:58PM -0400, Christopher Morrow wrote:
> actually, I think PIE sees this route from 6461 and passes it along
> probably because they didn't update the filters on their sessions when
> they dropped the links to 27595 :(
Has anyone actually confirmed that the link is dro
Patrick W. Gilmore wrote:
There is no law or even custom stopping me from asking you to prove you
are worthy to connect to my network.
There may not be a law preventing you from asking him for proof of
legitimate customers, but there is a law preventing him from answering
you. Google for C
On Sun, Sep 21, 2008 at 12:46:54PM -0700, Emil Kacperski wrote:
> Hey James,
>
> That's the worst part in all this, so many been with me for years!? I just
put my fate into companies I shouldn't have.
Emil:
Yes, they have been with you for years -- it's quite unfortunate, such great
customers.
T
In article <[EMAIL PROTECTED]> you write:
>* marcus sachs:
>
>> While we wait for applications to become DNSSEC-aware,
>
>Uhm, applications shouldn't be DNSSEC-aware. Down that road lies
>madness. What should an end user do when the browser tells him,
>"Warning: Could not validate DNSSEC signatur
That does not stop me from asking. Also, I've never seen a viable,
legit biz that didn't have at least a couple customers who were
willing to let their name be used.
--
TTFN,
patrick
iPhone 3-J
(That's 3-Jezuz for the uninitiated.)
On Sep 22, 2008, at 18:00, Justin Shore <[EMAIL PROTECTED]
I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and
another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in
using ASN 3267 (Russian Federal University Network) to advertise our space to
ASN 3277 (Regional University and Scientific Network (RUSNet)
On Mon, 22 Sep 2008 17:00:35 CDT, Justin Shore said:
> There may not be a law preventing you from asking him for proof of
> legitimate customers, but there is a law preventing him from answering
> you. Google for CPNI and "red flag".
Hmm... I'm not sure how "Yes, XYZ is a customer of mine" qua
I received a phas notification about this today as well...
I couldn't find any relevant data confirming the announcement of one
of my /19 blocks, until a few minutes ago when i checked the route
views bgplay (ripe bgplay turns up nothing) and can now see 8997
announcing and quickly withdrawing my
--Scott Weeks <[EMAIL PROTECTED]> wrote: ---
> I am hoping to confirm a short-duration prefix hijack
-
--- [EMAIL PROTECTED] wrote: ---
From: "Christian Koch" <[EMAIL PROTECTED]>
I couldn't find any relevant data confirming the announcement o
about 09:30 UTC per rviews
On Mon, Sep 22, 2008 at 9:31 PM, Scott Weeks <[EMAIL PROTECTED]> wrote:
>
> --Scott Weeks <[EMAIL PROTECTED]> wrote: ---
>
>> I am hoping to confirm a short-duration prefix hijack
>
> -
>
> --- [EMAIL PROTECTED] wrote:
On Mon, Sep 22, 2008 at 21:06, Scott Weeks <[EMAIL PROTECTED]> wrote:
>
> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and
> another of our
> prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267
> (Russian Federal University Network) to advertise
She'd have to actually specify -b to ping a broadcast address, and if
she did, she would only get replies back from the hosts on that
subnet, not duplicate replies from the same IP.
On Wed, Sep 10, 2008 at 5:11 AM, Sebastian Abt <[EMAIL PROTECTED]> wrote:
> * chloe K wrote:
>> When I ping the ip,
At least I think that's how it works. :)
On Mon, Sep 22, 2008 at 7:54 PM, John Jensen <[EMAIL PROTECTED]> wrote:
> She'd have to actually specify -b to ping a broadcast address, and if
> she did, she would only get replies back from the hosts on that
> subnet, not duplicate replies from the same I
On Mon, 22 Sep 2008 19:54:17 PDT, John Jensen said:
> She'd have to actually specify -b to ping a broadcast address,
Only true if you're pinging the broadcast address of a network that you
have an interface on, or the system has other knowledge of the netmask/etc.
If you're pinging a remote addre
Looking up some of my prefixes in PHAS and BGPPlay, I too see my
prefixes being advertised by 8997 for a short time. It looks like it
happened around 1222091563 according to PHAS.
Was this a mistake or something else?
Justin
Christian Koch wrote:
I received a phas notification about this t
On Mon, 22 Sep 2008, Scott Weeks wrote:
I too spotted this via PHAS for a large number of prefixes, but have not
received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack:
http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected
with so many RRC boxes that RIPE RI
On Mon, 22 Sep 2008, Christian Koch wrote:
Strange that RIPE RIS search doesn't show it:
http://www.ris.ripe.net/perl-risapp/risearch.html
but yet you say BGPlay does show it.
-Hank
I received a phas notification about this today as well...
I couldn't find any relevant data confirming the ann
At first glance this morning not seeing any data between the gain and
lost alerts from phas and inability to find a route in any of the many
collectors and route servers out there I had thought it was a possibly
a fat finger mistake by 8997 or a false positive.
After locating the data in bgplay/rv
Bgplay on routeviews, not the ripe one :)
Christian
On 9/23/08, Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Sep 2008, Christian Koch wrote:
>
> Strange that RIPE RIS search doesn't show it:
> http://www.ris.ripe.net/perl-risapp/risearch.html
> but yet you say BGPlay does show it.
>
Hi,
.-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank
Nussbacher wrote:
> I too spotted this via PHAS for a large number of prefixes, but have not
> received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack:
> http://www.ris.ripe.net/perl-risapp/risearch.htm
Ahah, so my first theory was on the right track :)
Thanks for sharing the info...
Christian
On Tue, Sep 23, 2008 at 2:33 AM, Andree Toonk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank
> Nussbacher wrote:
>
>> I too spotted this via
On Tue, 23 Sep 2008, Andree Toonk wrote:
Not a false positive, It actually was detected by the RIS box in Moscow
(rrc13). Strange that it's not visible in RIS search website, but it's
definitely in the raw data files.
Looking at that raw data from both routeviews and Ripe, it looks like they
72 matches
Mail list logo
