NETCUP: Parsed `CNAME`, `TLSA` entries cannot be used w/ other providers

[m-ueberall]

When trying to push CNAME, TLSA entries in js format to another provider (tested w/ DESEC), the following cause problems:

CNAME('www', '\@.')
-->
2022/01/04 17:42:50 printIR.go:94: ERROR: in CNAME www.example.org: target (@.) includes invalid char

Here, unless there is a unified placeholder for the domain name, the latter should be included in verbatim.

TLSA('_tcp', 0, 0, 0, '2 1 2 77[…]')
-->
CREATE TLSA _tcp.example.org 0 0 0 2 1 2 77[…] ttl=3600

FAILURE! failed create RRset (deSEC): HTTP status 400 Bad Request Body: [{},{},{},{},{"non_field_errors":["Record content for type TLSA malformed: Odd-length string"]},{}], the API does not provide more information

Here, the correct values for parameters 2–4 should be stripped from parameter 5.

[tlimoncelli]

Hi there!

I'm not exactly sure I understand the problem. Here are my questions:

1. Which providers are involved? Is it working for NETCUP but not when you move to deSEC?
2. I'm unclear what '\@.' means in the CNAME. Usually one uses '@' as a substitute for the apex domain, but that should be a 1-character string. I'm not sure what you're trying to achieve by adding \ and . to the string. Can you clarify?

Tom

cc @kordianbruck @D3luxee

[m-ueberall]

1. Which providers are involved? Is it working for NETCUP but not when you move to deSEC?

The involved providers are NETCUP (here, used in conjunction with dnscontrol get-zones --format js netcup NETCUP example.org >dnsconfig.js) and – after modifying the registrar/provider references – deSEC (here, used in conjunction with dnscontrol preview|push). I currently don't have a test domain registered with Netcup, so I can only run dnscontrol preview against the original js definition, but this yields the same error for CNAME records and also does not support parsing/previewing/pushing TLSA records:

2022/01/05 00:14:32 printIR.go:94: ERROR: in CNAME www.example.org: target (@.) includes invalid char
2022/01/05 00:14:32 printIR.go:94: ERROR: domain example.org uses TLSA records, but DNS provider type NETCUP does not support them

2. I'm unclear what '\@.' means in the CNAME. Usually one uses '@' as a substitute for the apex domain, but that should be a 1-character string. I'm not sure what you're trying to achieve by adding \ and . to the string. Can you clarify?

I wouldn't know either. If you use the browser-based Netcup Customer Control Panel (CCP), the entry in question shows an "@" which I would expect to see in the js configuration as well:

However, regardless of the above representation, I'd expect that js files can be used against every provider without requiring modifications (as long as all used rtypes are supported, that is).

[tlimoncelli]

Ah! This sounds like a bug in dnscontrol's JS generator. It should never generate a string like \@. since it isn't valid.

Could you help me reproduce the problem locally?

P.S. In my defense, "-forma js" is intended to be “a decent first draft”, only requiring minimal editing.

[m-ueberall]

Could you help me reproduce the problem locally?

Sure! Unfortunately, Netcup does not support read-only tokens, so by company policy, I'm unable to provide you with one–even using a token as non-shared secret in a controlled Drone environment would be a no-go. However, I can manually run a number of tests and forward you logs/outputs if needed.

I also reran the get-zones command against the desec provider (after correcting all CNAME, TLSA entries in the original js file generated using the netcup provider and successfully duplicating/pushing the contents using the non-authoritative deSEC nameservers first). In the resulting output, "@" is not used for CNAME (which always shows the domain name) and parameters 2–5 for TLSA records are also valid. (The same goes for files in zone format generated using get-zones; named-checkzone v9.16.1-Ubuntu chokes on the netcup output, the desec output seems to be valid–apart from missing SOA records.)

[tlimoncelli]

Yes, it can be difficult to make a repo case when there's an API involved.

I noticed that the code in providers/netcup/types.go manipulates \ and . in the target. I think we should focus there.

Let's see if this helps: I added some temporary Printf's in https://github.com/StackExchange/dnscontrol/pull/1365. Could you compile from that branch and run get-zones? Hopefully that will give us some clues.

Tom

[m-ueberall]

Are the following excerpts of two records enough? (The entire log is larger than 33 kB – I can send it to your e-mail address associated with the below commit without anonymization if needed.)

% /tmp/dnscontrol/dnscontrol version
dnscontrol v3.13.0 ("8c932bdde20615a2e85996b28b7c4b6add1e2775") built 05 Jan 22 17:47 CET
% /tmp/dnscontrol/dnscontrol get-zones --format=js netcup NETCUP example.org
[…]
DEBUG: NETCUP: r={ID:658946 Hostname:www Type:CNAME Priority:0 Destination:@ Delete:false State:yes}
DEBUG: NETCUP: TARGET BEFORE="@"
DEBUG: NETCUP: rc=\@.
DEBUG: NETCUP: TARGET AFTER ="\\@."
[…]
DEBUG: NETCUP: r={ID:2181821 Hostname:_tcp Type:TLSA Priority:0 Destination:2 1 2 77[…]40 Delete:false State:yes}
DEBUG: NETCUP: TARGET BEFORE="2 1 2 77[…]40"
DEBUG: NETCUP: rc=0 0 0 2 1 2 77[…]40
DEBUG: NETCUP: TARGET AFTER ="0 0 0 2 1 2 77[…]40"

[tlimoncelli]

Thanks!

@kordianbruck: Does that give you enough info to fix the issue? It looks like that function needs to special-case "@". As the owner of this provider, I should hand this over to you.

[kordianbruck]

Yeah, I can wrangle with this on the weekend. Thanks for locating it - I can probably reproduce it with one of my domains then.

[D3luxee]

@tlimoncelli you mentioned me but if i get it correct the issue is in the netcup provider and not in the desec provider. So i have nothing to do. Correct?

[tlimoncelli]

@D3luxee Yup! You're off the hook! Thanks for checking in!

[m-ueberall]

@kordianbruck Any news on this?

[tlimoncelli]

Friendly ping? @kordianbruck

[m-ueberall]

@tlimoncelli, @kordianbruck: It's been more than three months now… Despite all understandable reasons/circumstances – Does it make sense to list provider “NETCUP” as still being (actively) maintained?

[kordianbruck]

@m-ueberall I'd not say its "actively maintained" but its still working reasonably well for most of the things. I've put some special handling into https://github.com/kordianbruck/dnscontrol/tree/niche-case - Would you be able to give it another run to see if this is working now? (It ain't pretty, but ugh, I don't have a better idea right now)

[kordianbruck]

Hmm, I'm still getting the backslash:

D("xxx.de", REG_CHANGEME,
        DnsProvider(DSP_NETCUP),
        CNAME('foo', '\@')
)

[kordianbruck]

Well actually @ notes the apex domain, which I realized after looking at https://github.com/miekg/dns/blob/master/dnsutil/util.go#L19 - So that function then goes and replaces the @ with the actual domain, which is what I observed with other providers. So I think this should now be correct after that PR is merged.