Stanislav,
I don't think we should fix it on JDK level.
Workaround is obvious and actually recommended for production - install
one of cashing nameservers and lock resolv.conf to localhost.
-Dmitry
On 2015-05-04 18:38, Stanislav Baiduzhyi wrote:
> Hi All,
>
> We are facing an issue with DNS s
On 05/04/2015 05:38 PM, Stanislav Baiduzhyi wrote:
> We are facing an issue with DNS server caching on RHEL-based distros: after
> the update of resolv.conf java application cannot resolve the hosts any more.
>
> Reproducer is very simple:
> 1. Clean /etc/resolv.conf or connect to vpn and use vp
On May 5, 1:32pm, sbaid...@redhat.com (Stanislav Baiduzhyi) wrote:
-- Subject: Re: DNS resolution fails after resolv.conf update
| Hi Christos,
|
| On Monday 04 May 2015 21:16:40 Christos Zoulas wrote:
| > I don't think it is the job of the JDK to handle this. For example
| > many sy
On Monday 04 May 2015 22:26:26 Bernd Eckenfels wrote:
> not sure how I feel about the res_init(). Depending on the backends
> used this might be expensive. Especially since it wont be rate
> limited. The negative-ttl of 10s is for single records I thing. So at a
> minimum you should rate-limit res_
Hi Christos,
On Monday 04 May 2015 21:16:40 Christos Zoulas wrote:
> I don't think it is the job of the JDK to handle this. For example
> many systems (like NetBSD for example) work just fine without
> needing this, because their libc keeps track of resolv.conf changes.
Normally I would agree wit
On May 4, 5:38pm, sbaid...@redhat.com (Stanislav Baiduzhyi) wrote:
-- Subject: DNS resolution fails after resolv.conf update
| Hi All,
|
| We are facing an issue with DNS server caching on RHEL-based distros: after
| the update of resolv.conf java application cannot resolve the hosts any more.
Hello,
not sure how I feel about the res_init(). Depending on the backends
used this might be expensive. Especially since it wont be rate
limited. The negative-ttl of 10s is for single records I thing. So at a
minimum you should rate-limit res_init to the same negative-ttl time).
But another aspe