bert hubert finally blogs comments

"PowerDNS 2.9.22 released, RFC 5452 assigned!" by Lennie

Sun, 08 Feb 2009 16:32:12 +0100

sorry, that was a typo, it's: www.EDNS-ping.org

"PowerDNS 2.9.22 released, RFC 5452 assigned!" by Lennie

Sun, 08 Feb 2009 16:27:57 +0100

And he keeps on going with www.ENDS-ping.org as the next draft he's working on

"PowerDNS 2.9.22 released, RFC 5452 assigned!" by Sean Leach

Wed, 28 Jan 2009 03:32:38 +0100

Congrats Bert!

"The ultimate SO_LINGER page, or: why is my tcp not reliable" by Eelco

Sat, 24 Jan 2009 15:34:26 +0100

I'm no expert at all, but "The best advice is to send length information, and to have the remote program actively acknowledge that all data was received." will this not create the possibility of malicious 'socket attacks' in which the server get overflown with length faulty requests?

"The ultimate SO_LINGER page, or: why is my tcp not reliable" by NG

Fri, 23 Jan 2009 14:34:39 +0100

wow, you just discovered why TCP is not on top of the IP network stack... gratz! :)

"The ultimate SO_LINGER page, or: why is my tcp not reliable" by piotr

Wed, 21 Jan 2009 17:31:08 +0100

Very interesting article, although this is not so surprising if you have carefully read W. Richard Stevens' UNIX Network Programming. I didn't know about SIOCOUTQ though. In my distributed search engine project I used O_NONBLOCK with epoll and length information in my protocol. I don't use shutdown, since I find reading 0, 0 or reading the required lengths of the messages is sufficient. All my IO is asyncrhonous and first I read a predefined size with the minimum record size which has lenght information about record's data, then to read data: // async read handler res = read (m_fd, readptr, readleft); if (res 0) { if (errno != EAGAIN) { on_error (); return; } else { return; } } else if (res == 0) { on_eof (); return; } else { readptr += res; readleft -= res; stats_read_cnt +=res; } if (readleft == 0) { // process data ... } And of course, these records should be acknowledged (and checksummed even) if you want the sender to be sure they were recieved. In the end programming asyncrhonously is very tricky and takes a lot of effort, but when got right it's very effective and easier to debug than threadhell.

"Calculating the chance of spoofing an agile source port randomised resolver" by Lennie

Sun, 17 Aug 2008 15:46:13 +0200

Getting them to apply patches is hard ? I still see a lot of queries on our authoritive servers with a source-port of 53. Even a large dutch access-provider.

"Some thoughts on the recent DNS vulnerability" by SIGLAZY

Thu, 17 Jul 2008 09:13:56 +0200

About DNSSEC, oh well, this is another "good solution to the wrong problem". (DNSSEC uses DNS protocol to propagate keys through DNS caches && DNS caches are vulnerables to cache poisoning = DNS keys may be forged ...) and If DJB was not listened at _on this specific point_ it is not only because he has a big social interface problem but also because IETF DNS-EXT WG people were... how to say? deaf or stupid.

"Some thoughts on the recent DNS vulnerability" by grin

Thu, 10 Jul 2008 13:45:20 +0200

But it should be noted that djb is a real PITA, so if there's something he try to push it's very probable that people try to avoid it. And him. Don't get me wrong: this is all about behaviour and not about his programming abilities at all.

About DNSSEC, oh well, would be nice to have seen it finalised and implemented.

"Some thoughts on the recent DNS vulnerability" by bert hubert

Thu, 10 Jul 2008 13:15:09 +0200

Roy - many of the points you raise are valid. But if people would have implemented this years ago, we would be having a totally different discussion right now. And I sincerely hope that this vulnerability opens people's eyes and that we can fix DNS to be secure enough.