OK, I have been using the August 21st snapshot of Deadwood without problem for the last week, so it looks pretty stable. That in mind, I have just released Deadwood 2.02. This is a stable release of Deadwood.
Everything words: Resurrections, writing cache to disk, reading cache from disk, compiling and running under Windows without Cygwin (without all of the features, alas), etc.
The "Google problem" isn't fixed, but that will wait for the post-2.02 snapshots (see older Deadwood entries for a description of this problem).
I will make Deadwood 2.02 the version of Deadwood included in the next 1.3 snapshot of MaraDNS.
It can be downloaded at www.maradns.org/deadwood
- Sam
Thursday, August 28, 2008
Monday, August 25, 2008
New ObHack snapshot
Saturday night, I had a case of insomnia, so ended up working a little on ObHack. My goal is to make a 004a release around the new month. The only changes I have made since April's snapshots is to integrate some of the upstream Oblige 0.97 changes in to ObHack. In today's release, I have integrated some of the code to allow Doom levels to have the occasional Boss monster be in levels.
It is available at www.samiam.org/slump
Sunday, I ended up hanging out with my neighbor again. At first, she was too busy too see me. So I bribed her by paying for her groceries when we went to the corner store together. She then magically made time for me to visit her; we had mole verde and watched TV together.
It is available at www.samiam.org/slump
Sunday, I ended up hanging out with my neighbor again. At first, she was too busy too see me. So I bribed her by paying for her groceries when we went to the corner store together. She then magically made time for me to visit her; we had mole verde and watched TV together.
Thursday, August 21, 2008
Deadwood update
I have updated Deadwood today to not only check the ID (and port number) [1] for incoming queries, but also to make sure the query is the same (the answer the remote server sends us should match the question we gave them).
It can be downloaded at www.maradns.org/deadwood.
- Sam
[1] The way Deadwood verifies the port is the somewhat hackey way of "connecting" with a UDP socket in the function make_remote_connection(). Once this is done, the only UDP query allowed to reply to the UDP packet we send is one from the same IP and port number.
It can be downloaded at www.maradns.org/deadwood.
- Sam
[1] The way Deadwood verifies the port is the somewhat hackey way of "connecting" with a UDP socket in the function make_remote_connection(). Once this is done, the only UDP query allowed to reply to the UDP packet we send is one from the same IP and port number.
Wednesday, August 20, 2008
Solving the Google problem
It looks like Deadwood is working pretty well; I plan on releasing a stable version of Deadwood before working on some issues in the wishlist.
One issue is that I need to check the code that validates a reply from the remote server. Right now the query ID and port number are validated; I need to make sure the code always validates the name requested also. This code will be put in get_remote_udp_packet() in DwUdpSocket.c.
I will need to reorganize this function a little; we will get the query from the question section of the reply and make sure it's the same before checking for truncation or what not.
I would like to thank "neeo" for pointing out this issue.
Once I do all that, I want to work on the "Google problem". To make the code as simple as possible, I will code things thusly:
One issue is that I need to check the code that validates a reply from the remote server. Right now the query ID and port number are validated; I need to make sure the code always validates the name requested also. This code will be put in get_remote_udp_packet() in DwUdpSocket.c.
I will need to reorganize this function a little; we will get the query from the question section of the reply and make sure it's the same before checking for truncation or what not.
I would like to thank "neeo" for pointing out this issue.
Once I do all that, I want to work on the "Google problem". To make the code as simple as possible, I will code things thusly:
- I will only look past the first reply if it's a CNAME reply and if there is more than one answer in the answer section.
- As long as the DNS reply is a CNAME, and there are still answers in the answer section, we go until the first non-CNAME packet, or when we run out of answers in the answer section.
- We keep a record of the lowest TTL we've seen in a packet. This is the TTL we will use to store the record
Monday, August 18, 2008
Deadwood update; ObHack minor update
On Friday, I silently updated the MaraDNS web page to point to the latest releases of MaraDNS which I uploaded two weeks ago. I haven't uploaded the latest release to Sourceforge, but will probably do so this week sometime.
On Saturday, I drove my neighbor to work. I then did some errands, and picked her up after work. She made me some "Russian salad" and we spent the afternoon eating and talking.
On Sunday, my neighbor was busy so I ended up having some time to geek out. I ended up updating Deadwood to remove a couple of Cygwin-only compile-time warnings, and getting "resurrections" to work when Deadwood is unable to connect to the upstream DNS server.
"resurrections" is the ability to pull expired records from the DNS cache when there is no other way to get a DNS record. Basically, it's a DNS record of last resort. If, for whatever reason, it's impossible to get a current DNS record, it's probably better to give the user a possibly outdated DNS record than no record at all. This is called "resurrections" in Deadwood. And yes, if you feel this someone violates the DNS spec or whatever, it can be disabled.
Anyway, resurrections now work either when there's a timeout trying to connect to an upstream DNS provider, or if it's impossible to send a packet upstream. Each case uses different code; I may also eventually add code to use resurrections in the case of being able to connect to the upstream DNS provider, but upstream gives Deadwood a DNS error instead of the reply (the code may actually already do this; I will have to check).
I also have the version number of Deadwood appear when it's started.
In addition, I have made a minor update to ObHack. This backports Andrew's bugfix for monsters or items on crates. The fix doesn't seem to be perfect, but does seem to reduce the number of times monsters or items are inaccessible because they're on top of a crate.
This will probably be my last update to ObHack for a while; to be honest, I currently don't enjoy playing first person shooters so have little motivation to work on this code. I may end up releasing ObHack 004a and declaring it stable. We'll see.
On Saturday, I drove my neighbor to work. I then did some errands, and picked her up after work. She made me some "Russian salad" and we spent the afternoon eating and talking.
On Sunday, my neighbor was busy so I ended up having some time to geek out. I ended up updating Deadwood to remove a couple of Cygwin-only compile-time warnings, and getting "resurrections" to work when Deadwood is unable to connect to the upstream DNS server.
"resurrections" is the ability to pull expired records from the DNS cache when there is no other way to get a DNS record. Basically, it's a DNS record of last resort. If, for whatever reason, it's impossible to get a current DNS record, it's probably better to give the user a possibly outdated DNS record than no record at all. This is called "resurrections" in Deadwood. And yes, if you feel this someone violates the DNS spec or whatever, it can be disabled.
Anyway, resurrections now work either when there's a timeout trying to connect to an upstream DNS provider, or if it's impossible to send a packet upstream. Each case uses different code; I may also eventually add code to use resurrections in the case of being able to connect to the upstream DNS provider, but upstream gives Deadwood a DNS error instead of the reply (the code may actually already do this; I will have to check).
I also have the version number of Deadwood appear when it's started.
In addition, I have made a minor update to ObHack. This backports Andrew's bugfix for monsters or items on crates. The fix doesn't seem to be perfect, but does seem to reduce the number of times monsters or items are inaccessible because they're on top of a crate.
This will probably be my last update to ObHack for a while; to be honest, I currently don't enjoy playing first person shooters so have little motivation to work on this code. I may end up releasing ObHack 004a and declaring it stable. We'll see.
Wednesday, August 13, 2008
MaraDNS support rant
I just had to refuse yet another ask for MaraDNS support sent as a comment here. As a reminder, MaraDNS support requests sent to the blog will not be published.
Also, I finally went to my PayPal account, and, lo and behold, it has a balance of zero. I once, back when I was doing email support, had someone claim they sent me a PayPal donation, and request support, when, in fact, no such donation was ever sent to me.
The only place for MaraDNS support is on the MaraDNS mailing list, unless you have an undiscovered security bug to report.
On more cheerful news, I have gotten a couple of very positive pieces of fan mail sent to me. Fan mail is greatly appreciated, and I apologize for not having a chance to send people sending me positive emails a personalized reply thanking them for their kind words and their support.
Update: OK, I got some small donations from various sources. It would seem Paypal won't let me use these donations until they confirm me. So I'll see if I have a check for my checking account at home I can use for the confirmation (they wouldn't let me confirm by getting their credit card). As it turns out I never got older donations and they were returned to the donor.
Thank you everyone for your donations. I will work on getting my account confirmed in the next day or two.
Also, I finally went to my PayPal account, and, lo and behold, it has a balance of zero. I once, back when I was doing email support, had someone claim they sent me a PayPal donation, and request support, when, in fact, no such donation was ever sent to me.
The only place for MaraDNS support is on the MaraDNS mailing list, unless you have an undiscovered security bug to report.
On more cheerful news, I have gotten a couple of very positive pieces of fan mail sent to me. Fan mail is greatly appreciated, and I apologize for not having a chance to send people sending me positive emails a personalized reply thanking them for their kind words and their support.
Update: OK, I got some small donations from various sources. It would seem Paypal won't let me use these donations until they confirm me. So I'll see if I have a check for my checking account at home I can use for the confirmation (they wouldn't let me confirm by getting their credit card). As it turns out I never got older donations and they were returned to the donor.
Thank you everyone for your donations. I will work on getting my account confirmed in the next day or two.
Tuesday, August 12, 2008
Deadwood minor update
OK, last Friday I had big plans for updating Deadwood.
That didn't happen.
I actually finished another personal project on Saturday. On Sunday, I spent all afternoon with my neighbor, who fed me some really yummy tostadas with beans and cheese that she made. We watched Enemy of the State dubbed in to Spanish (she never saw it before; I never saw it in Spanish) and I showed her how to shuffle a deck and how to play the card game Gin Rummy.
So much for Deadwood getting updated this weekend.
However, Neeo contributed two minor patches; one that speeds things up a little bit, and another that makes sure 0-TTL entires are not cached.
Check it out at www.maradns.org/deadwood.
I will also bump up both stable releases of MaraDNS later on this week with a bugfix; until I make the release official, people can check out the 1.2 stable update and the 1.3 stable update.
That didn't happen.
I actually finished another personal project on Saturday. On Sunday, I spent all afternoon with my neighbor, who fed me some really yummy tostadas with beans and cheese that she made. We watched Enemy of the State dubbed in to Spanish (she never saw it before; I never saw it in Spanish) and I showed her how to shuffle a deck and how to play the card game Gin Rummy.
So much for Deadwood getting updated this weekend.
However, Neeo contributed two minor patches; one that speeds things up a little bit, and another that makes sure 0-TTL entires are not cached.
Check it out at www.maradns.org/deadwood.
I will also bump up both stable releases of MaraDNS later on this week with a bugfix; until I make the release official, people can check out the 1.2 stable update and the 1.3 stable update.
Friday, August 8, 2008
Mini Deadwood roadmap
OK, I've fixed the one real bug with real-world consequences I can see with Deadwood. I have added some error correction so that, should the upstream server give us a malformed DNS packet, the packet is discarded and not cached.
I also have code so that, should a zero-length packet (a packet caused by a malformed DNS packet) be in the cache, the offending packet is deleted, and Deadwood tries to get a legitimate packet from the upstream DNS provider.
So now, I have to work on some of the other bugs in Deadwood. The next thing I want to fix is the problem with "resurrections" (using an expired record from the cache should it be impossible to contact the upstream DNS provider) which are not working.
After that, I want to look at the "Google problem" (described in the docs).
In the meantime, Deadwood is a perfectly usable DNS caching server.
I also have code so that, should a zero-length packet (a packet caused by a malformed DNS packet) be in the cache, the offending packet is deleted, and Deadwood tries to get a legitimate packet from the upstream DNS provider.
So now, I have to work on some of the other bugs in Deadwood. The next thing I want to fix is the problem with "resurrections" (using an expired record from the cache should it be impossible to contact the upstream DNS provider) which are not working.
After that, I want to look at the "Google problem" (described in the docs).
In the meantime, Deadwood is a perfectly usable DNS caching server.
Thursday, August 7, 2008
Linux (OK, Ubuntu) sucks: Updates
Linux's update handling was obviously designed by a bunch of kids in their mommy's basement who spend all day on the internet, and whose mommy pays for them to have a high-speed broadband connection.
Down here in Mexico, I don't have an ultra-fast broadband connection. I don't have internet at home either. I'm just a recovering Linux fanboy trying to develop a life beyond sitting around on Slashdot and Digg all day flaming anyone who doesn't think Linux is God's gift to earth.
So, this morning, I booted in the Ubuntu that I installed last weekend (I had some time to kill before dating a girl Saturday evening). Got on the network, then started seeing if I could download the updates to bring my system up to date.
Well, except the connection here at work was seriously lagging (it does that sometimes). The DNS broke down about halfway through the painfully slow process of seeing what packages were available to be updated.
Does the update manager bother to cache the IPs of the site it connected to to get updates? Nope. Is there a usable DNS server on the localhost port in the default install of Ubuntu? Nope. Does Ubuntu come with a usable compiler and development environment so I can compile my own DNS server on the localhost port? Nope, you have to apt-get it.
apt-get is another usability nightmare. You would think apt is smart enough to figure that anyone who wants a C compiler also wants to, you know, compile programs that run. But, no. Once you get gcc, you also have to hunt down and get the "libc-dev" package to compile anything.
So, anyway, this process of looking for updates failed halfway through. I had a list of packages to update, but I have no idea if some critical security update was missed. I had better things to do with my time than to restart the "look at the big huge package lists to see what updates I need" process.
So I booted back in to Windows.
Let's compare this to Microsoft. With Microsoft, the update process is one that is perfectly usable, even on a dialup connection. It will run the updates in the background, with a low priority given to the packets uses for downloading updates. This required something Linux isn't very good at: Coordination with the people responsible for making sure the operating system is up to date and the people who implement the TCP stack is as simple as getting a few people together in a meeting room somewhere in Redmond and talk about the need to have it so downloading updates can be done on a slow connection that is often offline without affecting the user's internet experience.
The update process is one where, if something fails, like DNS dying halfway through the process, the task is stopped where the failure happened, and can be painlessly started again without needing to go back to square one. It's one where downloads can be interrupted and resumed again at any time.
The closest Linux gets is with CentOS, where I can just go here and download the updates by hand. Should the download be interrupted, I only have to re-download one package instead of the whole spiel. Once I download the updates, I then have to, by hand, see which RPM files I have on my system and update them. OK, I can kinda-sorta automate this with something like for a in *rpm ; do if rpm -qa | grep $( echo $a | awk -F- '{print $1}' ) ; then rpm --upgrade --nodeps $a ; fi ; done but that's a little unreliable and buggy.
But even that doesn't hold a candle to Microsoft's update process. Don't get me started on the distributions where the distribution maker one day lost interest in keeping the distribution up to date, making it so the distribution has no security updates whatsoever.
Down here in Mexico, I don't have an ultra-fast broadband connection. I don't have internet at home either. I'm just a recovering Linux fanboy trying to develop a life beyond sitting around on Slashdot and Digg all day flaming anyone who doesn't think Linux is God's gift to earth.
So, this morning, I booted in the Ubuntu that I installed last weekend (I had some time to kill before dating a girl Saturday evening). Got on the network, then started seeing if I could download the updates to bring my system up to date.
Well, except the connection here at work was seriously lagging (it does that sometimes). The DNS broke down about halfway through the painfully slow process of seeing what packages were available to be updated.
Does the update manager bother to cache the IPs of the site it connected to to get updates? Nope. Is there a usable DNS server on the localhost port in the default install of Ubuntu? Nope. Does Ubuntu come with a usable compiler and development environment so I can compile my own DNS server on the localhost port? Nope, you have to apt-get it.
apt-get is another usability nightmare. You would think apt is smart enough to figure that anyone who wants a C compiler also wants to, you know, compile programs that run. But, no. Once you get gcc, you also have to hunt down and get the "libc-dev" package to compile anything.
So, anyway, this process of looking for updates failed halfway through. I had a list of packages to update, but I have no idea if some critical security update was missed. I had better things to do with my time than to restart the "look at the big huge package lists to see what updates I need" process.
So I booted back in to Windows.
Let's compare this to Microsoft. With Microsoft, the update process is one that is perfectly usable, even on a dialup connection. It will run the updates in the background, with a low priority given to the packets uses for downloading updates. This required something Linux isn't very good at: Coordination with the people responsible for making sure the operating system is up to date and the people who implement the TCP stack is as simple as getting a few people together in a meeting room somewhere in Redmond and talk about the need to have it so downloading updates can be done on a slow connection that is often offline without affecting the user's internet experience.
The update process is one where, if something fails, like DNS dying halfway through the process, the task is stopped where the failure happened, and can be painlessly started again without needing to go back to square one. It's one where downloads can be interrupted and resumed again at any time.
The closest Linux gets is with CentOS, where I can just go here and download the updates by hand. Should the download be interrupted, I only have to re-download one package instead of the whole spiel. Once I download the updates, I then have to, by hand, see which RPM files I have on my system and update them. OK, I can kinda-sorta automate this with something like for a in *rpm ; do if rpm -qa | grep $( echo $a | awk -F- '{print $1}' ) ; then rpm --upgrade --nodeps $a ; fi ; done but that's a little unreliable and buggy.
But even that doesn't hold a candle to Microsoft's update process. Don't get me started on the distributions where the distribution maker one day lost interest in keeping the distribution up to date, making it so the distribution has no security updates whatsoever.
Wednesday, August 6, 2008
Deadwood update
First of all, I'm changing the numbering of Deadwood releases. Instead of giving releases numbers, I'm giving them dates. Today's release, deadwood-Q-20080806 (Deadwood snapshot for August 6, 2008) tries to fix the problem with empty packets by having these empty packets detected before they're added to the cache.
This way, the packets shouldn't ever been seen by the resolver using Deadwood.
It can be looked at on the webpage www.maradns.org/deadwood.
- Sam
This way, the packets shouldn't ever been seen by the resolver using Deadwood.
It can be looked at on the webpage www.maradns.org/deadwood.
- Sam
Tuesday, August 5, 2008
New MaraDNS support policy
I have a new MaraDNS support policy: The only place where I support MaraDNS is on the MaraDNS mailing list. Details on how to subscribe to the mailing list are on the MaraDNS web page.
All MaraDNS blog comments are moderated, and any blog comments with MaraDNS support requests will not be published.
All MaraDNS blog comments are moderated, and any blog comments with MaraDNS support requests will not be published.
Subscribe to:
Posts (Atom)
