dnsimple / coredns-dnsimple Goto Github PK

What is the problem?

NAPTR records provided via the DNSimple app should be considered valid.

Steps to reproduce

1. Create a NAPTR record with 100 10 "U" "E2U+sip" "!^.*$!sip:[email protected]!"
2. Expect to see an error showing the following:

[ERROR] plugin/dnsimple: failed to parse resource record: dns: bad NAPTR Replacement: " " at line: 1:28

Currently, if CoreDNS is used as the system resolver, it will fail to start, since it will be unable to make the DNS lookup to call the DNSimple API on setup because the system resolver is set to itself, but it isn't responding yet.

A temporary workaround is to change the system resolver to something else first, start CoreDNS, then change the system resolver back. However, this only lasts until CoreDNS restarts.

Ideally, we should not block CoreDNS from starting, and delay API calls until our first fetch. This way, any forward/fallback/alternate plugins can start serving those DNS queries while our plugin is starting.

Currently, if DNSIMPLE_TOKEN and/or DNSIMPLE_ACCOUNT_ID are not provided, we simply silently proceed, which will lead to less friendly errors around API failures. We should instead check that these exist and fail if they haven't been provided in the config or env vars.

What is the problem?

When an ALIAS record is being loaded and we fail to resolve the ALIAS record we log it as an error and do not add it to the zone file. We also send the error to the DNSimple APP flagging the sync as failed.

Steps to reproduce

1. Create an ALIAS record with a bad target e.g. odjasouhdisghcvdsyv984u3roi23jkjvcndcv08i23.com.
2. Sporadically syncs will be reported as failed and will see the following in the app:
   

For advanced users who don't need or want the automatic status updates, it should be possible to turn off the feature if requested. For example, they may already have their own logging, monitoring, and alerting set up, and would prefer not to duplicate such functionality.

If an update fails, we should delay the next update exponentially, as otherwise we'll repeatedly perform updates on a fixed interval while the network or service is degraded. Additionally, we should also not wait too long after the first failure, as the issue may be ephemeral and we should not persist a degraded or stale state.

What is the problem?

SRV records should work.

Steps to reproduce

1. Create an SRV record in the DNSimple App.
2. Expect to see an error:

[ERROR] plugin/dnsimple: failed to parse resource record: dns: bad SRV Port: "server.pros-at.work" at line: 1:67
[ERROR] plugin/dnsimple: failed to parse resource record: dns: bad SRV Port: "tko.pros-at.work" at line: 1:60