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/
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
