Add an IGNORE() DSL directive #183

onlyhavecans · 2017-08-14T22:50:33Z

Occasionally I have a record or two which is either not a supported type by dnscontrol, or I otherwise would not want it managed by dnscontrol. It would be nice to have a IGNORE(name) directive to allow dnscontrol to skip deleting or modifying the records

examples for why;

DynamicDNS records controlled externally
URL records from DNSimple & NameCheap

The text was updated successfully, but these errors were encountered:

tlimoncelli · 2017-08-15T13:59:49Z

Let me make sure I understand the feature. Basically IGNORE("label") would tell DNSControl not to touch a DNS record in that domain whose name is "label". The contents would be created by some external mechanism. (i.e. someone has inserted the record via a web UI or other mechanism)

captncraig · 2017-08-15T14:22:01Z

This sounds a lot like the (poorly documented) NO_PURGE option.

D("example.com", .... , NO_PURGE,
  A("foo","1.2.3.4")
)

Will cause dnscontrol to manage the records you define, but not delete others. Is that close to what you are asking for?

onlyhavecans · 2017-08-15T16:23:09Z

@tlimoncelli your summary is correct. That is the desired behavior. I'd like to define the record as being handled externally so it is not tampered with.

@captncraig that's very close, but I'd like to be able to define specific records not just a blanket behavior for all records not defined.

For now I could probably use NO_PURGE to do this but I'd still like to allow for record cleaning.

gbrayut · 2017-08-15T17:04:38Z

We did have something like that for the Cloudflare provider called ignored_labels but it probably is a good idea to create a better standard approach for how to do this across all providers.

tlimoncelli · 2017-08-15T17:33:08Z

The cleanest solution is to implement "special" records in the providers. There is now a mechanism to list capabilities of a provider (for example, some providers are marked as supporting SRV records). URL records from DNSimple & NameCheap could be implemented fairly easily as a "REDIRECT()" record that does the right thing depending on the provider.

onlyhavecans · 2017-08-15T18:00:04Z

At some point in the near future I'd like to try my hand at adding URL record support much like the existing ALIAS records assuming someone else doesn't get to it first. However that's a separate issue from this. I would still like an IGNORE("label") record as well

tlimoncelli · 2017-08-15T20:02:17Z

REDIRECT(): @onlyhavecans Nobody is currently working on it. I did recently update the doc on how to add new record types (https://stackexchange.github.io/dnscontrol/adding-new-rtypes) so this seems like an excellent opportunity for you.

@gbrayut: Good point. IGNORE("label") could simply generalize the code in Cloudflare's ignored_labels feature. Great idea!

IGNORE is like NO_PURGE but for a spefic record instead of the whole zone. This is very useful for instance if you have a zone where only some records are managed externally from dnscontrol (for instance using kubernetes external dns system). Adding IGNORE("foo") in the zone will make dnscontrol not trying to manage the "foo" record (and especially not deleting it). dnscontrol will error out if the "foo" domain is both ignored and managed in dnscontrol. This can be seen as a generic Cloudflare's ignored label, even though this changeset doesn't remove that specific feature. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

) Since IGNORE implements a generic `ignoredLabels` system, let the user know CF `ignoredLabels` are deprecated. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

IGNORE is like NO_PURGE but for a spefic record instead of the whole zone. This is very useful for instance if you have a zone where only some records are managed externally from dnscontrol (for instance using kubernetes external dns system). Adding IGNORE("foo") in the zone will make dnscontrol not trying to manage the "foo" record (and especially not deleting it). dnscontrol will error out if the "foo" record is both ignored and managed in dnscontrol. This can be seen as a generic Cloudflare's ignored label. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

) Since IGNORE implements a generic `ignoredLabels` system, let the user know CF `ignoredLabels` are deprecated. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

masterzen · 2018-01-14T16:31:07Z

I've pushed PR #300 to fix this issue (and don't know why github doesn't show it).

IGNORE is like NO_PURGE but for a spefic record instead of the whole zone. This is very useful for instance if you have a zone where only some records are managed externally from dnscontrol (for instance using kubernetes external dns system). Adding IGNORE("foo") in the zone will make dnscontrol not trying to manage the "foo" record (and especially not deleting it). dnscontrol will error out if the "foo" record is both ignored and managed in dnscontrol. This can be seen as a generic Cloudflare's ignored label. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

) Since IGNORE implements a generic `ignoredLabels` system, let the user know CF `ignoredLabels` are deprecated. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

IGNORE is like NO_PURGE but for a spefic record instead of the whole zone. This is very useful for instance if you have a zone where only some records are managed externally from dnscontrol (for instance using kubernetes external dns system). Adding IGNORE("foo") in the zone will make dnscontrol not trying to manage the "foo" record (and especially not deleting it). dnscontrol will error out if the "foo" record is both ignored and managed in dnscontrol. This can be seen as a generic Cloudflare's ignored label. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

) Since IGNORE implements a generic `ignoredLabels` system, let the user know CF `ignoredLabels` are deprecated. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

* Add support for the IGNORE(name) directive (#183) IGNORE is like NO_PURGE but for a spefic record instead of the whole zone. This is very useful for instance if you have a zone where only some records are managed externally from dnscontrol (for instance using kubernetes external dns system). Adding IGNORE("foo") in the zone will make dnscontrol not trying to manage the "foo" record (and especially not deleting it). dnscontrol will error out if the "foo" record is both ignored and managed in dnscontrol. This can be seen as a generic Cloudflare's ignored label. Signed-off-by: Brice Figureau <brice@daysofwonder.com> * Deprecate CloudFlare ignoredLabels in favor of IGNORE (#183) Since IGNORE implements a generic `ignoredLabels` system, let the user know CF `ignoredLabels` are deprecated. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

rblenkinsopp · 2018-05-23T10:48:50Z

It would be great if this had support for wildcarding. ACME (Letsencrypt) DNS validation currently creates TXT "_acme-challenge.SUBDOMAIN" records for each subdomain being validated.

It would be great if I could have one entry such as:
IGNORE("_acme-challenge*")

Which can capture all of these.

masterzen · 2018-05-23T11:02:22Z

@rblenkinsopp this is a good idea!
I'll try to produce a PR in the coming weeks (but no promise as I have very few spare time).

captncraig · 2018-05-23T17:00:48Z

This is something we have been mulling over for a while, but haven't pulled the trigger on yet, because of a couple of complications:

Some providers do not easily lend to this style of management, particularly when you need to supply the entire zone for each change. (Namecheap, gandi, bind at least are in this category.) I think this can be tested more fully by beefing up the integration tests to look for such scenarios and make sure each provider is compliant.
We do have NO_PURGE which is kinda like this, but not as powerful. It is currently locked behind a provider-specific feature flag, but I'd like to remove that restriction once we have better testing. These features do feel "risky" to me, mostly because I'm afraid dnscontrol will start deleting things it shouldn't.

The way I think I look at things is that each record set (unique record type and name) falls into one of two caregories: managed or unmanaged. If it is managed (the default for everything), then dnscontrol will make it match your desired state, or delete it if it is not in the config.

"No purge", indicates that record sets not present in the config should be left as is (considered unmanaged) and not deleted. This is limiting because there may be certain records you do not wish to delete, but in general do want to purge unused records. If you only want to have a subset of records as "unmanaged", it can be frustrating to not be able to delete other record sets ever.

The proposed "ignore" feature will fill this gap, allowing you to say "ignore records with this pattern, but feel free to delete others if they are not in the config." This seems useful, but again, I'd like to have great test coverage before I'd really trust it.

captncraig · 2018-05-23T17:02:41Z

An aside about _acme-challenge @rblenkinsopp, what are you using to issue certs? Have you tried dnscontrol's support for LE?

The challenge records should be fine to delete once the validations succeed.

rblenkinsopp · 2018-05-23T20:50:55Z

@captncraig: I did realise after asking that they should probably not be there any more anyway but the request still seemed reasonable, if not for the specific case that I stated. I don't want to take this off-topic too much but I am using traefik for LE support at the moment, I've not looked at dnscontrol's support for that yet.

jeff-cook · 2019-07-16T17:53:28Z

It looks like this may be near being released, but I'll add my use case anyway.

I have a domain I want completely managed by DNS Control, except for one record which needs to by handled dynamically. I would really like to leave PURGE on. Thought about writing a script to update the dnsconfig.js file with the current value, just before it ran. But the IGNORE option would be best.

Thank you for your hard work on this amazing project.

Tested and working dnscontrol 2.9 ("cafd4d387a61a5932394670a4fc4ff02196c5707[dirty]") built 15 Jul 19 16:31 UTC

tlimoncelli · 2020-03-10T15:56:22Z

I noticed this issue hasn't been touched in a while. I think that IGNORE() currently works this way. Can you verify?

) (StackExchange#300) * Add support for the IGNORE(name) directive (StackExchange#183) IGNORE is like NO_PURGE but for a spefic record instead of the whole zone. This is very useful for instance if you have a zone where only some records are managed externally from dnscontrol (for instance using kubernetes external dns system). Adding IGNORE("foo") in the zone will make dnscontrol not trying to manage the "foo" record (and especially not deleting it). dnscontrol will error out if the "foo" record is both ignored and managed in dnscontrol. This can be seen as a generic Cloudflare's ignored label. Signed-off-by: Brice Figureau <brice@daysofwonder.com> * Deprecate CloudFlare ignoredLabels in favor of IGNORE (StackExchange#183) Since IGNORE implements a generic `ignoredLabels` system, let the user know CF `ignoredLabels` are deprecated. Signed-off-by: Brice Figureau <brice@daysofwonder.com>

wolfedale · 2021-08-10T12:13:20Z

I'm looking for a similar option but I would like to specify record type. Is it possible? I'm trying to use NO_PURGE and IGNORE_NAME('') but those are not doing what I'm expecting. My problem is that I want to specify some records by dnsControl, and I don't want to touch (add,modify,delete) all the others which are not in the dnsControl.

I'm experimenting with those two but I'm always getting same result:

----- Getting nameservers from: gcloud ----- DNS Provider: gcloud... 1 correction #1: CREATE A foo.example.com {MY_IP} ttl=60 MODIFY NS example.com: (ns-cloud-e4.googledomains.com. ttl=21600) -> (ns-cloud-e4.googledomains.com. ttl=300) MODIFY NS example.com: (ns-cloud-e3.googledomains.com. ttl=21600) -> (ns-cloud-e3.googledomains.com. ttl=300) MODIFY NS example.com: (ns-cloud-e2.googledomains.com. ttl=21600) -> (ns-cloud-e2.googledomains.com. ttl=300) MODIFY NS example.com: (ns-cloud-e1.googledomains.com. ttl=21600) -> (ns-cloud-e1.googledomains.com. ttl=300)

and my config looks like this:

D("example.com", REG_NONE, DnsProvider(GCLOUD), NO_PURGE, A("foo","{IP}", TTL('60')), IGNORE_NAME("*", "NS") );

is it possible to not touch NS records?

Thanks!

tlimoncelli · 2021-08-10T12:30:00Z

is it possible to not touch NS records?

Not at this time. PRs accepted.

Please start a new issue if you want to discuss this particular situation.

tlimoncelli added the Type: Enhancement label Nov 9, 2017

koesie10 mentioned this issue Apr 17, 2019

Add glob pattern/wildcard support for IGNORE directive #463

Merged

tlimoncelli closed this as completed Mar 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add an IGNORE() DSL directive #183

Add an IGNORE() DSL directive #183

onlyhavecans commented Aug 14, 2017

tlimoncelli commented Aug 15, 2017

captncraig commented Aug 15, 2017

onlyhavecans commented Aug 15, 2017

gbrayut commented Aug 15, 2017

tlimoncelli commented Aug 15, 2017

onlyhavecans commented Aug 15, 2017 •

edited

Loading

tlimoncelli commented Aug 15, 2017

masterzen commented Jan 14, 2018

rblenkinsopp commented May 23, 2018 •

edited

Loading

masterzen commented May 23, 2018

captncraig commented May 23, 2018

captncraig commented May 23, 2018

rblenkinsopp commented May 23, 2018 •

edited

Loading

jeff-cook commented Jul 16, 2019 •

edited

Loading

tlimoncelli commented Mar 10, 2020

wolfedale commented Aug 10, 2021 •

edited

Loading

tlimoncelli commented Aug 10, 2021

Add an IGNORE() DSL directive #183

Add an IGNORE() DSL directive #183

Comments

onlyhavecans commented Aug 14, 2017

tlimoncelli commented Aug 15, 2017

captncraig commented Aug 15, 2017

onlyhavecans commented Aug 15, 2017

gbrayut commented Aug 15, 2017

tlimoncelli commented Aug 15, 2017

onlyhavecans commented Aug 15, 2017 • edited Loading

tlimoncelli commented Aug 15, 2017

masterzen commented Jan 14, 2018

rblenkinsopp commented May 23, 2018 • edited Loading

masterzen commented May 23, 2018

captncraig commented May 23, 2018

captncraig commented May 23, 2018

rblenkinsopp commented May 23, 2018 • edited Loading

jeff-cook commented Jul 16, 2019 • edited Loading

tlimoncelli commented Mar 10, 2020

wolfedale commented Aug 10, 2021 • edited Loading

tlimoncelli commented Aug 10, 2021

onlyhavecans commented Aug 15, 2017 •

edited

Loading

rblenkinsopp commented May 23, 2018 •

edited

Loading

rblenkinsopp commented May 23, 2018 •

edited

Loading

jeff-cook commented Jul 16, 2019 •

edited

Loading

wolfedale commented Aug 10, 2021 •

edited

Loading