Date: Mon, 17 Nov 2014 02:38:21 +0000 From: Jamie Landeg-Jones <jamie@dyslexicfish.net> To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Potential security issues with new top level domains? Message-ID: <201411170238.sAH2cLXQ062439@dyslexicfish.net>
next in thread | raw e-mail | index | archive | help
As if I needed another reason to hate the new top level domain free-for-all, I was checking on one of my machines earlier, and forgot that I'd renamed it, so it is no longer in my domains DNS. This was the result: | 2:13 (2) "~" jamie@catflap% ping android | PING android (127.0.53.53): 56 data bytes | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ^C | --- android ping statistics --- | 3 packets transmitted, 0 packets received, 100.0% packet loss | | 2:13 (3) "~" jamie@catflap% cat /etc/resolv.conf | domain dyslexicfish.net | nameserver 127.0.0.1 | options edns0 A quick check revealed that, as expected, unbound was first asked for 'android.dyslexicfish.net.' which returned NX, and was then asked for 'android.' which resolved the 'A' that the owners of the TLD have configured. Now, any scripts/binaries etc. I have that use DNS resolution always use the FQDN with the trailing dot, so I have no personal security worries, but I'm sure there are others out there that don't, and even so, it could still bite for interactive use. Yes, the 'A' returned is invalid in this case, but what's to say this will be the case with all future new TLDs? I realise the spec is being followed correctly, but it still seems wrong to me that any 'host' related resource types resolve for an address at the top level, and I was wondering what others thought about it? Should the FreeBSD resolver ignore / not make such requests? Should instead the functionality be built into unbound/named etc.? Should instead TLD owners be banned from adding such records? (this still could be abused though) Should neither be done? I dunno, I'm just used to A/AAAA resolves on a non qualified address to either come from /etc/hosts, or be in under a domain in 'domain/search' from /etc/resolv.conf The current situation seems 'wrong' and potentially troublesome to me, but I'd be interested in what others think. Cheers, Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201411170238.sAH2cLXQ062439>