DelphinusDNS Blog

(the latest about delphinusdnsd)
  

Previous Page


Applying for funding (with your help?)

July 18th, 2020

Dear Delphinusdns blog reader,

If you haven't heard of the prototypefund.de it's a fund in Germany that supports open source. They pay up to 47K EUR to teams.

I am applying to the 9th round (between January and July, 2021) of this prototype fund, on August 1st, for the work of "DNS Updates" in delphinusdnsd. I did apply to the 5th round (2018) before also for delphinusdnsd improvements, but did not secure the grant. I was turned down in November of 2018, and similarily this year I'll find out in November likely if I'll be selected.

This will pretty much be for the entirety of the 1.6.0 release which will be sped up to be done by July, 2021.

So here's my reaching out. If you're german and living in Germany, know how to code in C, and want to help me with this for the work of DNS Updates (with DNSSEC signing) send me an email before August 1st. I'll apply with your name as a team member. Mind the dates I listed above (August 1st, November, January-July 2021) and commit to them. If it doesn't get through November there is no money, and no team. But if we do get selected in November, I need you to commit 6 hours per weekday between January-July 2021.

I think it would be fun! And don't worry, if you do get selected I won't expect you to work on this at the pace that I'm working. In fact I'll give you a related small work first to get to know the delphinusdnsd, before asking you to do heavy lifting. As long as we get the work done by June/July. Let me know if you qualify with an email.

0 comments

Forwarding is done, what's next?

July 17th, 2020

I allocated the entire month of July for the forwarding work but it seems to be nearing completion. I got stalled on porting it to NetBSD and that will take a few weeks more, so I'm thinking I'll use the momentum I got the first half of this month to implement CAA RR's in the authoritative mode.

This is a lot of work these days because the delphinusdnsd ecosystem has spread over dddctl programs and needs to be checked in several places. I have the entire workweek next week to work on that. It will make a fine addition to the 1.5.0 release. I can't guarantee that I will do much work between August and the release time, I have a lot of job applications to do, as I'm below zero so to speak. But coding on delphinusdnsd keeps my spirits high. I have been applying to companies in the last few weeks but only sparingly.

On with it!

1 comment

Didn't make it in the Arctic code vault

July 17th, 2020

Here is a story about the arctic code vault (the story is in german) where programs are safe for 1000 years. The github snapshot was made in February 2020 so before I joined GITHUB. I guess delphinusdnsd will be living on the edge without repos in ice to fall back on.

0 comments

A DNS Question Name, or, What is 0xC00C?

July 16th, 2020

I have just replaced the foundation in delphinusdnsd. In fact I have replaced 15 year old code (code that was there at initial checkin at wildcarddnsd) and replaced it with a function called expand_compression(). I programmed expand_compression() a few years back where I made sure that nothing could exploit it. In fact something could have and I have improved on it today. But let me start with a function written in 2005 build_question() and here is a snippet of the first executable code:

 /* find the end of name */
 for (i = sizeof(struct dns_header); i < len; i++) {
  if (buf[i] == NULL) {
   end_name = &buf[i];   
   break;
  }
 }
What was there still this morning was similar to this. Obviously it was bogus. The struct dns_header looks something like this:
/* RFC 1035 - page 26 */

struct dns_header {
        u_int16_t       id;                     /* ID of header */
        u_int16_t query;
        u_int16_t question;                     /* # of question entries */
        u_int16_t answer;                       /* # of answer RR's */
        u_int16_t nsrr;                         /* # of NS RR's */
        u_int16_t additional;                   /* # additional RR's */
};
So when a question came in it would skip the header, to parse the first DNS name (the question name), and it knows that the name is terminated with a 0-byte so it said: go to this zero byte and that's the length of the question name. Of course it was bogus. Someone can insert 0's into the labels contents and this would bomb. So I downright replaced this with expand_compression() which also tries to expand compression, but it can only go to compression offsets looking to the beginning of the packet otherwise it would open an infinite compression loop opportunity.
/*
 * parse a domain name through a compression scheme and stay inside the bounds
 * returns NULL on error and pointer to the next object;
 */

char *
expand_compression(u_char *p, u_char *estart, u_char *end, u_char *expand, int *
elen, int max)
{
...
This function stays within the bounds of the packet thus it has a estart, and and end which indicates start and end of the packet. It has an extra buffer called expand which is like a digest pad where the compressed name is uncompressed to. And p is the offset where it's parsing from. So going into the first parsing of the packet the DNS Header is parsed, (or allocated), then it sits at offset 0x0C or decimal 12 which is the size of the DNS Header. You guessed it that 0x0C which is part of 0xC00C. Many answers use that compression offset because it saves on writing out the dns name that was in the question (and was requested).

Before today expand_compression() was faulty because it would take on any ID value that can be crafted to be 0xC000 or at offset 0 of the packet which is the ID. From there one can control up to 63 bytes offset, but one cannot go compressing forwards due to restriction of the algorithm for that. So I just put a stop in for that, that the dns header is off limits for compression. This stops compressing in the 0x0C offset completely. Good for the first dns question.

All in all I'm very happy I took a look today what build_question() did. It will pay itself off, with better security, I think (and hope).

1 comment

HEADS UP: delphinusdnsd-current rolls config version

July 15th, 2020

If you know delphinusdnsd config files you may have run into the 'version "9";' at the top of the config file. It's required.

I have just rolled back the version 9 to version 1, meaning after today (or on tomorrows snapshot forward) it will be at version 1. All examples and manpages have been updated.

When I forked delphinusdnsd from wildcarddnsd (which I also wrote), the first version was version 7. So there won't be a conflict until version 2.1.0 in 7 years. By that time I don't think anyone will have delphinusdnsd-1.0.0's running, it has too many bugs. Also it will be a major release bump then and we'll see how the versions can be done. The version "1"; will likely stay until the release of 1.6.0 in 2021, unless you track the snapshots/-current at which point it will be sooner.

The idea of versioning in the configfiles is that it creates administrative overhead to make sure that a config is backwards compatible if you go back in versions. I think this is a good thing, and I first saw it I think in syslog-ng config files.

0 comments

Tomorrows snapshot may support Linux again

July 14th, 2020

Yesterday I did porting work of -current to Linux. It didn't make todays snapshot but it should make tomorrows. In the following days/weeks I'm also going to make sure FreeBSD and NetBSD work. OpenBSD is my developing platform and it works there.

0 comments

We may see an early release for 1.5.0

July 12th, 2020

Due to the Dynamic DNS work that I have planned for 1.6.0 I'm considering committing the 1.5.0 release a few months early. Perhaps just after the OpenBSD 6.8 release which will come out between october and november some time. This way I give myself a bit more time for 1.6.0. I kinda dislike floating releases and prefer set dates but this is sorta a special event. I'll keep pondering around this and you may see a november release.

0 comments

Updated chart of delphinusdnsd processes

July 12th, 2020

0 comments

Delphinusdnsd surpassed 40K lines

July 10th, 2020

In delphinusdnsd -current..

40146 total
This number will go up and down, but wow, what a bloat. I'm currently enjoying the last incarnation of the forwarding code. I finally fixed it I hope (in the cache). The work is committed tomorrows snapshot may be stable for enabling the cache. It is activated in the forward "" {} with a "cache yes;" line. Off I go, see you later.

0 comments

Delphinusdnsd 1.4.2 Released (minor fix)

July 9th, 2020

Even though the 1.4.2 tarball doesn't update the internal version string to 1.4.2 (I forgot this rolling it this morning), it does feature a slight DNS header query flags fix to REFUSED answers. This bug was found 6 days ago, so I finally was able to backport it. So, only 1 source file is different from 1.4.1 featuring a 3 line diff.

0 comments

Next Page

Search

RSS Feed

Click here for RSS

On this day in

Other links

Have feedback?

By clicking on the header of an article you will be served a cookie. If you do not agree to this do not click on the header. Thanks!

Using a text-based webbrowser?

... such as lynx? Welcome back it's working again for the time being.

Older Blog Entries


Powered by BCHS