dig has parameters to force cache bypass.
Daryl
----- Reply message ----- From: "Trevor Cordes" trevor@tecnopolis.ca To: "Robert Keizer" robert@keizer.ca Cc: "Continuation of Round Table discussion" roundtable@muug.mb.ca Subject: [RndTbl] programatically determine if DNS is down or blocked? Date: Wed, Apr 6, 2016 15:41
On 2016-04-06 Robert Keizer wrote:
Why don't you use dig+grep+sed in bash?
Ya, that's one of the ideas (dig). It looks like dig will differentiate between named down, vs blocked 53, vs simple invalid domain.
I'm trying to see if there are other ways also, perhaps ones that don't require a fork. And the dig will send out real queries to real servers, but I guess it will be tempered by the cache? I'll have to test what dig does in the different failure modes when a) resolving a domain that isn't cached vs b) resolving one that is cached. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
But obviously, no number of local parameters can dictate what happens to DNS resolving beyond your local infrastructure (LAN). Even if there were parameters that "suggest" behaviour to upstream servers, those servers could ignore that. I suspect that full zone file retrieval (or full zone file content retrieval) commands might be the only way to be sure that caching is bypassed.
Hartmut W Sager - Tel +1-204-339-8331, +1-204-515-1701, +1-204-515-1700, +1-810-471-4600, +1-909-361-6005
On 7 April 2016 at 07:51, wyatt@prairieturtle.ca wyatt@prairieturtle.ca wrote:
dig has parameters to force cache bypass.
Daryl
----- Reply message ----- From: "Trevor Cordes" trevor@tecnopolis.ca To: "Robert Keizer" robert@keizer.ca Cc: "Continuation of Round Table discussion" roundtable@muug.mb.ca Subject: [RndTbl] programatically determine if DNS is down or blocked? Date: Wed, Apr 6, 2016 15:41
On 2016-04-06 Robert Keizer wrote:
Why don't you use dig+grep+sed in bash?
Ya, that's one of the ideas (dig). It looks like dig will differentiate between named down, vs blocked 53, vs simple invalid domain.
I'm trying to see if there are other ways also, perhaps ones that don't require a fork. And the dig will send out real queries to real servers, but I guess it will be tempered by the cache? I'll have to test what dig does in the different failure modes when a) resolving a domain that isn't cached vs b) resolving one that is cached. _______________________________________________ Roundtable mailing listRoundtable@muug.mb.cahttp://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
Trevor, why don't you just pay $5/month for a VPS somewhere out on the 'net (in Canada, even!) with static IP addresses and use that as your central coordination point? If it's still just the principle of the thing, well, keep flogging away at it. -Adam
On 16-04-07 05:50 PM, Hartmut W Sager wrote:
But obviously, no number of local parameters can dictate what happens to DNS resolving beyond your local infrastructure (LAN). Even if there were parameters that "suggest" behaviour to upstream servers, those servers could ignore that. I suspect that full zone file retrieval (or full zone file content retrieval) commands might be the only way to be sure that caching is bypassed.
Hartmut W Sager - Tel +1-204-339-8331, +1-204-515-1701, +1-204-515-1700, +1-810-471-4600, +1-909-361-6005
On 7 April 2016 at 07:51, wyatt@prairieturtle.ca mailto:wyatt@prairieturtle.ca <wyatt@prairieturtle.ca mailto:wyatt@prairieturtle.ca> wrote:
dig has parameters to force cache bypass. Daryl ----- Reply message ----- From: "Trevor Cordes" <trevor@tecnopolis.ca <mailto:trevor@tecnopolis.ca>> To: "Robert Keizer" <robert@keizer.ca <mailto:robert@keizer.ca>> Cc: "Continuation of Round Table discussion" <roundtable@muug.mb.ca <mailto:roundtable@muug.mb.ca>> Subject: [RndTbl] programatically determine if DNS is down or blocked? Date: Wed, Apr 6, 2016 15:41 On 2016-04-06 Robert Keizer wrote: > Why don't you use dig+grep+sed in bash? Ya, that's one of the ideas (dig). It looks like dig will differentiate between named down, vs blocked 53, vs simple invalid domain. I'm trying to see if there are other ways also, perhaps ones that don't require a fork. And the dig will send out real queries to real servers, but I guess it will be tempered by the cache? I'll have to test what dig does in the different failure modes when a) resolving a domain that isn't cached vs b) resolving one that is cached. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca <mailto:Roundtable@muug.mb.ca> http://www.muug.mb.ca/mailman/listinfo/roundtable _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca <mailto:Roundtable@muug.mb.ca> http://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 2016-04-07 Adam Thompson wrote:
Trevor, why don't you just pay $5/month for a VPS somewhere out on the 'net (in Canada, even!) with static IP addresses and use that as your central coordination point? If it's still just the principle of the thing, well, keep flogging away at it.
This isn't that thing (and any other "things" I may have had are already on static IP). The issue here is the mitigation of a problem I had a couple of months ago where a Major US Hosting Provider I have an app on decided to block my DNS. App went completely mental and crashed nearly everything.
Investigating the code paths it is very clear I need to do some delicate things with the results of DNS queries. To do this reliably I need to know that DNS is working. That means if Hosting Provider blocks me, I want to stop doing delicate things. If my own named dies (now that I don't rely on said hosting provider's DNS server), I want to stop doing delicate things.
It's funny, but not much discussion of this out on the net... I guess no one else needs a reliable way to tell if DNS is "working". And if they do, they're coming up with proprietary solutions (as I am, it seems). Granted, the app in question is doing some stuff that not many others are doing...
I have some good ideas now, mostly just an aggregation of a bunch of mini tests I can run whenever a lookup fails. Then, if the tests fail (i.e. DNS is "down") I can just "pause" my app until situation is resolved. Add in some time-caching so as to not waste too many cycles on this, and voila, I should be able to better survive any of myriad possible DNS issues... In theory. I didn't want to code it myself, but looks like I'll have to.
On Thu, Apr 7, 2016 at 11:49 PM, Trevor Cordes trevor@tecnopolis.ca wrote:
On 2016-04-07 Adam Thompson wrote:
Trevor, why don't you just pay $5/month for a VPS somewhere out on the 'net (in Canada, even!) with static IP addresses and use that as your central coordination point? If it's still just the principle of the thing, well, keep flogging away at it.
This isn't that thing (and any other "things" I may have had are already on static IP). The issue here is the mitigation of a problem I had a couple of months ago where a Major US Hosting Provider I have an app on decided to block my DNS. App went completely mental and crashed nearly everything.
Investigating the code paths it is very clear I need to do some delicate things with the results of DNS queries. To do this reliably I need to know that DNS is working. That means if Hosting Provider blocks me, I want to stop doing delicate things. If my own named dies (now that I don't rely on said hosting provider's DNS server), I want to stop doing delicate things.
It's funny, but not much discussion of this out on the net... I guess no one else needs a reliable way to tell if DNS is "working". And if they do, they're coming up with proprietary solutions (as I am, it seems). Granted, the app in question is doing some stuff that not many others are doing...
I have some good ideas now, mostly just an aggregation of a bunch of mini tests I can run whenever a lookup fails. Then, if the tests fail (i.e. DNS is "down") I can just "pause" my app until situation is resolved. Add in some time-caching so as to not waste too many cycles on this, and voila, I should be able to better survive any of myriad possible DNS issues... In theory. I didn't want to code it myself, but looks like I'll have to.
Have you looked at running multiple recursive resolvers on your system and using a load balancer to always hit a live one? http://dnsdist.org/
Theo
On 2016-04-08 Theodore Baschak wrote:
Have you looked at running multiple recursive resolvers on your system and using a load balancer to always hit a live one? http://dnsdist.org/
That's an idea... it would take care of named crashing. But I still need more to ensure The Big Hosting Provider isn't blocking 53 UDP in/out of my box at their firewall, or that the whole world's DNS isn't down / DDoS'd (don't laugh, I've seen a few times where several root NS's were being DDoS'd).
Thanks for all the ideas guys!
-
Adam Thompson -
Hartmut W Sager -
Theodore Baschak -
Trevor Cordes -
wyatt＠prairieturtle.ca