Jamie Landeg-Jones
2014-Nov-17 02:38 UTC
Potential security issues with new top level domains?
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 at 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 at 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
On Nov 16, 2014, at 6:38 PM, Jamie Landeg-Jones <jamie at dyslexicfish.net> wrote:> Yes, the 'A' returned is invalid in this case, but what's to say this > will be the case with all future new TLDs?It will be the case for the first 90 days for all new TLDs that have three or more letters in their names; it will probably not be true for new TLDs with two letters in their name.> I realise the spec is being followed correctly,Yes.> 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?The spec is being followed correctly, and there are many other TLDs that do this: see <https://tools.ietf.org/html/rfc7085>.> 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)No, no, and no. As you say above, the spec is being followed. You can mitigate your misuse of the DNS: <https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf>. --Paul Hoffman (a long-time FreeBSDer who co-wrote the above RFC, and also wrote the ICANN report)