We were troubleshooting DNS for a customer who has the domains hosted over at DNS Exit over the last couple of days and couldn’t seem to nail down why we here at Rollernet couldn’t resolve their DNS reliably, if at all. After much extended testing, we eventually tested from a site that was IPv4 only and discovered this:
;; ADDITIONAL SECTION: ns1.dnsexit.com. 28800 IN A 69.57.160.118 ns1.dnsexit.com. 28800 IN AAAA ::1 ns2.dnsexit.com. 59400 IN A 64.182.102.188 ns2.dnsexit.com. 59400 IN AAAA ::1 ns3.dnsexit.com. 57600 IN A 67.214.175.73 ns3.dnsexit.com. 57600 IN AAAA ::1 ns4.dnsexit.com. 57600 IN A 67.214.161.154 ns4.dnsexit.com. 57600 IN AAAA ::1
There’s the problem: delegations to the IPv6 loopback address. This is not something we would ever expect to see. It can, in fact, be damaging because an IPv6 resolver may try to query itself (localhost). As such, we are strongly recommending to all of our customers (plus anyone in general who is interested in working with IPv6 or may use an IPv6 network) to stay clear of DNS Exit at this time.
We try not to recommend one provider over another, but in this instance the localhost AAAA delegations are too egregious of an error to ignore. As far as we are aware only DNS Exit does this, so any of their competitors should be a suitable replacement.
4 replies on “DNS Exit Breaks IPv6”
I did a quick dig through my IPv6 enabled resolver and got this awful answer:
;; AUTHORITY SECTION:
dnsexit.com. 26492 IN NS ns3.dnsexit.com.
dnsexit.com. 26492 IN NS ns2.dnsexit.com.
dnsexit.com. 26492 IN NS ns4.dnsexit.com.
dnsexit.com. 26492 IN NS ns1.dnsexit.com.
;; ADDITIONAL SECTION:
ns1.dnsexit.com. 26492 IN AAAA ::1
ns2.dnsexit.com. 57092 IN AAAA ::1
ns3.dnsexit.com. 55292 IN AAAA ::1
ns4.dnsexit.com. 55292 IN AAAA ::1
No IPv4 glue at all.
Two make matters worse, two out of four name servers failed to respond when using @ip.v4.add.ress with dig.
I just send them an e-mail about the AAAA records. It was fixed (removed) within 3 hours.
If you point out that something is broken, make sure you also inform the right people.
We tried contacting them before taking the public name-and-shame route, but either could not because of the problem (remember, we’re dual-stack, so is our mail) or were simply ignored. Either way we did not receive a direct response from them to address it and the problem persisted. Perhaps our messages never reached the “right people”, whomever they may be.
Ignorance and/or indifference is unfortunately far too common for IPv6 related issues from entities of all sizes.