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. >> >> >> >
