ODNS and ring

So here they are, the brand new ODNS library and the ring tool. Below are the main changes.

ODNS release notes

Resolver class name changing

This is not a nice change to change the API, but I should have done it before. The main class of the library was named “query” and its main method (the one actually making the query) was “action“. That was actually historic naming before me, and though I often thought about updating it, I always left it unchanged. But when you think, that’s a strange naming. The “query” class is actually a resolver, so I called it… “resolver” (tadada!). And the “action” method is actually when one makes the actual query, so it becomes… (suspense?!) “query“.
That’s more logical naming and looking also much more like other DNS libraries (this second point is a minor reason though: I may name things differently if there is a good reason. Here I don’t see any). Hopefully there should not be big naming change like this too often, but I allowed myself to do this one as this is still an early 0.2. Obviously when I’ll arrive to a 1.x naming, API will be fully stable.

Runtime Cache

The library now caches, and uses in subsequent calls, the resource records through a complex algorithm taking the Time To Live values of records, and doing other processing (for instance a SOA record cannot have a TTL higher than 0, etc.). As I lock the cache, this feature is thread-safe (you can query names in separate threads in the same time. They will both share the same cache without any problem).
Notes:

1. this is only a “runtime” cache for now. Which means 2 programs running in the same time won’t share the cache. Moreover the same program stopping will restart with a fresh cache. I plan to make a cache saving and sharing across the system in the next version.
2. Caching and getting result from cache is the default behavior. If you want to bypass the cache system (which means not storing, nor checking for recent records which answers your query), this is possible to configure the resolver class this way with the resolver#set_nocache method.

Using resolvers as resolver templates

You may have a program where you need to do a lot of resolving and the default resolver configuration does not suit you. So there was one solution which was that you were re-setting all the configuration option each time you create a resolver. Now I created the function Dns#resolver_from_model whose basic use is to create a new resolver with the same configuration as another. This allows you to create a resolver that you keep on the global scope of your program for instance, then you create all other needed resolver from this “template”. Later if I create new configuration options in further version of the library and you want to set this option differently as well, you will have just one place in your program to update: the template. All other resolvers will be updated accordingly.
The helpers also uses now the same kind of template system thanks to an optional parameter ~configuration making now the helper functions to be as powerful and customizable as the main resolver, with all the additional calculations.

Helpers now are multi-threaded.

Previously the helpers were making all queries one after another. So if you imagined a srv_lookup call on a domain, which returns 10 records and you want the IPv4 addresses and IPv6 addresses of all 10 of them (if they are not provided in the additional section by the name server, which is the recommended logics but is not done by all servers, and if we don’t have the information in cache already), we were making 20 queries on a row. Now with threading I can make the 20 queries at the same time.

Annoying Makefile bug fixed

I noticed that I had an installation bug. Only the DNS module of the library was accessible. I fixed this. Now all 4 public modules are accessible: Dns (main module, low level functions and high level resolver), Iana (utility module to get IANA’s number information), Dnsprint (utility module to pretty-print DNS stuffs. It needs to be improved and I don’t advice to use it yet), Dns_helper (very high level DNS function, the most interesting module if there is already the function you need there!).

New Resolver configuration Options

• The nameservers can now be checked and set with object’s methods. Moreover they are not anymore an optional parameter settable during resolver initialization because thinking this back, there is no reason to treat this configuration differently form others (and I used the fact I was already breaking everything by changing the name of the class as an excuse, but obviously this kind of thing also should not happen anymore if I can avoid it). This also allowed me to remove the unit parameter on the constructor which is necessary when there are only optional parameters.
• The resolver can be set recursive (default) or not. This is not a local recursivity algorithm. It only sets our desire for the query to be recursive (depending on the name server’s will to accept this or not).
• You can set the resolver as “verbose” (default is disabled) to output into some channel (standard output, a file, whatever) resolution steps. This output can be set ANSI capable (default: not) if the output is for instance a terminal (to have nicer display).

Failure Cases Handling

Cases of failures are now much better handled with documented exceptions in the API, so that robust programs can be built above ODNS.

Various Bug Fixes

As always!

ring release notes

Verbose option with pretty color output

The color output can be disabled (-T), still keeping the verbosity (-v), if for instance you wanted to redirect the output to a file.

Recursion can be disabled

If you don’t want to set recursion

Retries and timeout option can now be set

Better handling of error cases.

Hi all,

I have created a small mailing list for the project. This is NOT a discussion list. I don’t think such a project needs a discussion list (we can discuss bugs and features by making reports and requests in the bug tracker). This is only a “diffusion” list: to announce important stuffs, like releases. In other words, I am the only one able to publish on the list.

It means you won’t receive any spams from this list and also that this is a very low volume list (very few messages) but that’s good to keep informed of the project’s development, because obviously you are not going to come on this website all the time (for RSS addicts, RSS is a good tool for keeping updated too).

To subscribe:

1. Send an email to odns-announce-request@lists.tuxfamily.org with subject “subscribe” from the email you want to subscribe.
2. You will receive an email which you will have to respond to, in order to confirm the subscription request.

To unsubscribe:

1. Send an email to odns-announce-request@lists.tuxfamily.org with subject “unsubscribe” from the email you are subscribed with.
2. You will receive an email which you will have to respond to, in order to confirm the unsubscription request.

See you all and have fun!

Finally the first official release of ODNS and ring is here!

Get a look at the API documentation, the tutorial for ODNS (not finished), the documentation of the associated DNS lookup tool, ring, or simply download this new release.

If you find any bug on either the API or “ring”, don’t hesitate to fill a bug report.

I don’t know if any release note is really necessary as this is the first real release anyway, so everything should be new to anyone. The best would then be to watch at the associated documentations I linked before, and then get your own idea of what you can do with this API library or this DNS lookup tool.

And thank you to the original authors (Guillaume Valadon and Emmanuel Letellier), thanks to whom I have been able to begin working on this library on good bases.

Enjoy!

Yeah so now there is a bug tracker included in my WordPress instance (basically the software which makes this website). I first tried to install a full-featured bug tracker and project management tool (Trac) but it was a pain in the ass to install (though the software itself is pretty nice for the time I had to use it as a simple user). I mean in particular, it was not easy and I didn’t want to spend hours.

So I found this nice WordPress plugin called “bug library“. Obviously it is missing a lot of features compared to bug tracker projects on their own; but for the few minutes I have played with, it still looks nice and probably sufficient for this project (though for my bigger projects, I may probably use more complete trackers).
So I’ll keep this for now unless I see big problems with it in the future.

Soon will be the first official release, keep updated!