api: consider allowing certain non-alphanumeric names in CNAME targets

[peterthomassen]

pdns does allow some non-alphanumeric characters in CNAME targets:

c =='-' || c == '_' || c=='*' || c=='.' || c=='/' || c=='@' || c==' ' || c=='\\' || c==':'

(source)

Our dnspython preprocessing escapes some characters (e.g. @ --> \@) which the pdns auth API does not accept. (They only except escaping for . and \, and \DDD format below 0x20 and above 0x7F.) Related: https://github.com/PowerDNS/pdns/issues/9870

I'm not sure how to resolve this, but we should at least fix the 500 response that this currently triggers, maybe by rejecting the characters that dnspython would escape or by unescaping them.* Both approaches would need some corner-case code of which I'm not sure where it should best live.

@nils-wisiol What do you think?

*: Insisting that users encode them using \DDD format does not help, as dnspython parses and canonicalizes that, of course. Btw, I checked, and we do accept e.g. \013 in CNAME targets.

[peterthomassen]

When attempting to send @ as part of the names in MX or NS, the same thing happens, and pdns rejects them because they are not in expected format. According to pdns IRC, however, they would also be rejected if sent in correct format (unescaped at sign), because names in MX and NS need to be host names, which have stricter conditions.

So if we find a solution for this ticket that would allow passing on @ to pdns' satisfaction, MX and NS are still broken. However, RFC 2181 Sec. 11 speaks against that:

any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added).

[nils-wisiol]

Zone updates in knotc's interface seem to closer to dnspython in terms of they parse and not parse. An example of how the knotc zone update works is below (in knotc shell):

conf-begin
conf-set zone.domain example.com
conf-commit
zone-begin example.com
zone-set example.com @ 7200 SOA ns hostmaster 1 86400 900 691200 3600
zone-set example.com ns 3600 A 192.168.0.1
zone-set example.com www 3600 A 192.168.0.100
zone-commit example.com

I've tested several "weird" values including non-ASCII bytes, @, $, and paranthesis and it seems to work when escaped with \\, like so:

knotc> zone-set example.com b\\130 3600 MX 10 (a\\129a.example.com.)