Using google public dns should be fine.
Removed yahoo in colo resolver, 67.195.2.197 which is accessible from hosted
apache nodes. DHCPD configs is also updated to issue revolvers as
8.8.8.8/8.8.4.4 .
-rajive
From: Andrew Bayer <andrew.ba...@gmail.com>
To: "builds@apache.org" <builds@apache.org>
Cc: Keith W <keith.w...@gmail.com>; Rajiv Chittajallu <raj...@yahoo-inc.com>
Sent: Thursday, August 20, 2015 10:23 AM
Subject: Re: Name resolution issue on ubuntu jenkins slaves?
FYI, I've manually overwritten /etc/resolv.conf on all the H* and ubuntu-*
slaves with something more valid.
A.
On Thu, Aug 20, 2015 at 1:16 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote:
Yup,
http://drewgraybeal.blogspot.com/2015/05/level-3-dns-hijacking-4222-and-others.html
- level3 is hijacking NXDOMAIN now. I think Y!'s DHCP is setting those DNS
servers? Rajiv, can you comment?
A.
On Thu, Aug 20, 2015 at 10:32 AM, Andrew Bayer <andrew.ba...@gmail.com> wrote:
So the Yahoo! provided slaves (H*, ubuntu-*) do have Level3's DNS servers in
/etc/resolv.conf - we don't actually control that directly, it's part of the
system setup Y! uses, I think. I'll ping our contact at Y! about changing them
to use more standard DNS.
A.
On Thu, Aug 20, 2015 at 6:15 AM, Gavin McDonald <gmcdon...@apache.org> wrote:
> On 20 Aug 2015, at 4:03 am, David Nalley <da...@gnsa.us> wrote:
>
> Whatever we are using for DNS on those build slaves is redirecting any
> NXDOMAIN to a Level3 search domain.
>
> Is this happening on the ubuntu-* slaves or on the dynamic build slaves?
It was mentioned earlier :
> I am certainly seeing this on slaves ubuntu4
> through ubuntu6.
I have seen passes and failures on the dynamic slaves too, so seems
inconsistent.
Gav…
>
> --David
>
> On Mon, Aug 10, 2015 at 8:59 AM, Keith W <keith.w...@gmail.com> wrote:
>> Hello Apache builds,
>>
>> We (Apache Qpid) have been seeing a test fail on the Ubuntu Jenkins slaves
>> since August 9th. The test verifies the behaviour of the code when the
>> user specifies a hostname that does not exist in DNS. For this purpose,
>> the test uses a random name 'hg3sgaaw4lgihjs' (without hierarchal part)
>> which is assumed not resolve. This test is longstanding and has been
>> running on the slaves for many years without issue.
>>
>> Between August 9th and 10th, something appears to have changed on the
>> slaves, which is meaning that the lookup of the name is now returning an
>> IP. This is causing the Java test to fail. I've investigated by
>> introducing shell commands into the job, and can see evidence of the same
>> problem at the UNIX level. I am certainly seeing this on slaves ubuntu4
>> through ubuntu6.
>>
>>
>> $ host hg3sgaaw4lgihjs
>> hg3sgaaw4lgihjs has address 198.105.244.11
>> hg3sgaaw4lgihjs has address 198.105.254.11
>> Host hg3sgaaw4lgihjs not found: 3(NXDOMAIN)
>>
>> $ host hg3sgaaw4lgihjs2
>> hg3sgaaw4lgihjs2 has address 198.105.244.11
>> hg3sgaaw4lgihjs2 has address 198.105.254.11
>> Host hg3sgaaw4lgihjs2 not found: 3(NXDOMAIN)
>>
>>
>> I considered changing the test to use a RFC-2606 Reserved Top Level DNS
>> Names hg3sgaaw4lgihjs.invalid but I notice that it too is resolving to
>> 198.105.244.11 too. The fact that an .invalid address is resolving makes
>> me suspect there is an environmental problem at the root cause.
>>
>> host hg3sgaaw4lgihjs.invalid
>> hg3sgaaw4lgihjs.invalid has address 198.105.244.11
>> hg3sgaaw4lgihjs.invalid has address 198.105.254.11
>> Host hg3sgaaw4lgihjs.invalid not found: 3(NXDOMAIN)
>>
>> Is there a name resolution issue affecting these hosts?
>>
>> Example job affected by the issue:
>>
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-Test-JDK1.8/
>>
>> Kind regards, Keith Wall.
