[Pdns-users] PowerDNS needs your thoughts on two important DNSSEC matters

[Peter van Dijk]

Hello,

we are working hard to get 3.1.1 out the door, fixing the last remaining DNSSEC issues. Since 3.1, we have discovered two issues that require some re-engineering and may have database impact. We could really use some input on these issues.


ISSUE 1: ordername sorting

As you may know, when using NSEC (not NSEC3), PowerDNS converts records.name to records.ordername, reversing the order of labels in the process (i.e. 'a.b.c.example.com' becomes 'c b a'). This is done so that the database can find previous/next names for us quickly and easily, using an index.

However, it turns out that not all databases, in their default settings, sort the underscore correctly:

Correct order, as demonstrated by ASCII values (Python):
>>> l=sorted(list('_abc*'))
>>> l
['*', '_', 'a', 'b', 'c']
>>> map(ord,l)
[42, 95, 97, 98, 99]
>>> sorted(['test sub', 'test www' ,'_underscore','very-long-txt'])
['_underscore', 'test sub', 'test www', 'very-long-txt']


What Postgres tends to do with default settings:
 test sub
 test www
 _underscore
 very-long-txt

Settings from psql -l:
   Name    |  Owner   | Encoding |  Collation  |    Ctype    |   Access privileges   
-----------+----------+----------+-------------+-------------+-----------------------
 pdnstest  | vagrant  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 


Passing '-l C' to createdb fixes this, but that would involve a dump/restore. I also understand that with Postgres 9.1, there are ways to alter the column's collation settings without a full dump/restore, but many users are not running 9.1 yet. I have not managed to find a suitable way to emulate the VARBINARY trick (below) that works for MySQL, in Postgres.

MySQL, depending on charset settings (cannot reproduce right now), will also not do the right thing for us. However, for MySQL there are a few reliable workarounds:
ALTER TABLE records ADD order name      VARCHAR(255) COLLATE latin1_bin;
or
ALTER TABLE records ADD order name      VARBINARY(255);

Both of these will make order name sort correctly - the first one applies when latin1 is already active, the second one is generic.

SQLite mostly seems to do the right thing, at least with default settings.

OUR QUESTIONS:
1a. How do we tell Postgres to do "the right thing" for us, preferably in a way that does not force all users to do a dump/restore? We wouldn't mind an ALTER TABLE or the like!
1b. Is VARBINARY the best way to do it for MySQL?
1c. Should we cave in and encode ordername in some way that will sort reliably, regardless of database settings? Base64 perhaps? This does involve stretching ordername beyond 255 chars, which presumably is okay with all common versions of PG, My and SQLite3.


ISSUE 2: non-empty terminals

If a zone contains a name like 'a.b.c.example.com' but no 'b.c.example.com' or 'c.example.com', PowerDNS, when asked for b or b.c, will currently report NXDOMAIN. This is relatively harmless. However, when running with NSEC3, these NXDOMAINs can in fact translate to a.b.c.example.com becoming unreachable with some resolvers. This is not a bug in those resolvers! For correct NSEC3 operation, PowerDNS needs to pretend that b.c and c exist. Other name servers, that store their names in a tree structure in memory, get this for free. PowerDNS, when using SQL, does not.

The most common proposal for fixing this is to add 'b.c.example.com' and 'c.example.com' to the records table with type=NULL. This is in fact what the oraclebackend (not the goraclebackend) already does. For gsql, rectify-zone would automatically add (and, if necessary, remove) these records, if we go down this path.

Kees Monshouwer has sent me a patch that does this, while also adding a 'virt' BOOL field indicating whether a record is real or "emulated" in this sense.

OUR QUESTIONS:
2a. Do you think adding these records to the records table is sensible at all? If not, how else would we do it?
2b. Do you think type=NULL (SQL NULL) is an ugly hack? If so, what else should we do?
2c. If we accept type=NULL as an acceptable notation, should we still have this extra field just to make cleanup easier?



Thank you for reading this far. Please let us know if you have -any- thoughts on either of these subjects. Please also post if any of this is unclear to you, we love to share knowledge. We depend on you!

Kind regards,
-- 
Peter van Dijk
Netherlabs Computer Consulting BV - http://www.netherlabs.nl/