Dear Everybody
I have spent over a half a day trying to get to Professional level and all I have ever been getting is "Your MX does not appear to have working RDNS" non stop.
I have already created a reverse IPv6 DNS zone which already works on my server and updated my tunnel details to point to my RDNS server.
The domain that is concerned is je21.co.uk where I have complete control over DNS as it is glued to it via Nominet via IPv4.
dig mx je21.co.uk +short works which returns my mailserver name
dig aaaa (the mailserver name that was returned) +short returns the IPv6 address of my mailserver
dig -x (the IPv6 address of my mailserver returned) +short returns my mailserver name
I then repeated the above dig commands on other nameservers such as my ISP, OpenDNS and HE's caching server 2001:470:20::2 where only the first two come out right and the last one failing to resolve. HE's other nameservers ns1.he.net to ns5.he.net return no information about my domain whatsoever.
I then also opened an account up with afraid.org and put in all the relevant details for reverse IPv6.
dig -x (the IPv6 address of my mailserver returned) +short @ns1.afraid.org successfully resolves and the same goes for ns2.afraid.org, ns3.afraid.org and ns4.afraid.org.
I have tried absolutely everything all to no avail.
A quick way to do the task is to dig -x $(dig aaaa $(dig mx je21.co.uk +short) +short) +short @{nameserver} where nameserver is the nameserver you will test.
(I am sorry that I have not provided IP addresses here but it is because I am paranoid of bad bots harvesting such data to use for attempted attacks.)
Edit:
You could also do dig -x $(dig aaaa $(dig mx je21.co.uk +short) +short) +short @$(dig aaaa je21.co.uk +short) which is even quicker using my aaaa nameserver record returned.
I believe having already set up aaaa nameservers in my domain gets me to Guru in no time but I can't get to Professional first because of this annoying problem!!!
Regards
I am not able to resolve the IPv6 address of your mail server back to the name of your mail server, nor does HE know about it.
When I was working on my sage test, I had everything set up correctly, but the cert test just didn't agree. I ended up giving up for a week or so, came back and tried again without making any changes, and everything worked fine.
What is your TTL set to?
I have only just rebooted and hence the short downtime.
$TTL 3600
2009111600 ; serial
1200 ; refresh
60 ; retry
1209600 ; expire
3600 ; minimum
It appears that HE doesn't have the delegation set up for you. Try to re-do the RDNS delegation by doing the form again.
I have already done it many times today already and the information just won't get cached in HE's nameservers.
Quote from: lauj on November 15, 2009, 10:47:11 AM
I have already done it many times today already and the information just won't get cached in HE's nameservers.
Yeh it looks like the NS record just isn't making it into the HE NSes. Email ipv6@he.net.
E-mail just sent.
I've just had a reply saying that the point to point doesn't get delegated. Only ::1 and ::2 addresses are useable.
The routed /64 prefix is the zone which is fully available and delegated to my nameservers.
Don't fully understand what this is as I am still trying to learn IPv6.
I can say that none of my services are on ::1 and ::2 (DNS server, mailserver and webserver, etc.)
There are two /64s for each account initially.
The point-to-point /64, which is listed in the tunnel detail page as "Client IPv6 Address", and a second /64, listed as "Routed /64." The two will be similar, but off by one in the third section. For example, if your Client v6 is 2001:470:1f08:####::2, your routed /64 would be 2001:470:1f09:####::/64. The rDNS zone you included in your email was for the point-to-point /64, and not the routed one.
DOH!!!
That means I am going to be spending some time changing that prefix.
LOL. I actually was wondering if that might be the case. But there's no way for me to tell which one he was using without looking at his tunnel page. I should have asked.
Is the last octet of the 3rd quad for client network is always odd, and the routed /64 even (since they're assigned in pairs)? That'd be one way to tell quickly if that always holds true.
Also, I keep saying that HE should do something on the tunnel info page to highlight the differences between the two networks. This mixing up of client/routed networks has happened a more than a few times.
I've reorganized the tunnel detail page a little bit, adding section titles. I could bold the differing digits in the /64s, but if people don't catch the difference as it is now, not sure how much more useful bolding it would be.
I guess we could have a banner parade across the screen: "The /64s are different *elephant trumpets*" and the like, but I think that would be a bit overkill. ;-)
All fixed now.
I will now need to contact my domain registrar to put AAAA glue records on.
Quote from: jimb on November 15, 2009, 01:23:58 PM
LOL. I actually was wondering if that might be the case. But there's no way for me to tell which one he was using without looking at his tunnel page. I should have asked.
Is the last octet of the 3rd quad for client network is always odd, and the routed /64 even (since they're assigned in pairs)? That'd be one way to tell quickly if that always holds true.
Also, I keep saying that HE should do something on the tunnel info page to highlight the differences between the two networks. This mixing up of client/routed networks has happened a more than a few times.
I know this is a really stupid question but how did you get your badge to appear on your signature?
I have already tried editing my signature but it just displays HTML code.
Quote from: kcochran on November 15, 2009, 01:52:20 PM
I've reorganized the tunnel detail page a little bit, adding section titles. I could bold the differing digits in the /64s, but if people don't catch the difference as it is now, not sure how much more useful bolding it would be.
I guess we could have a banner parade across the screen: "The /64s are different *elephant trumpets*" and the like, but I think that would be a bit overkill. ;-)
I was thinking something more like making it a different color or something, or sectioning it off into a separate box ... something like that. Or perhaps just a little parenthesized red text under the client /64 or something saying don't use this for your IPv6 addresses or something similar.
The problem is that except for one digit, the addresses are identical, and that's can be hard to catch visually. It makes it easy to do things like cut and paste the wrong line and things like that.
EDIT: In fact, I admit that when I set up the tunnel, I somehow "visually filtered" the routeable /64 on that page as being a repeat of the 6in4 tunnel address, and presumed that we weren't assigned a routable network until we requested a /48. I just didn't look close enough at the headings, or examine the addresses close enough to see that they were actually different IPs.
EDIT2: Looking at the page, I see that they actually are in their own sections. Not sure if they were back when I set up my tunnel.
Quote from: lauj on November 15, 2009, 03:19:12 PM
Quote from: jimb on November 15, 2009, 01:23:58 PM
LOL. I actually was wondering if that might be the case. But there's no way for me to tell which one he was using without looking at his tunnel page. I should have asked.
Is the last octet of the 3rd quad for client network is always odd, and the routed /64 even (since they're assigned in pairs)? That'd be one way to tell quickly if that always holds true.
Also, I keep saying that HE should do something on the tunnel info page to highlight the differences between the two networks. This mixing up of client/routed networks has happened a more than a few times.
I know this is a really stupid question but how did you get your badge to appear on your signature?
I have already tried editing my signature but it just displays HTML code.
[url=http://ipv6.he.net/certification/scoresheet.php?pass_name=jimb][img]http://ipv6.he.net/certification/create_badge.php?pass_name=jimb&badge=3[/img][/url]You have to drill down a bit into the HTML code to see the proper URL for an img bbcode.
Quote from: jimb on November 15, 2009, 03:46:21 PM
EDIT: In fact, I admit that when I set up the tunnel, I somehow "visually filtered" the routeable /64 on that page as being a repeat of the 6in4 tunnel address, and presumed that we weren't assigned a routable network until we requested a /48. I just didn't look close enough at the headings, or examine the addresses close enough to see that they were actually different IPs.
EDIT2: Looking at the page, I see that they actually are in their own sections. Not sure if they were back when I set up my tunnel.
They had lines between each "section" in the past, but no section headers. I'm hoping the labeling will help distinguish that there's something more than a mass of potentially redundant values listed in various spots.
Quote from: kcochran on November 15, 2009, 03:57:40 PM
Quote from: jimb on November 15, 2009, 03:46:21 PM
EDIT: In fact, I admit that when I set up the tunnel, I somehow "visually filtered" the routeable /64 on that page as being a repeat of the 6in4 tunnel address, and presumed that we weren't assigned a routable network until we requested a /48. I just didn't look close enough at the headings, or examine the addresses close enough to see that they were actually different IPs.
EDIT2: Looking at the page, I see that they actually are in their own sections. Not sure if they were back when I set up my tunnel.
They had lines between each "section" in the past, but no section headers. I'm hoping the labeling will help distinguish that there's something more than a mass of potentially redundant values listed in various spots.
Ah I see. You may even want to make separate sections for the routed networks and rDNS. Maybe that'd also help.
I think the main reason people sometimes don't spot this is because we tend to look more at the ends of the addresses, and not at the 3rd quad, where the difference exists, to differentiate them. My tunnel address ends in "dc7::2/64", and my routed address ends in "dc7::/64". So I think I was focusing on the addresses, and presuming that the "dc7::2/64" was the host address, and the "dc7::/64" was simply a listing of the tunnel network address. Had I examined it more closely, I would have caught that the last byte of the 3rd quad was different. Or, if I had looked left a bit and payed closer attention to the headings, I would have caught it too. But for whatever reason, maybe 'cause I was in a rush, or because my mind was more focused on setting up the tunnel, I just "missed" the routed /64.
Anyway, there's a whole field of study and engineering dedicated to designing things like this called Human Factors Engineering (http://en.wikipedia.org/wiki/Human_factors_engineering). A friend of mine does this for a living. He tests, evaluates flight control systems for aircraft. They often completely redesign displays, controls, panels, etc, which seem completely logical and adequate to the task, but turn out not to work well in practice because of human psychology and senses. (e.g., "Human Factors") :)
And especially what is the difference between an 8 and a 9 mixed up with a load of other numbers which are the same? No wonder why I missed it.
I've bolded the entire third section, so maybe that'll help in the future.
Ah. I bet it will. It drew my eye right to it immediately. We'll see I guess. Hopefully we'll see a reduction in these config errors (there's been a bunch since I've been on here).
Quote from: kcochran on November 18, 2009, 05:03:29 PM
I've bolded the entire third section, so maybe that'll help in the future.
I have noticed that so hopefully there won't be any more of these config errors by others.
RE Reply #19: I was just about to suggest that. How about also underlining the digit that is different?