search

PowerDNS / pdns

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

auth: accept NOTIFY signed with unknown TSIG key if unsigned NOTIFY would be accepted #10867

Open peterthomassen opened 2 years ago

peterthomassen commented 2 years ago

Short description

pdns as as secondary should accept NOTIFYs signed with an unknown key whenever it would also accept an unsigned NOTIFY.

Environment

Steps to reproduce

  1. Configure a zone on a pdns primary, with TSIG-ALLOW-AXFR referencing an existing TSIG key
  2. Configure the same zone on a pdns secondary, without TSIG settings
  3. The secondary will reject the (signed) NOTIFYs of the primary

Expected behaviour

Accept a NOTIFY signed with an unknown key if an unsigned NOTIFY would have been accepted.

Rationale: An attacker who wants to inject fake NOTIFYs can easily send an unsigned NOTIFY, or strip the TSIG record. The rejection thus does not increase security. (The lack of benefit from this limitation is why I chose "bug" over "feature request".)

Actual behaviour

In default configuration (no TSIG-related settings set, no TSIG keys configured, neither globally nor on any domain), pdns as a secondary accepts unsigned NOTIFY. However, when a TSIG-signed NOTIFY is received and the key is unknown, it will get rejected: Packet for domain 'petertest123.dedyn.io' denied: can't find TSIG key with name 'default' and algorithm 'hmac-sha256'

Other information

Note that setting send-signed-notify=no is not a good workaround, as other secondaries may still expect the NOTIFY to be signed.

(This is actually the case in our setup: We communicate publicly with some secondaries (network A), so they need TSIG. Other secondaries (network B) have authenticity ensured through a VPN. We don't provision TSIG secrets on network B; if we did, network B admins would be in a position to forge AXFRs for network A nodes. We'd like to enforce strict trust boundaries.)

mind04 commented 2 years ago

Sending a valid answer is impossible, since an answer without a TSIG is invalid by definition for a query with a TSIG.

From RFC2845:

 4.6. Client processing of answer

   When a client receives a response from a server and expects to see a
   TSIG, it first checks if the TSIG RR is present in the response.
   Otherwise, the response is treated as having a format error and
   discarded.
peterthomassen commented 2 years ago

The section you are quoting is about how to process an answer that was received, and then you say that sending a valid answer is impossible. I don't see how this relates to each other, but I certainly don't think it has to do with processing incoming NOTIFYs.

Second, the text you quote explicitly say "When a client [...] expects to see a TSIG". However, in the current situation, the client (pdns secondary) does not expect the NOTIFY to come with a TSIG, as no key was configured for the zone on the secondary.

... or I got it all wrong?

mind04 commented 2 years ago

It is the other way around. The primary which is sending the notify query is the client and the secondary is the server. An unsigned answer to a signed notify is treated as invalid. This will result in an unacknowledged notify from the perspective of the primary. As a result of this the primary will most likely resend the notify a few times more and all the retries will result in processing on the secondary. With a large number of zones this can quickly result in an "interesting" flood of duplicate notify queries.

peterthomassen commented 2 years ago

Understood. - We can't answer NOTIFYs anyways, as we receive them on a multicast address (see #8747). ;-)

I think some extra load would be better than not acting on the NOTIFY at all, as long as pdns doesn't provide a way for the primary to specify per-secondary which TSIG key to use. What's the general feeling on this?

My favorite solution for a per-secondary TSIG configuration would be to make this based on secondary IP addresses, including subnets. In our case, for exampe, we could configure that no TSIG is used for secondaries which reside within our VPN network, on use various TSIG keys for secondaries located in other networks.

@nils-wisiol fyi

peterthomassen commented 2 years ago

Also, I don't think it's correct to "not act upon the NOTIFY" because you can't send an answer. (If that logic was accepted, then NOTIFYs arriving via a multicast IP address would have to be ignored, too -- but that's not a very sensible approach.)