Feature idea, have resolvers only entered to resolver if they work

[nickanderson]

I stumbled on this link http://kvz.io/blog/2013/03/27/poormans-way-to-decent-dns-failover about DNS failover. Made me think we could improve the resolver sketch to only include resolvers that respond to a test lookup. Report when a desired resolver is not answering as expected.

[tzz]

I am personally not hot on the idea of dynamically rewriting your resolv.conf based on a network outage. But you could certainly do it once sketch composition is rolled out with the DC API rewrite by using the ping_report sketch and filtering the original list of resolver candidates.

[tzz]

If you leave this open, assign to yourself :)

[nickanderson]

Its not at the top of my list by any means. And I don't think i have the rights to assign issues

[tzz]

I guess you have to be repo contributor, sorry. I'll assign it to myself and you'll have to keep track of it...

[zzamboni]

I agree - I'm not sure a network outage should trigger the sudden disappearance of your DNS settings. If anything, this should be an option, off by default.

It would also make it difficult to provision systems that are to be moved to some other network after their initial provisioning.

--Diego

On Apr 4, 2013, at 5:08 PM, Ted Zlatanov notifications@github.com wrote:

I am personally not hot on the idea of dynamically rewriting your resolv.conf based on a network outage. But you could certainly do it once sketch composition is rolled out with the DC API rewrite by using the ping_report sketch and filtering the original list of resolver candidates.

—
Reply to this email directly or view it on GitHub.

[nickanderson]

That's fine in not in love with it. Let's close it. Random thoughts aren't always good.

Diego Zamboni notifications@github.com wrote:

I agree - I'm not sure a network outage should trigger the sudden
disappearance of your DNS settings. If anything, this should be an
option, off by default.

It would also make it difficult to provision systems that are to be
moved to some other network after their initial provisioning.

--Diego

On Apr 4, 2013, at 5:08 PM, Ted Zlatanov notifications@github.com
wrote:

I am personally not hot on the idea of dynamically rewriting your
resolv.conf based on a network outage. But you could certainly do it
once sketch composition is rolled out with the DC API rewrite by using
the ping_report sketch and filtering the original list of resolver
candidates.

—
Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub:
#265 (comment)

Sent from Kaiten Mail. Please excuse my brevity.

[tzz]

Idea: change it so instead of removing unresponsive resolvers, it prints a warning report about them. It should use persistence to avoid querying them too often, but I think that would be a really nice option to the current resolver sketch.

[jooooooon]

I like your idea @tzz. It is too easy to have several resolvers on a host, and just one not working, but you never know about it. If CFEngine can help, why not!

Another idea: have CFEngine check that resolvers work and only add them if they do. That is, never remove resolvers based on this check, but only add new ones if we know they work.

[nickanderson]

The original thought is that it would report at some interval, and perhaps only in a given context class expression that the desired resolver was not answering for some test domain. I don't think ping is sufficient to tell me if a resolver is down. I've worked in many environments where ping was dropped by the firewall. Anyway, all having broken resolvers in your nameserver list does is slow down any requests that hit it, and when it started working again it would be re-added.

Jonathan Clarke notifications@github.com wrote:

I like your idea @tzz. It is too easy to have several resolvers on a
host, and just one not working, but you never know about it. If
CFEngine can help, why not!

Another idea: have CFEngine check that resolvers work and only add
them if they do. That is, never remove resolvers based on this check,
but only add new ones if we know they work.

---

Reply to this email directly or view it on GitHub:
#265 (comment)

Sent from Kaiten Mail. Please excuse my brevity.

[tzz]

Hmm, I see how this would work. I'm not sure it's very generic; the vast majority of users are OK with a static list of resolvers. How about leaving the list of resolvers to the resolv sketch as a static list; then writing a new sketch based on this pull request specifically for testing resolvers: ping, custom command, resolve a specific domain... I think that would be useful and could be used for composition, reporting, and other places (e.g. in Enterprise you could do a report on all the resolvers that are not responding and look for patterns by colo or OS or whatever).