Date: Sun, 26 Jul 2009 20:48:06 -0500
Subject: AT&T. Layer 6-8 needed.
All,
It appears at AT&T (including DSL, and my own home service via u-verse)
has unilaterally and without explanation started blocking websites.
I have confirmed this with multiple tests. (It actually appears that
these sites are being blocked at a local-global scale -- that is, each
city/hub seems to have blackholes for the sites).
The sites I know of I'll list below (see Reddit for a discussion), but
this is clearly and absolutely unacceptable. Please, comments on the nature
of the sites are OT.. Let's keep this thread that way. (Away from being OT,
that is).
If any T folk are around, and have gotten wind of this (all comments /
direct emails will be off record), a reply would be appreciated.
No ears enclosing clue will be reached via normal channels at ~950E on a
Sunday, but this is clearly a problem needing addressing, resolution, action
and, who knows - suit?
Thanks in advance all for insight, comments,
-jamie
AT&Tが始めたWebサイトブロックについて、情報を集っています。
続々と情報が寄せられている模様。。。
7/27/2009
5/12/2009
NANOG@May 11, 2009
Date: Mon, 11 May 2009 22:29:27 +0200
Subject: two interfaces one subnet
Hi,
This is a pretty moronic question, but I've been searching RFC's on-
and-off for a couple of weeks and can't find an answer. So I'm hoping
someone here will know it offhand.
I've been looking through RFC's trying to find a clear statement that
having two interfaces in the same subnet does not work, but can't find
it that statement anywhere.
The OS in this case is Linux. I know it can be done with clever
routing and prioritization and such, but this has to do with vanilla
config, just setting up two interfaces in one network.
I would be grateful for a pointer to such an RFC statement, assuming
it exists.
Thanks!
Chris
とりあえずやってみればいいことなのにRFCを調べるなんて素晴らしい。
色々やった結果、挙動が異なるので調べてるならそれも納得。
コメントがたくさん出てきています。
Subject: two interfaces one subnet
Hi,
This is a pretty moronic question, but I've been searching RFC's on-
and-off for a couple of weeks and can't find an answer. So I'm hoping
someone here will know it offhand.
I've been looking through RFC's trying to find a clear statement that
having two interfaces in the same subnet does not work, but can't find
it that statement anywhere.
The OS in this case is Linux. I know it can be done with clever
routing and prioritization and such, but this has to do with vanilla
config, just setting up two interfaces in one network.
I would be grateful for a pointer to such an RFC statement, assuming
it exists.
Thanks!
Chris
とりあえずやってみればいいことなのにRFCを調べるなんて素晴らしい。
色々やった結果、挙動が異なるので調べてるならそれも納得。
コメントがたくさん出てきています。
5/07/2009
NANOG@May 6, 2009
Date: Wed, 6 May 2009 11:41:55 -0400
Subject: Minnesota Sends List of Blacklisted Gambling Sites to ISPs,
Telcos
With regard to the recent discussion...
"Late last month the Minnesota Department of Public Safety announced
it would require ISPs and telcos to block computers located in the
state from accessing gambling sites, and said non-compliant companies
would be referred to the FCC. Now, the state has sent each ISP and
telco the enclosed blacklist of sites and URLs."
http://www.govtech.com/gt/articles/656645
--
Jeremy L. Gaddis
ミネソタ州の公安局がギャンブルサイトのURLをブラックリストとして各ISPに送付した、と。
実行しないとFCCに報告。
ようやく無秩序な事態から変化が起こるか。
Subject: Minnesota Sends List of Blacklisted Gambling Sites to ISPs,
Telcos
With regard to the recent discussion...
"Late last month the Minnesota Department of Public Safety announced
it would require ISPs and telcos to block computers located in the
state from accessing gambling sites, and said non-compliant companies
would be referred to the FCC. Now, the state has sent each ISP and
telco the enclosed blacklist of sites and URLs."
http://www.govtech.com/gt/articles/656645
--
Jeremy L. Gaddis
ミネソタ州の公安局がギャンブルサイトのURLをブラックリストとして各ISPに送付した、と。
実行しないとFCCに報告。
ようやく無秩序な事態から変化が起こるか。
5/06/2009
NANOG@May 5, 2009
Date: Tue, 5 May 2009 13:38:17 -0700
Subject: DHCPv6 PD chains vs bridging
On Tue, May 05, 2009 at 04:22:04PM -0400, Paul Timmins wrote:
> Sorry for the top post, but as a crazy thought here, why not throw out an
> RA, and if answered, go into transparent bridge mode? Let the sophisticated
> users who want routed behavior override it manually.
Customer premise gear has a 'front side' and a 'back side', and it is
already well ingrained behaviour for 'back-to-back port chaining' to
create a single large bridged network in the home. What is the
customer's anticipated result from front-to-back chaining?
That seems much more reliable a hint to me than conditional behaviour.
DHCPv6 PD is applicable to the ISP customer premise. DHCPv6 PD
'chaining' however is probably only applicable in some promised future
where there are alternative home network medias to Ethernet, or to the
Enterprise where the boundaries drawn in broadcast domains are
administrative in nature and not technical (but still, all automated).
--
David W. Hankins
DHCPv6PD(PrefixDelegation)にするかブリッジ(RA(RouterAdvertise))にするかはやはり悩むポイント。
法人向けサービスならDHCPv6PDかな。個人向けならRAでもいいじゃん？って個人的に思います。
Subject: DHCPv6 PD chains vs bridging
On Tue, May 05, 2009 at 04:22:04PM -0400, Paul Timmins wrote:
> Sorry for the top post, but as a crazy thought here, why not throw out an
> RA, and if answered, go into transparent bridge mode? Let the sophisticated
> users who want routed behavior override it manually.
Customer premise gear has a 'front side' and a 'back side', and it is
already well ingrained behaviour for 'back-to-back port chaining' to
create a single large bridged network in the home. What is the
customer's anticipated result from front-to-back chaining?
That seems much more reliable a hint to me than conditional behaviour.
DHCPv6 PD is applicable to the ISP customer premise. DHCPv6 PD
'chaining' however is probably only applicable in some promised future
where there are alternative home network medias to Ethernet, or to the
Enterprise where the boundaries drawn in broadcast domains are
administrative in nature and not technical (but still, all automated).
--
David W. Hankins
DHCPv6PD(PrefixDelegation)にするかブリッジ(RA(RouterAdvertise))にするかはやはり悩むポイント。
法人向けサービスならDHCPv6PDかな。個人向けならRAでもいいじゃん？って個人的に思います。
5/05/2009
NANOG@May 4, 2009
Date: Mon, 4 May 2009 04:48:49 +0000 (UTC)
Subject: Re: [quagga-users 10587] bgpd crash - apologies (fwd)
On Mon, 4 May 2009, Ingo Flaschberger wrote:
> ---------- Forwarded message ----------
> Date: Mon, 04 May 2009 00:38:54 +0300
> Subject: [quagga-users 10587] bgpd crash - apologies
>
> Hello,
>
> I learned today that a BGP announcement for which I am the tech-c,
> is causing difficulties with Quagga. First of all, I apologise;
> it's only today that I heard about these difficulties.
[...]
A fix is here:
https://www.caputo.com/foss/quagga-0.99.10-BGP-4-byte-ASN-bug-fixes.patch
https://www.caputo.com/foss/quagga-0.99.11-BGP-4-byte-ASN-bug-fixes.patch
(the patches are identical. naming is just for clarity.)
Chris
各地で話題の4バイトAS下でのQuagga/BGPdクラッシュ話。
NANOGにもパッチ情報が。
Subject: Re: [quagga-users 10587] bgpd crash - apologies (fwd)
On Mon, 4 May 2009, Ingo Flaschberger wrote:
> ---------- Forwarded message ----------
> Date: Mon, 04 May 2009 00:38:54 +0300
> Subject: [quagga-users 10587] bgpd crash - apologies
>
> Hello,
>
> I learned today that a BGP announcement for which I am the tech-c,
> is causing difficulties with Quagga. First of all, I apologise;
> it's only today that I heard about these difficulties.
[...]
A fix is here:
https://www.caputo.com/foss/quagga-0.99.10-BGP-4-byte-ASN-bug-fixes.patch
https://www.caputo.com/foss/quagga-0.99.11-BGP-4-byte-ASN-bug-fixes.patch
(the patches are identical. naming is just for clarity.)
Chris
各地で話題の4バイトAS下でのQuagga/BGPdクラッシュ話。
NANOGにもパッチ情報が。
5/02/2009
NANOG@May 1, 2009
Date: Fri, 01 May 2009 11:35:00 -0700
Subject: Re: Where to buy Internet IP addresses
LEdouard Louis wrote:
> Optimum Online business only offer 5 static IP address.
>
>
>
> Where can I buy a block of Internet IP address for Business? How much
> does it cost?
>
>
>
> Most of our devices only require an internal IP address to reach the
> internet, but we have a Juniper DX for load balancing.
>
>
>
> We must provide Juniper DX with an internet IP address and point it to
> internal IP address for customers to be able to reach it from the
> internet. this is for testing and development purposes and will expect
> several servers on Load-balancer. The 5 static IP addresses just won't
> be enough.
>
Get a different ISP. You can't "buy addresses." You can apply to your
RIR for addresses, but it sounds like you wouldn't qualify if your price
range is 5 statics from your ISP. Also see huge debate on arin-ppml
about buying and selling addresses.
~Seth
ネタにマジレス？
しかしこういうメールが増えてくるのかもしれないなぁと妄想。
Subject: Re: Where to buy Internet IP addresses
LEdouard Louis wrote:
> Optimum Online business only offer 5 static IP address.
>
>
>
> Where can I buy a block of Internet IP address for Business? How much
> does it cost?
>
>
>
> Most of our devices only require an internal IP address to reach the
> internet, but we have a Juniper DX for load balancing.
>
>
>
> We must provide Juniper DX with an internet IP address and point it to
> internal IP address for customers to be able to reach it from the
> internet. this is for testing and development purposes and will expect
> several servers on Load-balancer. The 5 static IP addresses just won't
> be enough.
>
Get a different ISP. You can't "buy addresses." You can apply to your
RIR for addresses, but it sounds like you wouldn't qualify if your price
range is 5 statics from your ISP. Also see huge debate on arin-ppml
about buying and selling addresses.
~Seth
ネタにマジレス？
しかしこういうメールが増えてくるのかもしれないなぁと妄想。
4/29/2009
Outages@Apr 28, 2009
date Tue, Apr 28, 2009 at 6:45 AM
subject Re: [outages] Phoenix Area Network Issues?
There's a ton of chatter about it on the NANOG list now.
Apparently there were some issues with a major AT&T route.
SBC Issues were also reported, this was all about an hour ago.
> In Phoenix here and our XO T1s, Sprint mpls and Internet connection,
> and XO microwave connection are working fine. Cox cable Internet here
> and in Tempe seems fine as well. Where are you experiencing outages?
>
> _____
>
> C. Lauretano
>
>
> > Are there any fiber cuts or other routing issues anyone in the Phoenix
> > area is aware of?
> >
> >
> > Thanks.
フェニックス地域で経路障害発生。
NANOGでも話題に。AT&Tがんばれ。
今はどんな障害でもファイバーカット？と聞くのが定番に？
subject Re: [outages] Phoenix Area Network Issues?
There's a ton of chatter about it on the NANOG list now.
Apparently there were some issues with a major AT&T route.
SBC Issues were also reported, this was all about an hour ago.
> In Phoenix here and our XO T1s, Sprint mpls and Internet connection,
> and XO microwave connection are working fine. Cox cable Internet here
> and in Tempe seems fine as well. Where are you experiencing outages?
>
> _____
>
> C. Lauretano
>
>
> > Are there any fiber cuts or other routing issues anyone in the Phoenix
> > area is aware of?
> >
> >
> > Thanks.
フェニックス地域で経路障害発生。
NANOGでも話題に。AT&Tがんばれ。
今はどんな障害でもファイバーカット？と聞くのが定番に？
4/21/2009
NANOG@Apr 20, 2009
Date: Mon, 20 Apr 2009 18:39:47 -0500 (CDT)
Subject: Important New Requirement for IPv4 Requests
Forwarded message:
> Subject: Important New Requirement for IPv4 Requests
> From: ARIN Registration Services
>
> Hello,
>
> With the approaching depletion of the IPv4 address free pool, the
> ARIN Board of Trustees has directed ARIN staff to take additional
> steps to ensure the legitimacy of all IPv4 address space requests.
> Beginning 18 May 2009, ARIN will require that all applications for
> IPv4 address space include an attestation of accuracy from an officer
> of the organization. For more information on this requirement, please
> see:
>
> https://www.arin.net/resources/agreements/officer_attest.html
>
> Whenever a request for IPv4 resources is received, ARIN will ask in
> its initial reply for the name and contact information of an officer
> of the organization who will be able to attest to the validity of the
> information provided to ARIN.
>
> At the point a request is ready to be approved, ARIN will send a summary
> of the request (via e-mail) to the officer with a cc: to the requesting
> POC (Tech or Admin) and ask the officer to attest to the validity of the
> information provided to ARIN. The summary will provide a brief overview
> of the request and an explanation of the required attestation. ARIN will
> include the original request template and any other relevant information
> the requestor provided. Once ARIN receives the attestation from the
> officer, the request can be approved. Attestation may also be provided
> via fax or postal mail.
>
> For further assistance, contact ARIN's Registration Services Help Desk
> via e-mail to hostmaster@arin.net or telephone at +1.703.227.0660.
Let me see if I can understand this.
We're running out of IPv4 space.
Knowing that blatant lying about IP space justifications has been an
ongoing game in the community, ARIN has decided to "do something" about
it.
So now they're going to require an attestation. Which means that they
are going to require an "officer" to "attest" to the validity of the
information.
So the "officer," most likely not being a technical person, is going to
contact ... probably the same people who made the request, ask them if
they need the space. Right?
And why would the answer be any different, now?
... JG
ARINは新しいIP要求に対し、経営者に確認のメールなどを送ることを考えている。
それに対して異論が出てきています。
Subject: Important New Requirement for IPv4 Requests
Forwarded message:
> Subject: Important New Requirement for IPv4 Requests
> From: ARIN Registration Services
>
> Hello,
>
> With the approaching depletion of the IPv4 address free pool, the
> ARIN Board of Trustees has directed ARIN staff to take additional
> steps to ensure the legitimacy of all IPv4 address space requests.
> Beginning 18 May 2009, ARIN will require that all applications for
> IPv4 address space include an attestation of accuracy from an officer
> of the organization. For more information on this requirement, please
> see:
>
> https://www.arin.net/resources/agreements/officer_attest.html
>
> Whenever a request for IPv4 resources is received, ARIN will ask in
> its initial reply for the name and contact information of an officer
> of the organization who will be able to attest to the validity of the
> information provided to ARIN.
>
> At the point a request is ready to be approved, ARIN will send a summary
> of the request (via e-mail) to the officer with a cc: to the requesting
> POC (Tech or Admin) and ask the officer to attest to the validity of the
> information provided to ARIN. The summary will provide a brief overview
> of the request and an explanation of the required attestation. ARIN will
> include the original request template and any other relevant information
> the requestor provided. Once ARIN receives the attestation from the
> officer, the request can be approved. Attestation may also be provided
> via fax or postal mail.
>
> For further assistance, contact ARIN's Registration Services Help Desk
> via e-mail to hostmaster@arin.net or telephone at +1.703.227.0660.
Let me see if I can understand this.
We're running out of IPv4 space.
Knowing that blatant lying about IP space justifications has been an
ongoing game in the community, ARIN has decided to "do something" about
it.
So now they're going to require an attestation. Which means that they
are going to require an "officer" to "attest" to the validity of the
information.
So the "officer," most likely not being a technical person, is going to
contact ... probably the same people who made the request, ask them if
they need the space. Right?
And why would the answer be any different, now?
... JG
ARINは新しいIP要求に対し、経営者に確認のメールなどを送ることを考えている。
それに対して異論が出てきています。
4/20/2009
NANOG@Apr 19, 2009
Date: Sun, 19 Apr 2009 12:55:45 -0700 (PDT)
Subject: SkypeSetup Rogue Download
Has anyone seen anything like this?
http://www.virustotal.com/analisis/f58203f8d5cb98628eaa785e27c9e059
SkypeSetup.exeがVirusTotalを通してみるとウィルスに感染しているように見える。
返信としてDownload.comからダウンロードしたものは大丈夫だったよ、と。
怪しい？
Subject: SkypeSetup Rogue Download
Has anyone seen anything like this?
http://www.virustotal.com/analisis/f58203f8d5cb98628eaa785e27c9e059
SkypeSetup.exeがVirusTotalを通してみるとウィルスに感染しているように見える。
返信としてDownload.comからダウンロードしたものは大丈夫だったよ、と。
怪しい？
4/18/2009
NANOG@Apr 17, 2009
Date: Fri, 17 Apr 2009 22:56:31 +0000
Subject: Re: US west coast personal colo
On Fri, Apr 17, 2009 at 06:50:42PM -0400, Sean Donelan wrote:A
>
> Is anyone still doing personal colo on the west coast? I'm looking for a
> new home for my personal server on the west coast, and it seems like
> the economy has taken out most of the old personal colo offers.
> Even the old web page on www.vix.com/personalcolo is gone.
> A
there are a few of us still around.
--bill
米国西海岸で個人用コロケーションってない？という質問に、まだいくつかあるよ、という回答。
願わくばURLまで教えて欲しかった。。。
Subject: Re: US west coast personal colo
On Fri, Apr 17, 2009 at 06:50:42PM -0400, Sean Donelan wrote:A
>
> Is anyone still doing personal colo on the west coast? I'm looking for a
> new home for my personal server on the west coast, and it seems like
> the economy has taken out most of the old personal colo offers.
> Even the old web page on www.vix.com/personalcolo is gone.
> A
there are a few of us still around.
--bill
米国西海岸で個人用コロケーションってない？という質問に、まだいくつかあるよ、という回答。
願わくばURLまで教えて欲しかった。。。
NANOG@Apr 17, 2009
Date: Fri, 17 Apr 2009 10:11:30 -0400
Subject: IXP
Hello NANOG,
I like would to know what are best practices for an internet exchange. I
have some concerns about the following;
Can the IXP members use RFC 1918 ip addresses for their peering?
Can the IXP members use private autonomous numbers for their peering?
Maybe the answer is obviuos, but I like to know from any IXP admins what
their setup/experiences have been.
--
--sharlon
IXPのメンバーはプライベートアドレスやプライベートASを使ってもいいの？という質問。
使えるとは思うけど、グローバルでやらない理由はなにかな？
Subject: IXP
Hello NANOG,
I like would to know what are best practices for an internet exchange. I
have some concerns about the following;
Can the IXP members use RFC 1918 ip addresses for their peering?
Can the IXP members use private autonomous numbers for their peering?
Maybe the answer is obviuos, but I like to know from any IXP admins what
their setup/experiences have been.
--
--sharlon
IXPのメンバーはプライベートアドレスやプライベートASを使ってもいいの？という質問。
使えるとは思うけど、グローバルでやらない理由はなにかな？
4/16/2009
NANOG@Apr 15, 2009
Date: Wed, 15 Apr 2009 00:51:36 -0700
Subject: Anyone from Intelligence Network Online?
Hi -
I wanted to see if anyone is here from Intelligence Network Online - I
suspect an old AS number and a /16 of yours is being hijacked by a spam gang
operating in downtown LA and wanted to get some confirmation.
-Justin
誰か諜報ネットワークの人いない？LAのダウンタウンにいるSPAMGANGに古いAS番号と/16のIPアドレスをハイジャックされた疑いがあるのだが、確証を得たい、というメール。
日本には経路奉行/テレコムISAC/JPIRRがあるが米国にはそういう枠組みがない。
BGPlayがあるのみ。欧州にはRISがあるがやはり起こった事象の記録が残るのみ。
経路奉行はリアルタイムにハイジャック情報を流せる世界に誇れるシステム。すばらしい。
Subject: Anyone from Intelligence Network Online?
Hi -
I wanted to see if anyone is here from Intelligence Network Online - I
suspect an old AS number and a /16 of yours is being hijacked by a spam gang
operating in downtown LA and wanted to get some confirmation.
-Justin
誰か諜報ネットワークの人いない？LAのダウンタウンにいるSPAMGANGに古いAS番号と/16のIPアドレスをハイジャックされた疑いがあるのだが、確証を得たい、というメール。
日本には経路奉行/テレコムISAC/JPIRRがあるが米国にはそういう枠組みがない。
BGPlayがあるのみ。欧州にはRISがあるがやはり起こった事象の記録が残るのみ。
経路奉行はリアルタイムにハイジャック情報を流せる世界に誇れるシステム。すばらしい。
NANOG@Apr 15, 2009
Date: Wed, 15 Apr 2009 14:35:37 -0500
Subject: Level3 funkiness
Anyone else experience sporadic funkiness via
Level3? I can't even reach the main website from who
knows how many networks I've tried. Also friends
and former colleagues have tried to reach the site
to no avail.
One of my machines on AT&T:
# traceroute level3.net
traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets
4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms
5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms
6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms
7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms
8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms
9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms
10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms
11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms
12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms
13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms
14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms
15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H
(From Texas through Above.net)
$ traceroute level3.net|tail -n 1
traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets
11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H
Confirmed it can't be reached from Travelers Ins, The
Hartford, none of my connections. Anyone else seeing
issues? I'm seeing drop off from clients going through
their Atlanta interconnects with Charter and two other
providers, which I can't make sense of. I DO KNOW they
experienced some sort of issue with a TDM switch or so
they said... Very broad statements: "We know teh
interwebs are down please stand by"
I know websites are one thing, but the chances of the
website going down, a TDM switch being wacky and now
clients traversing their networks complaining all at
once seems a little out of the ordinary.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP
Level3.netに繋がらないんだけど・・・というメール。
Level3.comなら見えるぜという返事や、うちも同じ状況だというメール、アトランタでLevel3とピアしてるうちのISPは見えてるよ、という報告が続々と入ってきています。
とりあえず、Level3.comとLevel3.netは同一ホストなんだけどね・・・
Subject: Level3 funkiness
Anyone else experience sporadic funkiness via
Level3? I can't even reach the main website from who
knows how many networks I've tried. Also friends
and former colleagues have tried to reach the site
to no avail.
One of my machines on AT&T:
# traceroute level3.net
traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets
4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms
5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms
6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms
7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms
8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms
9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms
10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms
11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms
12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms
13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms
14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms
15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H
(From Texas through Above.net)
$ traceroute level3.net|tail -n 1
traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets
11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H
Confirmed it can't be reached from Travelers Ins, The
Hartford, none of my connections. Anyone else seeing
issues? I'm seeing drop off from clients going through
their Atlanta interconnects with Charter and two other
providers, which I can't make sense of. I DO KNOW they
experienced some sort of issue with a TDM switch or so
they said... Very broad statements: "We know teh
interwebs are down please stand by"
I know websites are one thing, but the chances of the
website going down, a TDM switch being wacky and now
clients traversing their networks complaining all at
once seems a little out of the ordinary.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP
Level3.netに繋がらないんだけど・・・というメール。
Level3.comなら見えるぜという返事や、うちも同じ状況だというメール、アトランタでLevel3とピアしてるうちのISPは見えてるよ、という報告が続々と入ってきています。
とりあえず、Level3.comとLevel3.netは同一ホストなんだけどね・・・
4/11/2009
NANOG@Apr 10, 2009
Date: Fri, 10 Apr 2009 08:45:46 +0000 (GMT)
From: "Leland E. Vandervort"
Subject: SIP - perhaps botnet? anyone else seeing this?
To: nanog@nanog.org
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi All,
Over the past couple of days we have been seeing an exponential increase
(about 200-fold)
in the amount of UDP SIP Control traffic in our netflow data. The past 24
hours, for example, has shown a total of nearly 300 GB of this traffic
incoming and over 400 GB outgoing -- this despite the fact that we do not
host any SIP services ourselves, and currently to my knowledge, we have no
hosting customers running any kind of SIP services. (Total RTP traffic
for 24 hours is only in the region of 150 Kb -- so a vast inbalance
between control and RTP)
The local sources/destinations of the traffic are within our hosting
space, but are spread across a wide range of hosts (i.e. nothing really
related to a single or handful of hosts).
Additionally over the past couple of days we have seen an increase of
mails to our abuse desk for "brute force" attempts against a number of SIP
services... possibly directly related to this traffic.
Is anyone aware of a new variant or modus-operandi of botnets in
circulation in the past couple of days which attempt to exploit SIP
services? Has anyone else notice a significant increase in this kind of
traffic?
Thanks
Leland
3/30にGTERでも話題になった、無差別攻撃SIPパケットについて。
やはりBotnetなのか？
From: "Leland E. Vandervort"
Subject: SIP - perhaps botnet? anyone else seeing this?
To: nanog@nanog.org
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi All,
Over the past couple of days we have been seeing an exponential increase
(about 200-fold)
in the amount of UDP SIP Control traffic in our netflow data. The past 24
hours, for example, has shown a total of nearly 300 GB of this traffic
incoming and over 400 GB outgoing -- this despite the fact that we do not
host any SIP services ourselves, and currently to my knowledge, we have no
hosting customers running any kind of SIP services. (Total RTP traffic
for 24 hours is only in the region of 150 Kb -- so a vast inbalance
between control and RTP)
The local sources/destinations of the traffic are within our hosting
space, but are spread across a wide range of hosts (i.e. nothing really
related to a single or handful of hosts).
Additionally over the past couple of days we have seen an increase of
mails to our abuse desk for "brute force" attempts against a number of SIP
services... possibly directly related to this traffic.
Is anyone aware of a new variant or modus-operandi of botnets in
circulation in the past couple of days which attempt to exploit SIP
services? Has anyone else notice a significant increase in this kind of
traffic?
Thanks
Leland
3/30にGTERでも話題になった、無差別攻撃SIPパケットについて。
やはりBotnetなのか？
4/10/2009
NANOG@Apr 9, 2009
Date: Thu, 9 Apr 2009 15:48:32 +0000
From: "Lee, Steven (NSG Malaysia)"
Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ?
To: "nanog@nanog.org"
Message-ID:
<084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net>
Content-Type: text/plain; charset="us-ascii"
Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) networks have Gi segment (interface between GGSN & IP Router/firewall). Due to the IP address constraint, operator usually do NAT on the Gi firewall to NAT the private IP to public IP in the past. Looking at the traffic pattern and user access behaviour, does it make sense to have firewall between the GGSN & Public Internet if the public IP addresses are sufficient to cater for mobile subscribers? Especially with 3G/UMTS/HSPA or even LTE in the future.
Please share your thought and thanks in advance :)
Regards,
Steven Lee
携帯ネットワークにもファイアウォールが必要か否か、という質問。
ブロードバンドネットワークにそんなもの突っ込んでないんだから要らないよ、という意見と、
古い機器が繋がってるから必要かも、という意見が出てきています。
From: "Lee, Steven (NSG Malaysia)"
Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ?
To: "nanog@nanog.org"
Message-ID:
<084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net>
Content-Type: text/plain; charset="us-ascii"
Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) networks have Gi segment (interface between GGSN & IP Router/firewall). Due to the IP address constraint, operator usually do NAT on the Gi firewall to NAT the private IP to public IP in the past. Looking at the traffic pattern and user access behaviour, does it make sense to have firewall between the GGSN & Public Internet if the public IP addresses are sufficient to cater for mobile subscribers? Especially with 3G/UMTS/HSPA or even LTE in the future.
Please share your thought and thanks in advance :)
Regards,
Steven Lee
携帯ネットワークにもファイアウォールが必要か否か、という質問。
ブロードバンドネットワークにそんなもの突っ込んでないんだから要らないよ、という意見と、
古い機器が繋がってるから必要かも、という意見が出てきています。
NANOG@Apr 9, 2009
Date: Thu, 09 Apr 2009 08:14:15 -0700
From: Craig Holland
Subject: Fiber cut in SF area
To: NANOG
Message-ID:
Content-Type: text/plain; charset="US-ASCII"
Just dropping a note that there is a fiber cut in the SF area (I have a
metro line down). AboveNet is reporting issues and I've heard unconfirmed
reports that ATT and VZW are affected as well.
Rgs,
craig
サンフランシスコ地域で回線障害が発生の模様。
続報が入ってきています。
Yup. Abovenet fiber between 200 Paul SFO and 11 Great Oaks SJC is currently
out of commission.
200 Paul Ave is seeing several carriers down. I am also in Santa Cruz and cannot make or receive long distance calls on my land lines. Unconfirmed reports of Caltrain cut.
Confirmed VZW & ATT;
http://cbs5.com/local/phone.internet.outage.2.980578.html
Rather widespread "general telco" outage, the county has deployed
extra patrol units in the south bay to compensate for not being able
to call 911.
Third video link in shows repairs underway.
緊急電話も使えない状態だった模様。
Additional news stories reporting second fiber cut on Sprint fiber
in San Carlos, between San Francisco and San Jose, the SF Gate article above
was updated at 12:20pm with that information.
San Jose cut at around 1:30am, San Carlos around 3:30am.
さらに別地域でも。
http://sandbox.bitgravity.com/blog/2009/04/09/destroy-the-internet-with-a-hacksaw/
影響範囲の地図付きのBlog
Activity Type Code Desc: PROGRESS COMMENTS
Activity Type Code: PROG
OTDR readings were taken by AT&T West and a cut was located 1600 ft from
the San Jose, CA central office. AT&T West technicians are onsite
working to isolate the exact location of the cut. There are 4 cables
impacted. AT&T Mobility has 61 GSM and 45 co-located UMTS sites out of
service off of Santa Clara Base Station Controllers 15 & 23, and Santa
Clara Radio Network Controller 4. E911 has 52 Location Measuring Units
down. The AT&T West Santa Cruz 11 central office (41,803 ATNs) is
experiencing an SS7 isolation and the San Martin central office (11,904
ATNs) lost it's umbilical and is isolated at this time. The Bailey
remote site (4,973 ATNs) is also isolated. Scott's Valley has 3 out of 4
SS7 links down. The Santa Cruz 01, Aptos, Scott's Valley, Felton,
Boulder Creek, Ben Lomand, San Jose 11, San Jose 13, San Jose 21 central
offices have trunks impacted such that all lines are busy and incoming
calls are receiving trouble messages. The Santa Cruz County SO (178,040
ATNs), Scott's Valley PD (12,007 ATNs) and the UC Santa Cruz PD (14,909
ATNs) are all without ALI at this time. The Gilroy PD PSAP and the
Morgan Hill PD and CDF have been rerouted with ALI/ANI. The Felton CDF
has not been rerouted. There are 17 DSLAMS and 4 ATMS out of service
impacting DSL service. There are 3 SMDI Links down impacting voicemail
service. Verizon's Morgan Hill and Gilroy central offices are currently
isolated. There have been 224,865 blocked calls.
こういう時はOTDRが大活躍。
なんだか5箇所で切断という情報も。テロ？
GIGAZINEでも扱われました。
http://gigazine.net/index.php?/news/comments/20090411_pie/
From: Craig Holland
Subject: Fiber cut in SF area
To: NANOG
Message-ID:
Content-Type: text/plain; charset="US-ASCII"
Just dropping a note that there is a fiber cut in the SF area (I have a
metro line down). AboveNet is reporting issues and I've heard unconfirmed
reports that ATT and VZW are affected as well.
Rgs,
craig
サンフランシスコ地域で回線障害が発生の模様。
続報が入ってきています。
Yup. Abovenet fiber between 200 Paul SFO and 11 Great Oaks SJC is currently
out of commission.
200 Paul Ave is seeing several carriers down. I am also in Santa Cruz and cannot make or receive long distance calls on my land lines. Unconfirmed reports of Caltrain cut.
Confirmed VZW & ATT;
http://cbs5.com/local/phone.internet.outage.2.980578.html
Rather widespread "general telco" outage, the county has deployed
extra patrol units in the south bay to compensate for not being able
to call 911.
Third video link in shows repairs underway.
緊急電話も使えない状態だった模様。
Additional news stories reporting second fiber cut on Sprint fiber
in San Carlos, between San Francisco and San Jose, the SF Gate article above
was updated at 12:20pm with that information.
San Jose cut at around 1:30am, San Carlos around 3:30am.
さらに別地域でも。
http://sandbox.bitgravity.com/blog/2009/04/09/destroy-the-internet-with-a-hacksaw/
影響範囲の地図付きのBlog
Activity Type Code Desc: PROGRESS COMMENTS
Activity Type Code: PROG
OTDR readings were taken by AT&T West and a cut was located 1600 ft from
the San Jose, CA central office. AT&T West technicians are onsite
working to isolate the exact location of the cut. There are 4 cables
impacted. AT&T Mobility has 61 GSM and 45 co-located UMTS sites out of
service off of Santa Clara Base Station Controllers 15 & 23, and Santa
Clara Radio Network Controller 4. E911 has 52 Location Measuring Units
down. The AT&T West Santa Cruz 11 central office (41,803 ATNs) is
experiencing an SS7 isolation and the San Martin central office (11,904
ATNs) lost it's umbilical and is isolated at this time. The Bailey
remote site (4,973 ATNs) is also isolated. Scott's Valley has 3 out of 4
SS7 links down. The Santa Cruz 01, Aptos, Scott's Valley, Felton,
Boulder Creek, Ben Lomand, San Jose 11, San Jose 13, San Jose 21 central
offices have trunks impacted such that all lines are busy and incoming
calls are receiving trouble messages. The Santa Cruz County SO (178,040
ATNs), Scott's Valley PD (12,007 ATNs) and the UC Santa Cruz PD (14,909
ATNs) are all without ALI at this time. The Gilroy PD PSAP and the
Morgan Hill PD and CDF have been rerouted with ALI/ANI. The Felton CDF
has not been rerouted. There are 17 DSLAMS and 4 ATMS out of service
impacting DSL service. There are 3 SMDI Links down impacting voicemail
service. Verizon's Morgan Hill and Gilroy central offices are currently
isolated. There have been 224,865 blocked calls.
こういう時はOTDRが大活躍。
なんだか5箇所で切断という情報も。テロ？
GIGAZINEでも扱われました。
http://gigazine.net/index.php?/news/comments/20090411_pie/
4/09/2009
NANOG@Apr 8, 2009
Date: Wed, 8 Apr 2009 18:33:48 -0700
From: Jo Rhett
Subject: options for full routing table in 1 year?
To: NANOG list
Message-ID:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I was chatting with someone the other day and we were trying to build
a complete list of all units which can handle full routing tables 1
year from now, assuming current 4k/month growth (nevermind de-
aggregation)
Juniper M/T-series units could handle 600k before, now 1mil with I-
chip upgrade?
Juniper MX-series units are always 1mil
Cisco 6500/7600 with SUP720-3BXL handles 1mil routes
Force10 E300/600/1200 with dual-cam line cards handle 512k routes
Force10 E600/1200 with Exascale (quad-cam) line cards handle 1mil routes
Is there anything I'm forgetting here?
And if you already have one of these units, the upgrades are:
Juniper M-series units can replace the FPIC card to get new I-chip?
...if I understand it, no other cards need replaced
Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL
...if I understand it, no other cards need replaced?
(note that this disagrees with my understanding of how their FIB/CEF
works so I'm curious about this)
Force10 you replace every single line card, since the entire chassis
is limited to the smallest CAM size available.
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
NANOGでも経路爆発に備える為かハイエンドのルータ情報を集める人が出てきた。
これもIP移転に伴う動きか。
From: Jo Rhett
Subject: options for full routing table in 1 year?
To: NANOG list
Message-ID:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I was chatting with someone the other day and we were trying to build
a complete list of all units which can handle full routing tables 1
year from now, assuming current 4k/month growth (nevermind de-
aggregation)
Juniper M/T-series units could handle 600k before, now 1mil with I-
chip upgrade?
Juniper MX-series units are always 1mil
Cisco 6500/7600 with SUP720-3BXL handles 1mil routes
Force10 E300/600/1200 with dual-cam line cards handle 512k routes
Force10 E600/1200 with Exascale (quad-cam) line cards handle 1mil routes
Is there anything I'm forgetting here?
And if you already have one of these units, the upgrades are:
Juniper M-series units can replace the FPIC card to get new I-chip?
...if I understand it, no other cards need replaced
Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL
...if I understand it, no other cards need replaced?
(note that this disagrees with my understanding of how their FIB/CEF
works so I'm curious about this)
Force10 you replace every single line card, since the entire chassis
is limited to the smallest CAM size available.
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
NANOGでも経路爆発に備える為かハイエンドのルータ情報を集める人が出てきた。
これもIP移転に伴う動きか。
4/08/2009
NANOG@Apr 7,2009
Date: Tue, 07 Apr 2009 14:10:24 -0700
From: Charles Wyble
Subject: Verizon EVDO Issues
To: "nanog@nanog.org"
Message-ID: <49DBC140.1040805@thewybles.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Been troubleshooting a very strange problem for a couple of weeks now.
I have a few hundred systems deployed throughout the United States
utilizing EVDO connectivity with Verizon as a carrier. They are stationary.
Over the past few weeks clusters of them in SF and Lewisville TX and a
few other areas have been failing intermittently. They are offline for
several days, then online for a few days then go offline again. They are
running Linux and PPPD.
Has anyone else seen anything like this? I realize that there are very
few other organizations with a network footprint like ours (few hundred
static EVDO cards). Other large users like FedEx and Amtrak aren't
reporting any issues. Verizon wants to replace the cards, but that
doesn't seem like a viable solution, as it's localized to a few areas
and is intermittent.
Replies on or off list appreciated.
米国でベライゾンのインフラでEVDOキャリアをやっているエンジニアからの相談。
この2週間、サンフランシスコの一部と、テキサスの一部その他で接続障害が起きているらしい。
日本のように携帯キャリア垂直統合の国と、他の国のようにアクセスとアカウントが
分離している国ではトラブルシュートの仕方も違うのかな。
#アクセスとアカウントが分離しているというのはフレッツ網とその上のISPという関係に近いか。
From: Charles Wyble
Subject: Verizon EVDO Issues
To: "nanog@nanog.org"
Message-ID: <49DBC140.1040805@thewybles.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Been troubleshooting a very strange problem for a couple of weeks now.
I have a few hundred systems deployed throughout the United States
utilizing EVDO connectivity with Verizon as a carrier. They are stationary.
Over the past few weeks clusters of them in SF and Lewisville TX and a
few other areas have been failing intermittently. They are offline for
several days, then online for a few days then go offline again. They are
running Linux and PPPD.
Has anyone else seen anything like this? I realize that there are very
few other organizations with a network footprint like ours (few hundred
static EVDO cards). Other large users like FedEx and Amtrak aren't
reporting any issues. Verizon wants to replace the cards, but that
doesn't seem like a viable solution, as it's localized to a few areas
and is intermittent.
Replies on or off list appreciated.
米国でベライゾンのインフラでEVDOキャリアをやっているエンジニアからの相談。
この2週間、サンフランシスコの一部と、テキサスの一部その他で接続障害が起きているらしい。
日本のように携帯キャリア垂直統合の国と、他の国のようにアクセスとアカウントが
分離している国ではトラブルシュートの仕方も違うのかな。
#アクセスとアカウントが分離しているというのはフレッツ網とその上のISPという関係に近いか。
4/07/2009
NANOG@Apr 6, 2009
Date: Mon, 6 Apr 2009 13:02:26 -0700
From: Leo Vegoda
Subject: Re: eGLOP and/or 232/8 question (SSM)
To: Ryan Landry, "nanog@nanog.org"
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
Hi Ryan,
On 06/04/2009 10:51, "Ryan Landry" wrote:
> i apologize if this has been discussed...searching mboned/nanog/ietf/arin/etc
> archives doesn't give me the clarification i hoped for.
>
> is there a defined method to request eGLOP space? does anyone really care
> what people use internally for mcast? i see mr. eubanks submitted a proposal
> back in 2007 for eGLOP assignment process and ARIN shot it down, but i can't
> seem to find current status.
If you need additional IPv4 multicast address space you can request it using
the form on this page:
http://www.iana.org/protocols/apply/
The EGLOP space is set to become additional AD-HOC multicast space. The
draft for this can be found at:
http://tools.ietf.org/id/draft-ietf-mboned-rfc3171bis
Hope this helps,
Leo
eGLOPについての質問に対し、IANAのIPリソースマネージャー直々のご回答。
4バイトASの人はどうしたらいいのかな？eGLOPの対象外じゃないかな・・・
From: Leo Vegoda
Subject: Re: eGLOP and/or 232/8 question (SSM)
To: Ryan Landry
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
Hi Ryan,
On 06/04/2009 10:51, "Ryan Landry"
> i apologize if this has been discussed...searching mboned/nanog/ietf/arin/etc
> archives doesn't give me the clarification i hoped for.
>
> is there a defined method to request eGLOP space? does anyone really care
> what people use internally for mcast? i see mr. eubanks submitted a proposal
> back in 2007 for eGLOP assignment process and ARIN shot it down, but i can't
> seem to find current status.
If you need additional IPv4 multicast address space you can request it using
the form on this page:
http://www.iana.org/protocols/apply/
The EGLOP space is set to become additional AD-HOC multicast space. The
draft for this can be found at:
http://tools.ietf.org/id/draft-ietf-mboned-rfc3171bis
Hope this helps,
Leo
eGLOPについての質問に対し、IANAのIPリソースマネージャー直々のご回答。
4バイトASの人はどうしたらいいのかな？eGLOPの対象外じゃないかな・・・
4/06/2009
NANOG@Apr 5, 2009
Date: Sun, 05 Apr 2009 07:00:53 +0000
From: Paul Vixie
Subject: Re: ISC DLV
To: nanog@merit.edu
Message-ID:
Content-Type: text/plain; charset=us-ascii
Paul Ferguson writes:
> On Sat, Apr 4, 2009 at 9:55 PM, Marcelo Gardini do Amaral
> wrote:
>
>> Guys,
>>
>> are you having problems to validate DNSEC using ISC DLV?
>>
>
> No idea, but I did see another reference to this over on the OARC dns-ops
> list:
>
> https://lists.dns-oarc.net/pipermail/dns-operations/2009-April/003726.html
note, this isn't a ddos, so it's probably not related to the other dns ddos
events that have been discussed here recently.
see also geoff's reply on that thread:
Date: Sat, 04 Apr 2009 23:15:55 -0700
From: "Geoffrey Sisson"
To: dns-operations@lists.dns-oarc.net
Subject: Re: [dns-operations] ISC DLV broken?
Sender: dns-operations-bounces@lists.dns-oarc.net
mvn@ucla.edu (Michael Van Norman) wrote:
> Starting a bit after 18:00, my home machines starting failing DNSSEC
> validation using the ISC DLV.
...
> Are other people seeing this?
Yes, starting at around the same time (PDT).
Peter_Losher@isc.org (Peter Losher) wrote:
> ISC is aware that there is a issue with lookups against dlv.isc.org and
> are investigating the cause behind it. You may want to disable DNSSEC
> validation against dlv.isc.org at this time.
It appears as if the RRSIG RRset returned by the DLV nameservers for
"dlv.isc.org" is missing the RRSIG for the KSK, so validation for
dlv.isc.org is failing. It _does_ contain the RRSIG for the ZSK (key
id 64263).
As a test I tried changing the trusted key to the ZSK, and DLV validation
appeared to work correctly. This is, of course, not a recommended
work-around.
Geoff
_______________________________________________
dns-operations mailing list
DLVの障害に関して。
NetworkというよりもDNSの障害なのでdns-operationsに正しくルーティングされました。
From: Paul Vixie
Subject: Re: ISC DLV
To: nanog@merit.edu
Message-ID:
Content-Type: text/plain; charset=us-ascii
Paul Ferguson
> On Sat, Apr 4, 2009 at 9:55 PM, Marcelo Gardini do Amaral
>
>
>> Guys,
>>
>> are you having problems to validate DNSEC using ISC DLV?
>>
>
> No idea, but I did see another reference to this over on the OARC dns-ops
> list:
>
> https://lists.dns-oarc.net/pipermail/dns-operations/2009-April/003726.html
note, this isn't a ddos, so it's probably not related to the other dns ddos
events that have been discussed here recently.
see also geoff's reply on that thread:
Date: Sat, 04 Apr 2009 23:15:55 -0700
From: "Geoffrey Sisson"
To: dns-operations@lists.dns-oarc.net
Subject: Re: [dns-operations] ISC DLV broken?
Sender: dns-operations-bounces@lists.dns-oarc.net
mvn@ucla.edu (Michael Van Norman) wrote:
> Starting a bit after 18:00, my home machines starting failing DNSSEC
> validation using the ISC DLV.
...
> Are other people seeing this?
Yes, starting at around the same time (PDT).
Peter_Losher@isc.org (Peter Losher) wrote:
> ISC is aware that there is a issue with lookups against dlv.isc.org and
> are investigating the cause behind it. You may want to disable DNSSEC
> validation against dlv.isc.org at this time.
It appears as if the RRSIG RRset returned by the DLV nameservers for
"dlv.isc.org" is missing the RRSIG for the KSK, so validation for
dlv.isc.org is failing. It _does_ contain the RRSIG for the ZSK (key
id 64263).
As a test I tried changing the trusted key to the ZSK, and DLV validation
appeared to work correctly. This is, of course, not a recommended
work-around.
Geoff
_______________________________________________
dns-operations mailing list
DLVの障害に関して。
NetworkというよりもDNSの障害なのでdns-operationsに正しくルーティングされました。
登録:
投稿 (Atom)
