Bug #109485 for Net-DNS: "Controlled interruption" by ICANN breaks search() function in Net::DNS::Resolver::Base

Hi, when searching (Net::DNS::Resolver::Base::search()) for a non qualified hostname (ie. 'seven') I got 127.0.53.53 although I set the right search domain (@searchlist in a Net::DNS::Resolver object). Turns out ICANN changed the standard behaviour of DNS and calls it controlled interruption to mitigate the danger of collisions of gTLDs and local TLDs. The idea of ICANN is that with all the new gTLDs like .lol, .sex, .seven, ... there is a chance that an organisation set up one of those as a local TLD internally before it was a global top level domain. To mitigate the danger of collisions it set the following replies for DNS Servers/Resolvers if someone does a query: A-Record: 127.0.53.53 MX-Record: your-dns-needs-immediate-attention.$NAME TXT-Record: Your DNS configuration needs immediate attention see https://icann.org/namecollision ICANN defined these "answers" for A, MX and TXT but I do not know why they did not do this for AAAA ... they are somehow inconsistent. In detail: When supplying a name like 'seven' which is (for the sake of argument) an existing hostname in your organisation and your organisation has registered 'compu-global-hyper-mega.net' and set up the subdomain 'workstation.compu-global-hyper-mega.net' the FQDN 'seven.workstation.compu-global-hyper-mega.net' is set up in DNS with an A and an AAAA record the Net::DNS::Resolver::search() function as it is will (in it's first query / udp packet to the DNS server / in it's first iteration) ask for 'seven'. The DNS Server/Resolver will then dutifully reply 127.0.53.53 when asking for the A record because it follows the specifications set by ICANN. It of course cannot differentiate between 'seven' as a simple non-qualified hostname and the TLD .seven when Net::DNS sends a query ("$self->send( $fqname, @_ );") to the server. Also because 127.0.53.53 is a completely valid A-record Net::DNS::Resolver::Base::search() will of course accept it as a valid answer. The ISC (Internet Systems Consortium) mitigated this in their host lookup utility (that comes with BIND) by first evaluating the search list. So the first query that goes out when using the host utility (you can find on any modern or ancient UNIX-like operating system like Solaris, Mac OS X, GNU/Linux by typing in `host`) goes to 'seven.workstation.compu-global-hyper-mega.net' instead of just 'seven'. I do not know if that was intentionally or they (the ISC) fixed it after ICANN did this. But it works out perfect. :-) Patch solving the problem: In my patch (attached to this email) I go through all answers and check for the relevant "errors" defined by ICANN in A, MX and TXT records. My environment: Distribution name and version: --> Net-DNS-1.03.tar.gz Perl version: --> `perl -v | head -n 2 | tail -n 1`: This is perl 5, version 22, subversion 0 (v5.22.0) built for x86_64-linux-thread-multi Operating System vendor and version: --> Linux MyHostname 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux Best regards, Andreas -- Andreas Boesen, BelWü-Koordination, Universität Stuttgart Industriestr. 28, 70565 Stuttgart Tel. 0711/685-65750 - Fax 0711/6788363 boesen@belwue.de - http://www.belwue.de ~cd in and find out