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

Seth Mattinen sethm at rollernet.us
Mon Sep 3 17:54:57 UTC 2012


On 9/3/12 10:19 AM, Peter van Dijk wrote:

> 
> ISSUE 1: ordername sorting
> 

> 
> 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?

Yes. A similar issue was seen in sql-based bayes databases for
SpamAssassin tokens and the solution is to use BINARY for the token col
instead of CHAR. Generic fixes are best.

> 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.

No, the database should be able to handle it properly. If it truly can't
then mark the feature as unsupported for that one outlier.



> 
> 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?

If it's internal-only and handled automatically by rectify-zone it makes
sense to not have a type and that it would be null. External management
tools can be easily modified to ignore rows were type is null.

> 2c. If we accept type=NULL as an acceptable notation, should we still have this extra field just to make cleanup easier?
> 

A 'virt' flag wold be more future-proof if in the future virtual records
needed a type for some currently unforeseen reason. Management tools can
likewise ignore 'virt=true' records.

~Seth



More information about the Pdns-users mailing list