Sadly this article seems to be very true even for germanys ISP business.

That is at least when it comes to buying for small to medium business needs, the big fat pipes are usually much easier to come by and establish altough they too take time off course.

Ok lets make this short: yes, i’ve seen the phenomenon too. Small bandwidth needs do not seem to be an interesting territory for the ever converging ISP industry. This is there many markets are not satisfied and where ISPs that know where they can offer what simply reign.

Anyways, i just thought i’d try hooking them up with a trackback and off course for me to find that entry again. ;-)

Ok so, my RSS feeds were br0ken.

After some typo database migration issues — up and down, back and forth — i thought i had won the war and my blog seemed to be running smooth again, but i missed out one essential battle it seems…

Ok now this is where things get odd:

While running typo version 4.1.1 via fastcgi on lighttpd all my RSS feeds seemed to work but none of the feedreaders got updated with anything new. Strange right?

I finally did not only look at the content but also on the headers that the server was giving out and noticed that even so the content was all well formatted and up to date the server was giving it out with a 404 response code thus causing all fetchers out there to do an early stop, they just ignored the rest understandably.

Ok now guess what the funniest part is…

The same thing did not happen when i started the mongrel server via ‘script/server’.

This is why you are watching lighty mod_proxy in action here, forwarding all blog queries to the mongrel server.

Web2.0 is simply a nightmare to debug and i don’t have the time for it at the moment, any takers? No? Well, go figure where this will end. ;-)

Hey people,

would you like to pick webradios by ear?

Try out this link on to start with the best c64 remix radio there is.

Beware: SLAYRadio can be highly addictive. ;-)

Well the bad news is i’m about to die first in every episode of StarTrek. ;-)

Your results:
You are An Expendable Character (Redshirt)

An Expendable Character (Redshirt) 75% Jean-Luc Picard 75% Geordi LaForge 65% Spock 64% Deanna Troi 60% Data 53% Leonard McCoy (Bones) 45% Chekov 40% Uhura 40% Worf 35% Will Riker 35% James T. Kirk (Captain) 35% Mr. Scott 30% Beverly Crusher 25% Mr. Sulu 15%

Since your accomplishments are seldom noticed, and you are rarely thought of, you are expendable. That doesn’t mean your job isn’t important but if you were in Star Trek you would be killed off in the first episode you appeared in.

ISC: BIND 9: cryptographically weak query ids. [Added 2007.07.24] CVE: CVE-2007-2926 Versions affected: BIND 9.0 (all versions) BIND 9.1 (all versions) BIND 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.2.5, 9.2.6, 9.2.7, 9.2.8 BIND 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4 BIND 9.4.0, 9.4.1 BIND 9.5.0a1, 9.5.0a2, 9.5.0a3, 9.5.0a4, 9.5.0a5 Severity: Medium Exploitable: Remotely Description: The DNS query id generation is vulnerable to cryptographic analysis which provides a 1 in 8 chance of guessing the next query id for 50% of the query ids. This can be used to perform cache poisoning by an attacker. This bug only affects outgoing queries, generated by BIND 9 to answer questions as a resolver, or when it is looking up data for internal uses, such as when sending NOTIFYs to slave name servers. All users are encouraged to upgrade. Workaround: None. Fix: Upgrade to BIND 9.2.8-P1, BIND 9.3.4-P1, BIND 9.4.1-P1 or BIND 9.5.0a6. Amit Klein from Trusteer (www.trusteer.com) found this vulnerability.

Trusteer:

It is saddening to realize that 10-15 years after the dangers of predictable DNS transaction ID were discovered, still the leading DNS cache server does not incorporate strong transaction ID generation, particularly such one that is based on industrial grade cryptographic algorithms.

Measures to prevent DNS spoofing:

The DNS ID field is 16 bits wide, meaning that if full use is made of all these bits, and if their contents are truly random, it will require on average 32768 attempts to guess. Anecdotal evidence suggests there are implementations utilising only 14 bits, meaning on average 8192 attempts will suffice.

…

Given the above, a resolver MUST:

o Use a new random source port from its available range for each outgoing query

o Make full use of all 16 bits of the ID field

o Assure that its choices of port and ID cannot be predicted by an attacker having knowledge of its (pseudo-)random generator

o Take measures to prevent having multiple equivalent questions outstanding to any authoritative server