I fail this test with "Your MX does not appear to have working RDNS".
My test however works:
; <<>> DiG 9.3.5-P1 <<>> -x 2001:470:1f0b:2c4::100:1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27931
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.0.0.0.1.0.0.0.0.0.0.0.0.0.4.c.2.0.b.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.0.0.0.1.0.0.0.0.0.0.0.0.0.4.c.2.0.b.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 258813 IN PTR ipv6-mx.iip.lu.
;; AUTHORITY SECTION:
4.c.2.0.b.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 258813 IN NS b.ns.iip.lu.
4.c.2.0.b.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 258813 IN NS a.ns.iip.lu.
;; Query time: 1 msec
;; SERVER: 134.96.230.233#53(134.96.230.233)
;; WHEN: Wed Jun 24 04:51:15 2009
;; MSG SIZE rcvd: 153
Also the DIG PTR test fails. Why?
Summary of user's dig query
IPv6 Address: 2001:470:1f0b:2c4::100:1
Status: NOERROR
Reverse ip6.arpa:
1.0.0.0.0.0.1.0.0.0.0.0.0.0.0.0.4.c.2.0.b.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa.
Validating user's dig query
Result: Fail
Caching NS reloads cache every 6 hrs. Now it shows up correctly on the server
Ah ok.
Maybe for those tests it would be more meaningful not to ask the cache but the concerned nameserver directly.
Quote from: broquea on June 23, 2009, 09:33:39 PM
Caching NS reloads cache every 6 hrs. Now it shows up correctly on the server
Does that mean the cache ignores the TTL on returned RRs?
I set the forward TTL to an hour just in case I needed to change it (and I did) with a rDNS TTL to 5 minutes. Since the email test I've had to change the MX record to a different IP address so I could add the rDNS properly. Even with such a low TTL and the testing system having sent the email 2 hours ago it doesn't seem to be looking up the right information.
Should I just wait the 6 hours and see if it's fixed itself by then? I'm using the anycast resolver at 2001:470:20::2 to get see if that at least has the correct answers.
The test doesn't give much feedback on the failures either. It would be nice if it was a little more verbose on which hosts it was testing and where it failed. It would be very embarrassing if I still had it mis-configured at this point :P
You're using an IPv4 resolver. That should probably be mentioned in the test as I had set up an IPv6 only version.
Quote from: chawbreaker on July 08, 2009, 06:09:34 PM
You're using an IPv4 resolver. That should probably be mentioned in the test as I had set up an IPv6 only version.
Since at that point in the test there still need not be any IPv6 glue at the registrar, using IPv4 for DNS seems logical however.
WTF?
I've not setup my email server to receive on an IPv4 address!
This cert. stuff is all about IPv6!
My rDNS setup works fine for my IPv6 address, so why is the test failing?
The message is less than explanatory and not helpful at all.
I'm really glad this test was included. My tunnel's been up since Jan 3rd 2008, and I had not noticed that my routed /64 was not the point-to-point - no idea whether that changed at some point along the line, I swear at one point there was no distinction.
So, yeah, trying to set up reverse delegation for the point-to-point - not so successful. I have good hopes that once freedns.org is back up, I can correct and increment that third dword by one, and have working reverse DNS.
Oops?
Wondering whether the OP has a similar "oh dang that _is_ 1f07 after all, not 1f06" kind of issue.
Also got hit by the caching issue. Agree with previous posters that it would be useful to give more debugging output, and also possibly have the option of manually clearing the cache before retesting.
I"m having the same problem / error
Your MX does not appear to have working RDNS
c:\programs\dig>dig @ns1.he.net -x 2001:5c0:150c:7200::1
; <<>> DiG 9.3.2 <<>> @ns1.he.net -x 2001:5c0:150c:7200::1
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 696
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.7.c.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. IN PT
R
;; ANSWER SECTION:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.7.c.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. 86400
IN PTR theclements.info.
;; Query time: 150 msec
;; SERVER: 216.218.130.2#53(216.218.130.2)
;; WHEN: Sat Nov 06 16:25:09 2010
;; MSG SIZE rcvd: 120
Doesn't look delegated to ns1.he.net
~$ dig -x 2001:5c0:150c:7200::1 +trace
; <<>> DiG 9.7.0-P1 <<>> -x 2001:5c0:150c:7200::1 +trace
;; global options: +cmd
. 86114 IN NS f.root-servers.net.
. 86114 IN NS d.root-servers.net.
. 86114 IN NS i.root-servers.net.
. 86114 IN NS k.root-servers.net.
. 86114 IN NS l.root-servers.net.
. 86114 IN NS m.root-servers.net.
. 86114 IN NS c.root-servers.net.
. 86114 IN NS h.root-servers.net.
. 86114 IN NS e.root-servers.net.
. 86114 IN NS a.root-servers.net.
. 86114 IN NS b.root-servers.net.
. 86114 IN NS g.root-servers.net.
. 86114 IN NS j.root-servers.net.
;; Received 497 bytes from 74.82.42.42#53(74.82.42.42) in 1 ms
arpa. 172800 IN NS d.root-servers.net.
arpa. 172800 IN NS l.root-servers.net.
arpa. 172800 IN NS e.root-servers.net.
arpa. 172800 IN NS m.root-servers.net.
arpa. 172800 IN NS i.root-servers.net.
arpa. 172800 IN NS a.root-servers.net.
arpa. 172800 IN NS g.root-servers.net.
arpa. 172800 IN NS b.root-servers.net.
arpa. 172800 IN NS f.root-servers.net.
arpa. 172800 IN NS h.root-servers.net.
arpa. 172800 IN NS c.root-servers.net.
arpa. 172800 IN NS k.root-servers.net.
;; Received 510 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 3 ms
ip6.arpa. 172800 IN NS ns.icann.org.
ip6.arpa. 172800 IN NS ns2.lacnic.net.
ip6.arpa. 172800 IN NS sec1.apnic.net.
ip6.arpa. 172800 IN NS ns-sec.ripe.net.
ip6.arpa. 172800 IN NS tinnie.arin.net.
;; Received 229 bytes from 2001:500:1::803f:235#53(h.root-servers.net) in 76 ms
0.c.5.0.1.0.0.2.ip6.arpa. 10800 IN NS ns1.gogo6.com.
0.c.5.0.1.0.0.2.ip6.arpa. 10800 IN NS ns2.gogo6.com.
;; Received 135 bytes from 2001:dc0:2001:a:4608::59#53(sec1.apnic.net) in 175 ms
1.0.c.5.0.1.0.0.2.ip6.arpa. 1800 IN SOA ns1.gogo6.com. support.gogo6.com. 2012552141 10800 900 604800 86400
;; Received 147 bytes from 2001:5c0:1001::194#53(ns2.gogo6.com) in 83 ms
thanks, any tips how I delegate to he.net ? I'm at a complete loss at this point.
thanks for any help
Here is the result of my dig (specifying ns1.he.net)
c:\programs\dig>dig @ns1.he.net -x 2001:5c0:150c:7200::1
; <<>> DiG 9.3.2 <<>> @ns1.he.net -x 2001:5c0:150c:7200::1
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.7.c.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. IN PT
R
;; ANSWER SECTION:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.7.c.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. 86400
IN PTR theclements.info.
;; Query time: 150 msec
;; SERVER: 216.218.130.2#53(216.218.130.2)
;; WHEN: Sat Nov 06 17:34:02 2010
;; MSG SIZE rcvd: 120
c:\programs\dig>
Nothing wrong with your dig, it is just that we don't query ns1-5.he.net as they aren't caching recursors, only authoritative, so no machine on our network would ever use them for DNS lookups. You'll need to look at gogo6 and how they delegate rDNS for their allocations.
The gogoclient reverse dns configuration seems easy.
I just list the ns1.he.net:ns2.he.net:ns3.he.net:ns4.he.net in the field and it is supposed to delegate.
I can't find anything in the docs or web that talks about this.
Any advice ?
thanks
Tim
i'm giving up on the gogoclient. seems like its' just not working for delegating.
So, I'm switching to tunnelbroker but am having a problem getting it working also:
C:\Windows\system32>netsh interface ipv6 add v6v4tunnel IP6Tunnel 70.116.7.46 21
6.218.224.42
You were not connected because a duplicate name exists on the network. If joinin
g a domain, go to System in Control Panel to change the computer name and try ag
ain. If joining a workgroup, choose another workgroup name.
Any advice ?
figured it out
thanks