Hurricane Electric's IPv6 Tunnel Broker Forums

IPv6 Certification Program Topics => General Discussion => Topic started by: jawbreaker on October 14, 2015, 01:36:23 PM

Title: Stuck on Admin Cert
Post by: jawbreaker on October 14, 2015, 01:36:23 PM
I'm stuck on the Admin Cert. It started off saying "connection refused", but now I'm getting "unable to find MX". I've obviously borked something in my DNS trying to make sure the test was hitting the correct server.

my.net        A 300 - 16.18.17.10
mail.my.net A 300 - 16.18.17.10
mail6.my.net AAAA 300 - 2001:x:x:x:x:x:x:x
mail.my.net MX 300 20 my.net
mail6.my.net MX 300 10 my.net


This is currently working fine for IPv4. I am able to send\recv email. So what am I doing wrong?
Title: Re: Stuck on Admin Cert
Post by: cholzhauer on October 14, 2015, 01:47:06 PM
Domain is my.net?


$ drill mx my.net
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 32795
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;; my.net.      IN      MX

;; ANSWER SECTION:
my.net. 3599    IN      MX      0 mail.nickstel.com.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
mail.nickstel.com.      59      IN      A       107.20.212.168



No IPv6 address
Title: Re: Stuck on Admin Cert
Post by: jawbreaker on October 14, 2015, 02:00:48 PM
No. I changed that for the example. Here is the real output...


[jeff@wyvern:~]
[15:58:08]$> drill mx cerberus.network
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48646
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; cerberus.network.    IN      MX

;; ANSWER SECTION:

;; AUTHORITY SECTION:
cerberus.network.       86400   IN      SOA     ns1.he.net. hostmaster.he.net. 2015101422 10800 1800 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 35 msec
;; SERVER: 10.0.0.31
;; WHEN: Wed Oct 14 15:58:18 2015
;; MSG SIZE  rcvd: 91
Title: Re: Stuck on Admin Cert
Post by: cholzhauer on October 14, 2015, 02:02:46 PM
I get the same result as you; there's no answer to your query, so HE can't query your email server
Title: Re: Stuck on Admin Cert
Post by: jawbreaker on October 14, 2015, 03:56:39 PM
If I run drill against mail.cerberus.network, I do have an answer section. Does that mean I need to swap the values for the MX record? v4 is working fine the way it is.
Title: Re: Stuck on Admin Cert
Post by: cholzhauer on October 14, 2015, 04:12:25 PM
What domain did you give HE in the tests?
Title: Re: Stuck on Admin Cert
Post by: kcochran on October 14, 2015, 05:12:22 PM
Quote from: jawbreaker on October 14, 2015, 03:56:39 PM
If I run drill against mail.cerberus.network, I do have an answer section. Does that mean I need to swap the values for the MX record? v4 is working fine the way it is.

The MX record should be on the hostname you're testing against, and the one expected to receive email.  It'll work generally, as when no MX records are defined, the hostname is documented to be used as a fallback with MX priority 0.  We do not attempt that fallback for this test.  Having an MX is more efficient than relying on the fallback behavior, as having a defined MX means a single DNS query, versus potentially 3 (MX, fail, then an A and AAAA query).  It also makes a clear indication that the domain does mail service.
Title: Re: Stuck on Admin Cert
Post by: jawbreaker on October 14, 2015, 07:44:12 PM
Thanks guys, I got it now.

cerberus.network  MX 300 20 mail.cerberus.network
cerberus.network  MX 300 10 mail6.cerberus.network


Have I gotten the priority bit right, 10 for v6 and 20 for v4, to make IPv6 the default?
Title: Re: Stuck on Admin Cert
Post by: kcochran on October 14, 2015, 08:11:23 PM
Yes, that would cause the v6 host to be tried first.  MX priority is a little weird in that usually you would think higher priority wins.  This is why some have taken to calling it "distance" since then it's that the shorter distance wins.

That said, if you had one record, with both a v4 and v6 address, you'd see roughly the same effect.  RFC6724 defines a priority order for client systems to try addresses when multiple are available.  In the general case, it causes IPv6 addresses to be tried before IPv4 (except for addresses involved with deprecated transition technologies such as 6to4, unless the other side is also 6to4, etc., etc.).