PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.69k stars 906 forks source link

NSEC and NSEC3 discrepancy with wildcard CNAME #9668

Closed PAStheLoD closed 3 years ago

PAStheLoD commented 3 years ago

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

*.x.fffae.hu    60      IN      CNAME   web.coreconsult.systems.
default._domainkey.fffae.hu     60      IN      TXT     "v=DKIM1; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwmJPUkLBY5rq7sq6Q8Vtvh9RMh4aIcc/++rYR8e1aPIA91pxPFa4DEtDfAG4k9plNV/1nCo019cbw+rW8EHZuDshr+aG6y4Dj3qI/Eaa+hcIWxfpZYTmXME3Vwmay37ObZqyxCmEcLbEAd6vQ9zq9SNOi5tLhlwsf/pu+z2zSmXe5+cqutU6cJlGkHAlctQHbJNRuHEGpJFdMujthSqyXhQNaAY33vMIgDjOZhwprw4jJLXX1Jw0MewDQA1RysCMtcG4keI0nZDtkXQ9kAlYcRPBTumd8iV3x4SjaVAJWyixZpT8x1JvTtBvngRaHQlSeDTKhokamyMeJrHR42Ri7wIDAQAB"
fffae.hu        60      IN      A       78.47.146.252
fffae.hu        60      IN      CAA     0 iodef "mailto:ops@coreconsult.systems"
fffae.hu        60      IN      CAA     0 issue "letsencrypt.org"
fffae.hu        60      IN      MX      10 mail.coreconsult.systems.
fffae.hu        60      IN      NS      ns1.d-lan.hu.
fffae.hu        60      IN      NS      ns2.d-lan.hu.
fffae.hu        60      IN      NS      ns3.d-lan.hu.
fffae.hu        60      IN      NS      ns4.d-lan.hu.
fffae.hu        3600    IN      SOA     ns1.d-lan.hu hostmaster.d-lan.hu 2020110309 10800 3600 604800 3600
fffae.hu        60      IN      TXT     "v=spf1 mx -all"
mta-sts.fffae.hu        60      IN      CNAME   fffae.hu.
www.fffae.hu    60      IN      CNAME   fffae.hu.
# pdnsutil show-zone fffae.hu
This is a Native zone
Metadata items:
        NSEC3PARAM      1 0 1 ab
        SOA-EDIT-API    DEFAULT
Zone has hashed NSEC3 semantics, configuration: 1 0 1 ab
keys:
ID = 2 (CSK), flags = 257, tag = 52705, algo = 13, bits = 256     Active         Published  ( ECDSAP256SHA256 )
CSK DNSKEY = fffae.hu. IN DNSKEY 257 3 13 CBSmcu0WH4CkYk++3bthXWwtlqnTZIwjpfeBah0EAsKHIAXddkJiJqPq8fMrhcLtjXFBA1fGxwO3LGwfAaA2EQ== ; ( ECDSAP256SHA256 )
DS = fffae.hu. IN DS 52705 13 1 86af07e62ec5a17abefb2909881672d1cdeae28d ; ( SHA1 digest )
DS = fffae.hu. IN DS 52705 13 2 3b459f864c1aeec6dcef597deae1985d048d693b1d3a170330f4f85303fd812b ; ( SHA256 digest )
DS = fffae.hu. IN DS 52705 13 4 0e297cc71dd4993ae83852272f856694956c6b73ecbf7191a5a73c428eb3fecf7fea8bb66f8be84f89da9e5dc15c1690 ; ( SHA-384 digest )

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.

pdnsutil unset-nsec3 fffae.hu
# pdnsutil show-zone fffae.hu
This is a Native zone
Metadata items:
        SOA-EDIT-API    DEFAULT
Zone has NSEC semantics

dig @8.8.8.8 SERVFAIL,

Running rectify.

dnsviz says:

    NSEC proving non-existence of ax.x.fffae.hu/CNAME: The value of the Next Domain Name field in the NSEC RR with owner name *.x.fffae.hu indicates that it is the last NSEC RR in the zone, but the value (default._domainkey.fffae.hu) did not match the name of the zone apex (fffae.hu).
    NSEC proving non-existence of ax.x.fffae.hu/CNAME: The value of the Next Domain Name field in the NSEC RR with owner name *.x.fffae.hu indicates that it is the last NSEC RR in the zone, but the value (default._domainkey.fffae.hu) did not match the name of the zone apex (fffae.hu).

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!

Habbie commented 3 years ago

Did you run pdnsutil rectify-zone after disabling NSEC3?

Habbie commented 3 years ago

Did you run pdnsutil rectify-zone after disabling NSEC3?

Yes, you said you did. Can you provide a database dump of the broken situation?

Habbie commented 3 years ago

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?

Habbie commented 3 years ago

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

PAStheLoD commented 3 years ago

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!

Habbie commented 3 years ago

It seems that the ordername field is missing the "BINARY" collation (?).

Yes, that's the one that makes sorting work 'right' for NSEC!