This happens all the time. Bang head against problem, give up and ask for
help, figure it out thirty minutes later.
The DNS cache on the Windows DNS servers needed to be cleared. Windows, sheesh.
Thanks anyway,
Rick
-Original Message-
From: Reineman, Rick
Sent: Monday, January 29, 20
I recently migrated our internal DNS service to a newer OS and Bind. Bind
9.9.4 on CentOS7. I am a third level zone off the corporate zone, eng.idt.com
(Engineering)
In general things are working pretty well but I have one really odd problem
that I am struggling with.
Our Windows desktops ar
There really aren’t a lot of servers that return a bad enough answer to warrant
turning off cookies globally. After years of using cookies I have ~20 servers
listed in named.conf.
Most of the erroneous responses are benign. FORMERR and BADVERS are a nonissue
unless the zone is signed. Echoing
Matus UHLAR - fantomas wrote:
> On 29.01.18 15:08, Tony Finch wrote:
> > 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 8.8.8.8. In my setup the sc
PGNet Dev wrote:
Can these response timeouts be accommodated directly in the script? Or
only by, perhaps, increasing the global query timeouts from default 10
sec?
On 29.01.18 15:08, Tony Finch wrote:
Yes, there's a bootstrapping problem here ... possibly the easiest way to
avoid depending o
On 1/29/18 7:08 AM, Tony Finch wrote:
> PGNet Dev wrote:
>>
>> Can these response timeouts be accommodated directly in the script? Or
>> only by, perhaps, increasing the global query timeouts from default 10
>> sec?
>
> Yes, there's a bootstrapping problem here ... possibly the easiest way to
>
PGNet Dev wrote:
>
> Can these response timeouts be accommodated directly in the script? Or
> only by, perhaps, increasing the global query timeouts from default 10
> sec?
Yes, there's a bootstrapping problem here ... possibly the easiest way to
avoid depending on a server that sends cookies whe
On 1/29/18 6:03 AM, Tony Finch wrote:
> Use the script I posted the other day:
> https://lists.isc.org/pipermail/bind-users/2018-January/099481.html
> except amended like this
In a recent post, I bumped into a similar problem with ns[1234].irs.gov
The "no-cookie" solution fixes the problem.
Fou
Cardenas, John wrote:
> I there anything I can do or change to make this resolve or do I just
> pass on that it is a DNS cookie problem, sorry folks?
Use the script I posted the other day:
https://lists.isc.org/pipermail/bind-users/2018-January/099481.html
except amended like this
http://paste.d
Load balancer that punts the answer to the backing server which doesn’t have
zone content that is consistent with what is being served by the front end. In
this case the CNAME record is missing from the backing server.
--
Mark Andrews
> On 29 Jan 2018, at 23:42, Tony Finch wrote:
>
> carde
carde...@sig.com wrote:
> Can someone help me understand why I cannot resolve file.caixin.com, but
> if I direct my queries to open resolvers from the likes of
> Google/Verizon they yield positive results?
Good grief, another DNS cookie problem. Weirdly their servers seem to cope
OK with cookies
I have BIND 9.11.2 caching-only servers. So it is plain vanilla no
authoritative zones configuration and resolv.conf points to locahost address.
Can someone help me understand why I cannot resolve file.caixin.com, but if I
direct my queries to open resolvers from the likes of Google/Verizon th
The DNS-OARC reply size tester doesn't work with versions of BIND that
are 9.10 and newer. This is because of the new probing process that we
implemented that should be more resilient. But it does unfortunately
'break' getting sane results from the DNS-OARC reply size tester.
https://www.dns-oar
13 matches
Mail list logo
