Closed PAStheLoD closed 3 years ago
Did you run pdnsutil rectify-zone
after disabling NSEC3?
Did you run
pdnsutil rectify-zone
after disabling NSEC3?
Yes, you said you did. Can you provide a database dump of the broken situation?
Yes, you said you did. Can you provide a database dump of the broken situation?
Also nevermind that. Your database has a sorting issue - it sorts _domainkey
after x
, which is wrong. What database backend is this? Did you change our schema in any way?
To be clear, this does not look like a pdns bug, and we'll close the ticket as soon as we are certain of that. When we do that, we'll ask you to come to IRC or the pdns-users mailing list for further help. Of course, you are welcome to do so at this point already. Details are at https://www.powerdns.com/opensource.html
Oh, wow, thanks for the super fast response! Sorry, I was considering the mailing list, but then when the NSEC3 version "worked" I opted for opening this issue.
This is a MariaDB (10.4.15-MariaDB-1:10.4.15+maria~focal-log mariadb.org binary distribution)
MariaDB [powerdns]> show create table records\G
*************************** 1. row ***************************
Table: records
Create Table: CREATE TABLE `records` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`domain_id` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
`type` varchar(10) DEFAULT NULL,
`content` varchar(512) DEFAULT NULL,
`ttl` int(11) DEFAULT NULL,
`prio` int(11) DEFAULT NULL,
`change_date` int(11) DEFAULT NULL,
`disabled` tinyint(1) DEFAULT 0,
`ordername` varchar(255) DEFAULT NULL,
`auth` tinyint(1) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `rec_name_index` (`name`),
KEY `nametype_index` (`name`,`type`),
KEY `domain_id` (`domain_id`),
KEY `orderindex` (`ordername`),
KEY `recordorder` (`domain_id`,`ordername`),
CONSTRAINT `records_domain_id_ibfk` FOREIGN KEY (`domain_id`) REFERENCES `domains` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=12512 DEFAULT CHARSET=utf8
I enabled the foreign keys, but haven't done anything else - to my knowledge.
It seems that the ordername field is missing the "BINARY" collation (?).
After trying an alter table records modify column ordername VARCHAR(255) BINARY DEFAULT NULL
(which results in ordername varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL
)and a rectifying again:
# select id, name, disabled, ordername, type, auth from records where domain_id = 137;
| 12495 | *.x.fffae.hu | 0 | x * | CNAME | 1 |
| 12497 | x.fffae.hu | 0 | NULL | NULL | 1 |
| 12509 | default._domainkey.fffae.hu | 0 | _domainkey default | TXT | 1 |
| 12510 | fffae.hu | 0 | | SOA | 1 |
| 12511 | _domainkey.fffae.hu | 0 | NULL | NULL | 1 |
Thanks again!
It seems that the ordername field is missing the "BINARY" collation (?).
Yes, that's the one that makes sorting work 'right' for NSEC!
Short description
Using NSEC results in validating resolvers deeming the response bogus, while using NSEC3 leads to things working.
Environment
Steps to reproduce
The presence of the default._domainkey TXT record makes a difference. (Otherwise the NSEC result has the name of the apex as "next".)
https://dnsviz.net/d/ax.x.fffae.hu/dnssec/ -- everything seems to be in order.
dig @8.8.8.8 works.
Switching back to NSEC.
dig @8.8.8.8 SERVFAIL,
Running rectify.
dnsviz says:
Also it claims that there's one bogus validation result: ax.x.fffae.hu/CNAME (NXDOMAIN).
Disabling the TXT record also makes the NSEC case "work".
Expected behaviour
If this is by design/RFC then it would be very helpful to document it somewhere, otherwise it might be a bug.
Thanks for your time!