nested CNAMEs resolution failures?
pgnet.dev at gmail.com
Mon Jan 29 15:21:07 UTC 2018
On 1/29/18 7:08 AM, Tony Finch wrote:
> PGNet Dev <pgnet.dev at gmail.com> wrote:
>> Can these response timeouts be accommodated directly in the script? Or
>> only by, perhaps, increasing the global query timeouts from default 10
> Yes, there's a bootstrapping problem here ... possibly the easiest way to
> avoid depending on a server that sends cookies when reconfiguring it not
> to send cookies, is to point the script at 18.104.22.168. In my setup the script
> runs in a dev environment generating a static file that is deployed to
> production, but it's effectively the same trick of making the script use a
> different DNS server.
Pointing @goog NS is easy enough to manage, and it takes care of the problem for the ns.irs.gov servers. Thx!
I added the 'caixin' servers -- not that I knowingly use them, just to test here -- and even querying @22.214.171.124, they timeout
Jan 29 07:15:38 ns003 named: 29-Jan-2018 07:15:38.591 client: error: query client=0x7f626c0bfc30 thread=0x7f62741b7700 (ns0.caixin.com/A): query_gotanswer: unexpected error: timed out
Jan 29 07:15:48 ns003 named: 29-Jan-2018 07:15:48.931 client: error: query client=0x7f626c03d5a0 thread=0x7f62741b7700 (ns10.caixin.com/A): query_gotanswer: unexpected error: timed out
Jan 29 07:15:59 ns003 named: 29-Jan-2018 07:15:59.286 client: error: query client=0x7f626cae54c0 thread=0x7f62741b7700 (ns20.caixin.com/A): query_gotanswer: unexpected error: timed out
No such problems in either case with qwest or barclays servers ...
More information about the bind-users