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

generic syntax fails for known types #804

Open Habbie opened 11 years ago

Habbie commented 11 years ago

bindbackend zonefile content:

weirdtxt.example.net.    3600 IN TYPE16 \# 4 03 78 0e 78

dig output:

weirdtxt.example.net.   3600    IN  TXT "# 4 03 78 0e 78"

(TYPE16 is TXT)

silbe commented 7 years ago

Has there been any progress on fixing that? This kind of incompatibility makes it really hard to use new RR types in production setups. One has to start using the generic syntax because the version of PowerDNS shipped by the distro will usually be too "old" to support the new RR type. But on the next distro update of one of the servers (synchronised via something other than AXFR) the whole setup will break down as the different versions need different content.

Habbie commented 7 years ago

There has been no progress but this is high on my list, indeed other people have also been reporting pain at upgrade time.

klaus3000 commented 7 years ago

Any progress on this? This hits us quite hard at the moment. Customers begin to use CAA with presigned zones and those "fancy" records in <4.0 are not implemented correctly. Hence, pdns 3.4 does not deliver RRSIGs for CAA (MBOXFW). So we need to update to 4.0 but have no clean upgrade path.

ahupowerdns commented 7 years ago

klaus, can you clarify what you would need to upgrade to 4.x?

klaus3000 commented 7 years ago

Actually I am not sure what would be the best way. At the moment we use pdns 3.4.11. The "control" server receives the zones from customers (AXFR) and stores it into the DB. The DB is replicated to ~30 nodes where pdns "slaves" reads from the DB and serves requests. CAA used to work fine (stored in DB as MBOXFW). Now we have customers with CAA and pre-signed zones. As the MBOXFW is implemented as "fancy type" it seems incomplete and RRSIGs are not served.

So we need a smooth way to upgrade the control server and the slaves, one after the other. The problem is, once we upgrade a slave to 4.0.3 it does not serve CAA anymore (as in the DB is a MBOXFW RR) until we update the control server - and the other way round. Even worse, if not using 4.0.3, but using newest rel/auth-4.0.x PDNS we respond with servfail to all queries (even for A queries) if there is an MBOXFW in DB: Exception building answer packet for example.com/CAA (All data was not consumed) sending out servfail

ahupowerdns commented 7 years ago

From our end, we can only solve problems in 4.x. Please let us know which problems in 4.x we need to solve. The 'MBOXFW' record is not coming back in any case. I want to be helpful, but 4.x is what we develop on.

klaus3000 commented 7 years ago

When reading from DB 4.x should support TYPExxx format (with content=# ) also when this type is meanwhile a "supported" type. 4.x would detects that this type is supported (eg TYPE257 will be interpreted as CAA) and tries to parse the content with the defined parser only. If this parsing fails, PDNS sends SERVFAIL. Instead it should try to reparse the content with the "UnknwonRessourceRecord" parser.

klaus3000 commented 7 years ago

Sounds this reasonable and doable?

ahupowerdns commented 7 years ago

So the bug is: 4.x attempts to parse unknown records incorrectly, because it applies the known record parser?

zeha commented 7 years ago

From my previous understanding of the code, yes. Old TYPExxx records are obviously not in plain-text in the DB and then the non-unknown parser chokes on the unknown-encoded content.

zeha commented 7 years ago

IIRC the logic in core is:

But core does not know if the Qtype came from a "good" Qtype (A, CNAME, ...) or from an "unknown" Qtype (TYPExxx) in the DB.

klaus3000 commented 7 years ago

Yes, zeha is correct. I also described the problem in detail (with example) in comment https://github.com/PowerDNS/pdns/issues/4923#issuecomment-273597415

Habbie commented 7 years ago

https://www.nlnetlabs.nl/blog/2012/09/20/howto-add-new-rrtypes-to-nsd/ notes that in the NSD source, the parser for unknown types is added to each type. I wonder if we could just fall back from the specific to the generic unknown parser on parse failure. I bet this would work for a lot of types.

klaus3000 commented 7 years ago

That's actually what I propsed in https://github.com/PowerDNS/pdns/issues/4923#issuecomment-273597415. I tried two approaches: catch the parse exception at a place where it is possible to reparse with the generic unknown parser, or call the generic parser instead of throwing the parsing exception. Unfortunately this code is quite complex in PDNS so I failed and have to wait that some fixes it which wrotes the original code.

nlyan commented 7 years ago

RFC 3597 suggests that the hex-encoded binary RDATA format be available to all known types regardless of whether you actually use the TYPEXXX-form record type tag or not. When I wrote my own master file parser a few years ago, I opted for the RDATA grammar to always try and decode the this format before falling back to the quoted & unquoted tokenization process.

stbuehler commented 6 years ago

I think RFC 3597 should not be followed in the "crazy combinations might be allowed" remark.

The reason is simple: generic RDATA texts \# <nn> <hex> are not invalid for normal interpretations (the obvious example being TXT), and allowing mixing the known and unknown representations only leads to ambiguous parsing.

As far as I understand this isn't needed to solve this bug in pdns; it would be enough to always parse TYPE... with the generic parser instead of the type-specific parser.

Habbie commented 3 years ago

Running with upgrade-unknown-types=yes can make these records work, since #9623.