I noticed that google / gmail has started rejecting all mail coming from my machine because of the lack of reverse DNS on the client endpoint IP of the tunnel.
I've worked around this by completely disabling ipv6 in my email server, but that's an unfortunate solution.
I realize that there may be concerns around granting reverse DNS on the tunnel endpoints. What about providing forward and reverse dns for the client endpoint if and only if there are matching forward and reverse dns entries on the ipv4 tunnel endpoint?
There should be rDNS on the client and server IPv6 endpoints. It's just not delegated.
Hmm ... so there is, my mistake. This just begs the question, what's going on with gmail. Perhaps it wants those DNS entries to match the HELO my machine is sending. Or perhaps it's getting angry about SPF records and simply sending back a confusing error message.
[Edit] Indeed, adding an a:my-tunnel-client-hostname entry to my spf records fixed the problem.
What Google is doing with gmail and rdns is nothing new. Many other servers have been doing that for years. reverse DNS for mail servers practically became a necessity about 2004-5. Anyone with a hosting arrangement that doesn't permit setting the reverse values needs a new arrangement, and others shouldn't be hosting an outbound mail server (but should probably be using their ISP's server(s) as a relay).
https://support.google.com/mail/answer/81126
Hi, I am having the same issue with gmail so I have requested delegation on my tunnel page to point to my nameservers. When I query the nameservers directly I get the expected response, but when I query via an internet nameserver like 8.8.8.8 or 4.2.2.1, etc. I get no resolution. What am I missing here?
nslookup 2001:470:e8de:2000::113 ns1.slash128.com
Server: ns1.slash128.com
Address: 173.10.105.194#53
3.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.e.d.8.e.0.7.4.0.1.0.0.2.ip6.arpa name = ex1.slash128.com.
nslookup 2001:470:e8de:2000::113 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find 3.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.e.d.8.e.0.7.4.0.1.0.0.2.ip6.arpa: NXDOMAIN
Ok, so delegation does not seem to have taken place, even though I put it in a few days ago. I will send tunnelbroker support an email.
dig -x 2001:470:e8de:2000::113 +trace
; <<>> DiG 9.8.3-P1 <<>> -x 2001:470:e8de:2000::113 +trace
;; global options: +cmd
. 10806 IN NS a.root-servers.net.
. 10806 IN NS b.root-servers.net.
. 10806 IN NS c.root-servers.net.
. 10806 IN NS d.root-servers.net.
. 10806 IN NS e.root-servers.net.
. 10806 IN NS f.root-servers.net.
. 10806 IN NS g.root-servers.net.
. 10806 IN NS h.root-servers.net.
. 10806 IN NS i.root-servers.net.
. 10806 IN NS j.root-servers.net.
. 10806 IN NS k.root-servers.net.
. 10806 IN NS l.root-servers.net.
. 10806 IN NS m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 49 ms
ip6.arpa. 172800 IN NS a.ip6-servers.arpa.
ip6.arpa. 172800 IN NS b.ip6-servers.arpa.
ip6.arpa. 172800 IN NS c.ip6-servers.arpa.
ip6.arpa. 172800 IN NS d.ip6-servers.arpa.
ip6.arpa. 172800 IN NS e.ip6-servers.arpa.
ip6.arpa. 172800 IN NS f.ip6-servers.arpa.
;; Received 462 bytes from 192.203.230.10#53(192.203.230.10) in 33 ms
4.0.1.0.0.2.ip6.arpa. 86400 IN NS u.arin.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS v.arin.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS w.arin.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS x.arin.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS z.arin.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS ns2.lacnic.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS sec1.apnic.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS sec1.authdns.ripe.net.
4.0.1.0.0.2.ip6.arpa. 86400 IN NS sec3.apnic.net.
;; Received 279 bytes from 196.216.169.11#53(196.216.169.11) in 371 ms
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS NS1.HE.NET.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS NS2.HE.NET.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS NS4.HE.NET.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS NS3.HE.NET.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS NS5.HE.NET.
;; Received 186 bytes from 199.212.0.63#53(199.212.0.63) in 91 ms
e.d.8.e.0.7.4.0.1.0.0.2.ip6.arpa. 86400 IN SOA ns1.he.net. hostmaster.he.net. 2010122202 10800 1800 604800 86400
;; Received 147 bytes from 216.66.1.2#53(216.66.1.2) in 98 ms
I don't see that record in your zone file on our side.
Maybe you meant to enter that as a slave zone?
Thanks for the assist. I was trying to delegate from my tunnel page and was not aware I needed to create a slave on dns.he.net. Fixed now and working, thanks!