NS1: DNSSEC broken

[Knight1]

Hi!

When I enable DNSSEC at NS1, dnscontrol crashes because it does not expect the DNSKEY record.

I am rather unsure if this is related to the NS1 provider or dnscontrol itself because NS1 sends these records.

Because you are mentioned @captncraig in the Docs I kindly tag you :)

----- Getting nameservers from: ns1
----- DNS Provider: ns1...panic: unparsable record received from ns1: unknown rtype (DNSKEY) when parsing (257 3 13 DNSKEY==) domain=(DOMAIN)

goroutine 1 [running]:
github.com/StackExchange/dnscontrol/v3/providers/ns1.convert(0xc00033d880, 0xc000cdfc70, 0x9, 0xc0010fc8a8, 0x1, 0x1, 0x1, 0x2)
	/Users/tlimoncelli/src/github.com/StackExchange/dnscontrol/providers/ns1/ns1provider.go:168 +0x3af
github.com/StackExchange/dnscontrol/v3/providers/ns1.(*nsone).GetDomainCorrections(0xc0000104b0, 0xc00061e780, 0x3, 0xc00061e700, 0x1, 0x0, 0x0)
	/Users/tlimoncelli/src/github.com/StackExchange/dnscontrol/providers/ns1/ns1provider.go:67 +0x17f
github.com/StackExchange/dnscontrol/v3/commands.run(0x1faeb3e, 0xc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1fac523, 0xa, 0x0, ...)
	/Users/tlimoncelli/src/github.com/StackExchange/dnscontrol/commands/previewPush.go:135 +0x3da
github.com/StackExchange/dnscontrol/v3/commands.Preview(...)
	/Users/tlimoncelli/src/github.com/StackExchange/dnscontrol/commands/previewPush.go:87
github.com/StackExchange/dnscontrol/v3/commands.glob..func6.1(0xc000127100, 0xb, 0xc)
	/Users/tlimoncelli/src/github.com/StackExchange/dnscontrol/commands/previewPush.go:25 +0x9a
github.com/urfave/cli/v2.(*Command).Run(0xc000193560, 0xc000126dc0, 0x0, 0x0)
	/Users/tlimoncelli/pkg/mod/github.com/urfave/cli/[email protected]/command.go:164 +0x4ed
github.com/urfave/cli/v2.(*App).RunContext(0xc000102a80, 0x21ab260, 0xc0000360b0, 0xc0000320a0, 0x5, 0x5, 0x0, 0x0)
	/Users/tlimoncelli/pkg/mod/github.com/urfave/cli/[email protected]/app.go:306 +0x81f
github.com/urfave/cli/v2.(*App).Run(...)
	/Users/tlimoncelli/pkg/mod/github.com/urfave/cli/[email protected]/app.go:215
github.com/StackExchange/dnscontrol/v3/commands.Run(0xc0004c2000, 0x58, 0xc0000a4058)
	/Users/tlimoncelli/src/github.com/StackExchange/dnscontrol/commands/commands.go:59 +0x247
main.main()
	/Users/tlimoncelli/src/github.com/StackExchange/dnscontrol/main.go:18 +0x45

➜  dnscontrol git:(master) ✗ ./dnscontrol version
dnscontrol 3.3.0 ("2d51dcddf39aa9c3be901768e2a6d5db13b9c6a3") built 04 Sep 20 17:06 CEST

[tlimoncelli]

The person that wrote the code is no longer involved in the project. We need a volunteer to look into this. (I don't have an account with NS1). Would you be interested in stepping up?

[Knight1]

Ok, after looking into it i think i know what is causing it.

The NS1 Provider is converting the records, but the function that does exactly that does not know the rtype "DNSKEY"

1. We can ignore DNSKEY inside the NS1 implementation by not calling PopulateFromString if we see an rtype of DNSKEY because we do not need it as far as I understand.
2. We add the rtype to the PopulateFromString Function.

I think 1. is the best. Which i implemented and fixed another Bug.

I found another bug

unknown rtype (SPF) when parsing

I currently ignore this... Is there a functioning converting routine?

But now i get this

Error getting corrections: DUPLICATE E_RECORD FOUND: {DOMAIN }  ttl=3600

Any Ideas?

[tlimoncelli]

CC: @costasd

[tlimoncelli]

Error getting corrections: DUPLICATE E_RECORD FOUND: {DOMAIN }  ttl=3600

When you get "DUPLICATE E_RECORD FOUND", manually delete all the records from the zone and try again. It should work. I don't know what causes this, but that's the workaround.

[costasd]

CC: @costasd

I've asked ns1 to enable DNSSEC on my test account to verify the bug (DNSSEC is opt-in in NS1).

Feel free to assign this to me!

[tlimoncelli]

unknown rtype (SPF) when parsing

Usually we change these to TXT records. See line 620 of providers/cloudflare/cloudflareProvider.go as an example.

[costasd]

Sadly I haven't been able to reproduce the SPF issue yet - setting SPF records from the panel doesn't break dnscontrol.

@Knight1, given how old this bug is, would you be able to retest and if still breaking, share a config snippet or test case triggering the issue?

Thanks!

[costasd]

@tlimoncelli Would you be able to close this as fixed when you get a chance? I don't see a reason for keeping it open anymore, as the crash was fixed with #1443 last year.

Thanks!

[tlimoncelli]

sure!