Posted by Stefan Schmidt Sun, 04 May 2008 10:24:00 GMT
If the title of this article reminded you of something, yes this is a quote from the song ‘My Favorite Net Things’ from back in the days when the coming of pure ip was still a future thing. You can also get it here for your collection.
I don’t have any explaination of what happened to youtube yesterday but just wanted to show you what it looked to me when i found out about it. Just like this:
Posted by Stefan Schmidt Mon, 14 Apr 2008 12:57:00 GMT
Alright i’m abusing my blog as a bookmarking tool again…
Last week a collegue of mine hit a problem in his java code trying to resolve mailexchange handler (MX) hostnames. He tried to get both A and AAAA records at the same time with the java dns library (JNDI) and found that sometimes he would only get a SOA reply back and that the library was doing ANY queries to accomplish the task with just one DNS query.
This is error! ;-)
Bert Hubert pointed me to this thread on the issue whether a recursive nameserver should recursve for any records upon an ANY query or just answer them from its cache if it has something for the qname.
As Edward Lewis put it:
I’ll nominate section 5.3.3. of rfc 1034:
5.3.3. Algorithm
The top level algorithm has four steps:
1. See if the answer is in local information, and if so return it to the client.…
T_ANY is at best a debugging tool. It has been used in the past to get mail records I think, but really, T_ANY is just for debugging and others trying to abuse the service.
Posted by Stefan Schmidt Tue, 29 Jan 2008 23:50:00 GMT
After contributing my .2รง to this usenet thread i remembered that today i first noticed one of our backbone rings to be split by our DNS graphs.
This is what it looked like:
What happened is that one part of our recursive servers are situated in Duesseldorf while the other part sits in Frankfurt; both sites are reachable via the same Addresses due to use of iBGP anycast so the load gets split by the l3 routing decision. What we can see above is some of the DNS queries getting shifted from Duesseldorf to Frankfurt because at that time Berlin and eastern Germany were ‘nearer’ to Frankfurt than to Duesseldorf network topology wise because of a fibrecut between Berlin and Hannover.
So, nothing serious happened due to the ring structure, some DNS queries got shifted and some milliseconds added - business as usual you could say, nevertheless fun to watch with these graphs.
Posted by Stefan Schmidt Tue, 24 Jul 2007 15:25:00 GMT
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: RemotelyDescription:
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.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.
draft-hubert-dns-anti-spoofing-00.txt:
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
Posted by Stefan Schmidt Mon, 30 Apr 2007 17:01:00 GMT
Its true what some cacti users say here, black graphs do indeed look better than in white. My graphs look all new and better to me now that i switched them to grey on black and added transparency to the lines.
I am using the following global preferences for rrdtool graph:
--imgformat PNG
--interlaced
--slope-mode
--lower-limit 0
--font-render-mode normal
--rigid
--width 801
--height 150
-c CANVAS#000000 -c FONT#aaaaaa -c BACK#000000Ah yes for transparency level just use hex values for: #RRGGBBtt
Posted by Stefan Schmidt Thu, 08 Feb 2007 18:11:00 GMT
Ok what do you think of that?
Doesn’t look like regular traffic, right?
Well that was our gameservers asking for PTR records of their very own temporary service IP addresses. We have no clue yet what gameserver software caused it or why or why there was this dent at 16.00 or why it started at 14.00 as there were no changes to the system(s) today whatsoever.
Well, yeah we have an awful lot of gameservers, which reminds me to once again praise PowerDNS recursor for its absolutely superior performance on this limited query set.
Hail Ahu for this splendid piece of software.
PS: Yeah i’d still love to get some trackbacks, hehe.
Posted by Stefan Schmidt Fri, 12 Jan 2007 21:35:00 GMT
…for a trackback to Berts blog.
…that this RFC draft went on its way.
And yes, DNS antispam/antispoofing is a good thing to care about if you’re running recursive DNS Service for your customers and even if you only run it for yourself. Our everyday commercial email-Spammers apparently did not yet figure out how to achive this but trust me, they will - just as easy as they give our postmasters nightmares quite frequently.
UPDATE: There is also a web1.0 version of this document available. ;)
Posted by Stefan Schmidt Thu, 11 Jan 2007 11:23:00 GMT
Well i guess its safe to say: Roughly every 10-18 Minutes.
Yes this is what happens after a nationwide DSL provider errr ‘resets’. *cough* ;-)
Posted by Stefan Schmidt Mon, 17 Jul 2006 07:51:00 GMT
This is what i wanted to send to the nanog-ML lately but i used the wrong From address and now they’re (hopefully) over with the topic, so i decided to put it here:
On Wed, Jul 12, 2006 at 08:30:32AM +0100, Simon Waters wrote:
> > I'm at a loss to explain why people are
> > trying so hard to condemn something like this.
> Experience?
Let me give you an reallife example of what can happen, which i just
experienced on my Linux workstation:
I put the opendns.com resolvers as first nameservers in my resolv.conf
yesterday to get some opendns webbrowsing experience. It worked, it was
a bit slower than my regular browsing due to the delay europe<->us and
their webserver redirecting invalid addresses to search results, but it
worked.
Off course i forgot to remove their nameservers again yesterday evening.
I am running a local MTA on my workstation that does some additional
spam-filtering through SpamAsassin.
I logged in, strolled through my mailfolders and wondered where all
those mails were that i am used to get every day.
Well, guess what - SpamAsassing also checks for several DNS RBLs by default.
I looked in my spamfolder and found funny things like:
X-Warning: 194.97.50.132 is listed at blackholes.mail-abuse.org
X-Warning: merit.edu is listed at abuse.rfc-ignorant.org
...
1.0 X_WARNING_NJABL_DYNABLOCK listed at dynablock.njabl.org
1.0 X_WARNING_SPAMCOP_BL listed at bl.spamcop.net
...
Example:
dig a 90.7.97.194.dynablock.njabl.org @208.67.222.222
...
;; ANSWER SECTION:
90.7.97.194.dynablock.njabl.org. 1 IN A 208.67.219.40
...
So according to opendns even my workstation is situated in situated in a
dialup block.
Why is that? Well in 'the real world' this query returns NXDOMAIN but
opendns tries to be smart and help you finding out about the site you
wanted to visit by redirecting your browser to their search engines
results for your 'typo'. To do that they return this IN A record to
their webserver so all RBLDNS queries will be true when you use opendns'
recursors.
As a result all incoming mails were regarded as spam and thrown in the
spamfolder - luckily for me it wasn't a busy night.
Stefan
Posted by Stefan Schmidt Sun, 25 Jun 2006 13:50:00 GMT
My brother just noticed that my tub nearly ran over. I was busy playing around with PowerDNS recursor and hearing a (loud) webradio stream for distraction.
And hell just now as i’m writing this article that bloody NIC/driver in my workstation (running windows xp at the moment) decided to give itself a break just as they were starting to play a song that i like… grrr
Older posts: 1 2
