Can't get to Professional level

[lauj]

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

[cholzhauer]

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?

[lauj]

I have only just rebooted and hence the short downtime.

$TTL 3600

                        2009111600 ; serial
                        1200       ; refresh
                        60         ; retry
                        1209600    ; expire
                        3600       ; minimum

[jimb]

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.

[lauj]

I have already done it many times today already and the information just won't get cached in HE's nameservers.

[jimb]

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.

[lauj]

E-mail just sent.

[lauj]

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.)

[kcochran]

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.

[lauj]

DOH!!!

That means I am going to be spending some time changing that prefix.

[jimb]

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.

[kcochran]

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.  ;-)

[lauj]

All fixed now.

I will now need to contact my domain registrar to put AAAA glue records on.

[lauj]

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.

[jimb]

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.