I can access it from Canada, but it seems that the first page is missing some info which are typically there. Priyantha Wightman Internet

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Todd Mitchell - lists Sent: Monday, March 15, 2004 3:23 PM To: nanog@nanog.org Subject: RE: Cisco website www.cisco.com 403 forbidden?

| Behalf Of Jay Hennigan | Sent: March 15, 2004 3:19 PM | | Is it just me that they don't like?

Apparently they don't like me either. On top of that, they're running Apache 1.0--not so good.

Todd

--

Can anyone point me at any papers that talk about security issues raised by private networks passing dns requests for RFC 1918 private address space out to their ISP's dns servers? I'm aware of the issues involved with an ISP passing the requests on to the root servers but was looking specifically for security type issues relating to a private network passing the requests out to their ISP's dns servers. Geo.

Geo. wrote:

Can anyone point me at any papers that talk about security issues raised by private networks passing dns requests for RFC 1918 private address space out to their ISP's dns servers?

I've never seen the whole paper on the topic. Leaking the fact that you use 10.10.10.0/24 or whatever internally is not a big deal. It's security by obscurity of the very weak kind. Anyone with half of a clue will drop traffic with a source or destination address of their internal RFC1918 networks at the border, (and even if one uses registered addresses internally, you would be dropping traffic with a souce address of the internal network from entering at the border). That's the "real" security.

I'm aware of the issues involved with an ISP passing the requests on to the root servers but was looking specifically for security type issues relating to a private network passing the requests out to their ISP's dns servers.

These requests will not go to the root servers any more than any other reverse lookups ISP's DNS, $ dig -x 10 ns ; <<>> DiG 8.3 <<>> -x ns ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUERY SECTION: ;; 10.in-addr.arpa, type = NS, class = IN ;; ANSWER SECTION: 10.in-addr.arpa. 1W IN NS blackhole-1.iana.org. 10.in-addr.arpa. 1W IN NS blackhole-2.iana.org. ;; ADDITIONAL SECTION: blackhole-1.iana.org. 16m43s IN A 192.175.48.6 blackhole-2.iana.org. 16m43s IN A 192.175.48.42 ;; Total query time: 53 msec ;; FROM: sec-tools.corp.globalstar.com to SERVER: default -- 207.88.152.10 ;; WHEN: Tue Mar 16 09:53:44 2004 The IN-ADDR.ARPA delegations for RFC1918 space are just like any other block. You'll just end up hitting IANA's blackhole servers, and not all that much, the cache times are one week. Of course, the obvious "fix" is to run your own internal DNS which is authorative for your RFC1918 addresses. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com

The IN-ADDR.ARPA delegations for RFC1918 space are just like any other block. You'll just end up hitting IANA's blackhole servers, and not all that much, the cache times are one week.

In theory, yes. In reality there are quite a few resolvers that, apparently, do not receive the delegation response and continue to hit the roots with PTR queries for RFC1918 space. Recent measurements at a single instance of an anycasted root server show that at least 250 such resolvers generate between 60-120 RFC1918 PTR queries/sec. Duane W.

Is there something special about RFC1918 in this respect? Wouldn't these resolvers not work for all of the IN-ADDR.ARPA space? Wouldn't they be hitting the roots with all kinds of PTR queries?

Good question. Certainly I do see plenty of non-1918 PTR queries as well, but I don't have good stats on that.

If he has broken resolvers, but the ISP servers are sane, he'll obviously end up pounding the ISP servers and perhaps the IANA blackhole servers if the queries are unique, but not the root servers.

Agreed. Duane W.

On Tue, 16 Mar 2004 10:08:28 PST, bill said:

http://www.nanog.org/mtg-0210/wessels.html has some very good information about some of the problems w/ leaked queries.

http://as112.net/ has some mitigation stratagies.

That mitigates the issue, but fails to deal with the root cause. One has to wonder - if a network is spewing enough broken DNS packets that it's noticable, and it's not getting fixed, what *else* is wrong with the network. Remember - every packet you see is a timeout happening back at the misconfigured site. It's like a car with one headlight out - yes, it still works, but whenever I see one on the road, I wonder what ELSE is marginal (like brake pads)....

On Mon, Mar 15, 2004 at 03:38:39PM -0500, Richard Danielli wrote:

Anyone going to open a TAC case ?

Good god, is there really so little interesting shit on the Internet that we are reduced to 20 post long threads me too-ing a 30 minute outage of a website which is now fixed? The god damn packet kiddies were more interesting than this crap. Enough already! -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

On Mon, 15 Mar 2004, Laurence F. Sheldon, Jr. wrote:

Jay Hennigan wrote:

...

Is it just me that they don't like?

I've seen one or two other reports.

Seems like a good opportunity for a round of Wild Speculation.

"Cisco is under spam attack" "Cisco has closed their website because Vendor J made fun of it" "Cisco just lost all of their data! Call DataSafe!" "An intern unplugged the website" "Cisco decided to use SPEWS to control access to their website"

On Mon, March 15, 2004 3:41 pm, Todd Mitchell - lists said:

| Behalf Of Jay Hennigan | Sent: March 15, 2004 3:19 PM | | Is it just me that they don't like?

All fixed now, but load times are hella slow:

Probably a million other people just discovered it was back up as well. I know alot of users that will just sit there, hitting refresh over and over again until the site finally comes up, instead of just going to do something else and coming back later. Then, when it finally comes back up, you have a million users who are hitting refresh over and over again because the site is slow, creating even more load, and you get the picture. :-) -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The AHBL - http://www.ahbl.org