Looks like we are now not delegating. Sorry.
Will follow it up in the morning with a team member.
Some resolvers, ours included wont answer trace requests, its seen as cache snooping.
I would have to do a tcpdump an look but I suspect when dig does a +trace it is doing some queries without the RD flag set.
Could be what you are seeing with your trace attempts, could also be i haven't consumed nearly enough beer tonight and talking rubbish:)
Paul
From: nznog-bounces@list.waikato.ac.nz [nznog-bounces@list.waikato.ac.nz] on behalf of Jonathan Spence [jonathan.spence@power-business.co.nz]
Sent: Tuesday, 17 September 2013 11:47 p.m.
To: nznog@list.waikato.ac.nz
Subject: Re: [nznog] NZNOG Digest, Vol 129, Issue 1
Sent: Tuesday, 17 September 2013 11:47 p.m.
To: nznog@list.waikato.ac.nz
Subject: Re: [nznog] NZNOG Digest, Vol 129, Issue 1
Hi Paul,
Jonathan Spence
Chief Information Officer
Mobile: +64-21-1055634
Work: +64-9-9503306
Web: power-business.co.nz
From: nznog-request@list.waikato.ac.nz
Sent: Monday, September 2, 2013 12:00 PM
To: nznog@list.waikato.ac.nz
Subject: NZNOG Digest, Vol 129, Issue 1
Send NZNOG mailing list submissions to
nznog@list.waikato.ac.nz
To subscribe or unsubscribe via the World Wide Web, visit
http://list.waikato.ac.nz/mailman/listinfo/nznog
or, via email, send a message with subject or body 'help' to
nznog-request@list.waikato.ac.nz
You can reach the person managing the list at
nznog-owner@list.waikato.ac.nz
When replying, please edit your Subject line so it is more specific
than "Re: Contents of NZNOG digest..."
Today's Topics:
1. Orcon IPv6 rDNS delegation (Jonathan Spence)
2. Re: Orcon IPv6 rDNS delegation (Leo Vegoda)
3. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
4. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Sep 2013 02:08:47 +1200
From: "Jonathan Spence" <jonathan.spence@power-business.co.nz>
To: <nznog@list.waikato.ac.nz>
Subject: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <7d59cc8$6fc11687$642d0766$@xtracta.com>
Content-Type: text/plain; charset="us-ascii"
Hi everyone, Google have just started enforcing PTR records for IPv6
addresses delivering to Gmail. Our IPv6 works great with Orcon but having
serious issues getting delegation back to our nameservers setup. I have
been told a few times that everything is setup on their end but I don't
think it is.
Our IP space: 2400:4800:4017::/48 is meant to be sent to
ns1.power-business.co.nz and ns2.power-business.co.nz. However it doesn't
seem to. For example our website is:2400:4800:4017:200:250:56ff:fe90:82f
If I query ns1.power-business.co.nz from my home computer is works fine:
-----command-----
C:\Users\Jonathan Spence>nslookup 2400:4800:4017:0200:0250:56ff:fe90:082f
60.234.77.213 Server: UnKnown Address: 60.234.77.213
Name: midas.power-business.co.nz Address:
2400:4800:4017:200:250:56ff:fe90:82f
------ end command -----
However other hosts don't resolve this. When using this tool it doesn't
work failing when reaching Orcon's nameserver:
http://www.simpledns.com/lookup-dg.aspx
Can anyone comment?
Thanks, Jonathan
------- output -------
Received referral response - DNS servers for "0.4.2.ip6.arpa":
-> ns4.apnic.net (no IP address)
-> apnic1.dnsnode.net (no IP address)
-> ns3.apnic.net (no IP address)
-> tinnie.arin.net (no IP address)
-> ns2.lacnic.net (no IP address)
-> sec1.authdns.ripe.net (no IP address)
-> ns1.apnic.net (no IP address)
----------------------------------------
Attempting to resolve DNS server name "apnic1.dnsnode.net" (details not
logged)
----------------------------------------
Resolved DNS server name "apnic1.dnsnode.net" to IP address
194.146.106.106
----------------------------------------
Sending request to "apnic1.dnsnode.net" (194.146.106.106)
----------------------------------------
Received referral response - DNS servers for "0.0.8.4.0.0.4.2.ip6.arpa":
-> ns1.orcon.net.nz (no IP address)
-> ns2.orcon.net.nz (no IP address)
----------------------------------------
Attempting to resolve DNS server name "ns2.orcon.net.nz" (details not
logged)
----------------------------------------
Resolved DNS server name "ns2.orcon.net.nz" to IP address 210.55.12.2
----------------------------------------
Sending request to "ns2.orcon.net.nz" (210.55.12.2)
----------------------------------------
Received authoritative (AA) response:
-> Header: Non-Existent Domain
----- end output -----
Jonathan Spence
Chief Information Officer
Mobile: +64-21-1055634
Work: +64-9-9503306
Web: power-business.co.nz
The information contained in this message is privileged and intended only
for the recipient names. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message or
the information it contains is prohibited. Views expressed in this message
may notnecessarily be those of Power Business Services Limited. If you have
received this message in error, please immediately notify the sender, and
delete the original message and attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.waikato.ac.nz/pipermail/nznog/attachments/20130902/3844257f/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 1 Sep 2013 08:29:26 -0700
From: Leo Vegoda <leo.vegoda@icann.org>
To: "jonathan.spence@power-business.co.nz"
<jonathan.spence@power-business.co.nz>
Cc: "nznog@list.waikato.ac.nz" <nznog@list.waikato.ac.nz>
Subject: Re: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <B7C861B6-983E-4A7B-9E02-CCFA6A302162@icann.org>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
On 1 Sep 2013, at 07:08, Jonathan Spence <jonathan.spence@power-business.co.nz> wrote:
> Hi everyone,
> Google have just started enforcing PTR records for IPv6 addresses delivering to Gmail. Our IPv6 works great with Orcon but having serious issues getting delegation back to our nameservers setup. I have been told a few times that everything is setup on their end but I don't think it is.
>
> Our IP space: 2400:4800:4017::/48 is meant to be sent to ns1.power-business.co.nz and ns2.power-business.co.nz. However it doesn't seem to.
The reverse domain for 2400:4800:4017::/48 is 7.1.0.4.0.0.8.4.0.0.4.2.ip6.arpa. Your supposition is correct and ns1.orcon.net.nz does not seem to have delegated the domain to your nameservers.
Regards,
Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
URL: <http://list.waikato.ac.nz/pipermail/nznog/attachments/20130901/6d99404e/attachment-0001.bin>
------------------------------
Message: 3
Date: Sun, 1 Sep 2013 19:47:05 +0000
From: Paul Tinson <Paul.Tinson@team.orcon.net.nz>
To: "nznog@list.waikato.ac.nz" <nznog@list.waikato.ac.nz>
Subject: Re: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <kmvggkxrqhsrvq9ml6ddt4ml.1378064823925@email.android.com>
Content-Type: text/plain; charset="iso-8859-1"
I will take a look when I get to the office.
Sadly IPv6 records are manual at the moment, and its entirely possible its a typo.
Paul
Leo Vegoda <leo.vegoda@icann.org> wrote:
Hi,
On 1 Sep 2013, at 07:08, Jonathan Spence <jonathan.spence@power-business.co.nz> wrote:
> Hi everyone,
> Google have just started enforcing PTR records for IPv6 addresses delivering to Gmail. Our IPv6 works great with Orcon but having serious issues getting delegation back to our nameservers setup. I have been told a few times that everything is setup on their end but I don't think it is.
>
> Our IP space: 2400:4800:4017::/48 is meant to be sent to ns1.power-business.co.nz and ns2.power-business.co.nz. However it doesn't seem to.
The reverse domain for 2400:4800:4017::/48 is 7.1.0.4.0.0.8.4.0.0.4.2.ip6.arpa. Your supposition is correct and ns1.orcon.net.nz does not seem to have delegated the domain to your nameservers.
Regards,
Leo
------------------------------
Message: 4
Date: Sun, 1 Sep 2013 21:59:44 +0000
From: Paul Tinson <Paul.Tinson@team.orcon.net.nz>
To: "nznog@list.waikato.ac.nz" <nznog@list.waikato.ac.nz>
Subject: Re: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <89CA63C1-BED3-4DF4-8E27-A27B0ABB9F5D@team.orcon.net.nz>
Content-Type: text/plain; charset="us-ascii"
OK we have had a good look into this and you have an issue you need to resolve.
A trace of your name servers shows this:
; <<>> DiG 9.3.4 <<>> +trace ns1.power-business.co.nz<http://ns1.power-business.co.nz>
;; global options: printcmd
. 19071 IN NS j.root-servers.net<http://j.root-servers.net>.
. 19071 IN NS m.root-servers.net<http://m.root-servers.net>.
. 19071 IN NS e.root-servers.net<http://e.root-servers.net>.
. 19071 IN NS i.root-servers.net<http://i.root-servers.net>.
. 19071 IN NS c.root-servers.net<http://c.root-servers.net>.
. 19071 IN NS l.root-servers.net<http://l.root-servers.net>.
. 19071 IN NS h.root-servers.net<http://h.root-servers.net>.
. 19071 IN NS d.root-servers.net<http://d.root-servers.net>.
. 19071 IN NS k.root-servers.net<http://k.root-servers.net>.
. 19071 IN NS g.root-servers.net<http://g.root-servers.net>.
. 19071 IN NS b.root-servers.net<http://b.root-servers.net>.
. 19071 IN NS f.root-servers.net<http://f.root-servers.net>.
. 19071 IN NS a.root-servers.net<http://a.root-servers.net>.
;; Received 512 bytes from 60.234.1.1#53(60.234.1.1) in 29 ms
nz. 172800 IN NS ns4.dns.net.nz<http://ns4.dns.net.nz>.
nz. 172800 IN NS ns6.dns.net.nz<http://ns6.dns.net.nz>.
nz. 172800 IN NS ns2.dns.net.nz<http://ns2.dns.net.nz>.
nz. 172800 IN NS ns5.dns.net.nz<http://ns5.dns.net.nz>.
nz. 172800 IN NS ns3.dns.net.nz<http://ns3.dns.net.nz>.
nz. 172800 IN NS ns1.dns.net.nz<http://ns1.dns.net.nz>.
nz. 172800 IN NS ns7.dns.net.nz<http://ns7.dns.net.nz>.
;; Received 428 bytes from 192.58.128.30#53(j.root-servers.net<http://j.root-servers.net>) in 13 ms
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns1.power-business.co.nz<http://ns1.power-business.co.nz>.
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns3.power-business.co.nz<http://ns3.power-business.co.nz>.
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns2.power-business.co.nz<http://ns2.power-business.co.nz>.
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns4.power-business.co.nz<http://ns4.power-business.co.nz>.
;; Received 230 bytes from 202.46.189.130#53(ns4.dns.net.nz<http://ns4.dns.net.nz>) in 0 ms
ns1.power-business.co.nz<http://ns1.power-business.co.nz>. 10800 IN CNAME bia.power-business.co.nz<http://bia.power-business.co.nz>.
bia.power-business.co.nz<http://bia.power-business.co.nz>. 10800 IN A 60.234.77.213
;; Received 76 bytes from 60.234.77.213#53(ns1.power-business.co.nz<http://ns1.power-business.co.nz>) in 1 ms
The CNAME is illegal, this means we dont follow it.
RFC2181 section 10.3: Copied below:
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed. In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.
Let me know if you need further assistance.
Paul
On 2/09/2013, at 7:47 AM, Paul Tinson <Paul.Tinson@team.orcon.net.nz<mailto:Paul.Tinson@team.orcon.net.nz>>
wrote:
I will take a look when I get to the office.
Sadly IPv6 records are manual at the moment, and its entirely possible its a typo.
Paul
Leo Vegoda <leo.vegoda@icann.org<mailto:leo.vegoda@icann.org>> wrote:
Hi,
On 1 Sep 2013, at 07:08, Jonathan Spence <jonathan.spence@power-business.co.nz<mailto:jonathan.spence@power-business.co.nz>> wrote:
Hi everyone,
Google have just started enforcing PTR records for IPv6 addresses delivering to Gmail. Our IPv6 works great with Orcon but having serious issues getting delegation back to our nameservers setup. I have been told a few times that everything is setup on their end but I don't think it is.
Our IP space: 2400:4800:4017::/48 is meant to be sent to ns1.power-business.co.nz<http://ns1.power-business.co.nz> and ns2.power-business.co.nz<http://ns2.power-business.co.nz>. However it doesn't seem to.
The reverse domain for 2400:4800:4017::/48 is 7.1.0.4.0.0.8.4.0.0.4.2.ip6.arpa. Your supposition is correct and ns1.orcon.net.nz<http://ns1.orcon.net.nz> does not seem to have delegated the domain to your nameservers.
Regards,
Leo
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz<mailto:NZNOG@list.waikato.ac.nz>
http://list.waikato.ac.nz/mailman/listinfo/nznog
--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------
Teach Email Guard if this mail (ID 09KjUC5mG) is spam:
Spam: https://emailguard.orcon.net.nz/canit/b.php?i=09KjUC5mG&m=ae916b2c1e4b&t=20130902&c=s
Not spam: https://emailguard.orcon.net.nz/canit/b.php?i=09KjUC5mG&m=ae916b2c1e4b&t=20130902&c=n
Forget vote: https://emailguard.orcon.net.nz/canit/b.php?i=09KjUC5mG&m=ae916b2c1e4b&t=20130902&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.waikato.ac.nz/pipermail/nznog/attachments/20130901/6fc86e67/attachment-0001.html>
------------------------------
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
End of NZNOG Digest, Vol 129, Issue 1
*************************************
Thanks for the assistance and pointing out a glaringly obvious problem :S.
NS records are all fixed but not seeing the delegation still. Should this happen now automatically or do Orcon still need to do something? I've now learnt how to use the Dig command but can't figure out how to trace it like in other posts.
Thanks,
Jonathan
Jonathan Spence
Chief Information Officer
Mobile: +64-21-1055634
Work: +64-9-9503306
Web: power-business.co.nz
The information contained in this message is privileged and intended only for the recipient names. If the reader is not a representative of the intended recipient, any
review, dissemination or copying of this message or the information it contains is prohibited.
Views expressed in this message may notnecessarily be those of Power Business Services Limited.
If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
From: nznog-request@list.waikato.ac.nz
Sent: Monday, September 2, 2013 12:00 PM
To: nznog@list.waikato.ac.nz
Subject: NZNOG Digest, Vol 129, Issue 1
Send NZNOG mailing list submissions to
nznog@list.waikato.ac.nz
To subscribe or unsubscribe via the World Wide Web, visit
http://list.waikato.ac.nz/mailman/listinfo/nznog
or, via email, send a message with subject or body 'help' to
nznog-request@list.waikato.ac.nz
You can reach the person managing the list at
nznog-owner@list.waikato.ac.nz
When replying, please edit your Subject line so it is more specific
than "Re: Contents of NZNOG digest..."
Today's Topics:
1. Orcon IPv6 rDNS delegation (Jonathan Spence)
2. Re: Orcon IPv6 rDNS delegation (Leo Vegoda)
3. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
4. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Sep 2013 02:08:47 +1200
From: "Jonathan Spence" <jonathan.spence@power-business.co.nz>
To: <nznog@list.waikato.ac.nz>
Subject: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <7d59cc8$6fc11687$642d0766$@xtracta.com>
Content-Type: text/plain; charset="us-ascii"
Hi everyone, Google have just started enforcing PTR records for IPv6
addresses delivering to Gmail. Our IPv6 works great with Orcon but having
serious issues getting delegation back to our nameservers setup. I have
been told a few times that everything is setup on their end but I don't
think it is.
Our IP space: 2400:4800:4017::/48 is meant to be sent to
ns1.power-business.co.nz and ns2.power-business.co.nz. However it doesn't
seem to. For example our website is:2400:4800:4017:200:250:56ff:fe90:82f
If I query ns1.power-business.co.nz from my home computer is works fine:
-----command-----
C:\Users\Jonathan Spence>nslookup 2400:4800:4017:0200:0250:56ff:fe90:082f
60.234.77.213 Server: UnKnown Address: 60.234.77.213
Name: midas.power-business.co.nz Address:
2400:4800:4017:200:250:56ff:fe90:82f
------ end command -----
However other hosts don't resolve this. When using this tool it doesn't
work failing when reaching Orcon's nameserver:
http://www.simpledns.com/lookup-dg.aspx
Can anyone comment?
Thanks, Jonathan
------- output -------
Received referral response - DNS servers for "0.4.2.ip6.arpa":
-> ns4.apnic.net (no IP address)
-> apnic1.dnsnode.net (no IP address)
-> ns3.apnic.net (no IP address)
-> tinnie.arin.net (no IP address)
-> ns2.lacnic.net (no IP address)
-> sec1.authdns.ripe.net (no IP address)
-> ns1.apnic.net (no IP address)
----------------------------------------
Attempting to resolve DNS server name "apnic1.dnsnode.net" (details not
logged)
----------------------------------------
Resolved DNS server name "apnic1.dnsnode.net" to IP address
194.146.106.106
----------------------------------------
Sending request to "apnic1.dnsnode.net" (194.146.106.106)
----------------------------------------
Received referral response - DNS servers for "0.0.8.4.0.0.4.2.ip6.arpa":
-> ns1.orcon.net.nz (no IP address)
-> ns2.orcon.net.nz (no IP address)
----------------------------------------
Attempting to resolve DNS server name "ns2.orcon.net.nz" (details not
logged)
----------------------------------------
Resolved DNS server name "ns2.orcon.net.nz" to IP address 210.55.12.2
----------------------------------------
Sending request to "ns2.orcon.net.nz" (210.55.12.2)
----------------------------------------
Received authoritative (AA) response:
-> Header: Non-Existent Domain
----- end output -----
Jonathan Spence
Chief Information Officer
Mobile: +64-21-1055634
Work: +64-9-9503306
Web: power-business.co.nz
The information contained in this message is privileged and intended only
for the recipient names. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message or
the information it contains is prohibited. Views expressed in this message
may notnecessarily be those of Power Business Services Limited. If you have
received this message in error, please immediately notify the sender, and
delete the original message and attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.waikato.ac.nz/pipermail/nznog/attachments/20130902/3844257f/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 1 Sep 2013 08:29:26 -0700
From: Leo Vegoda <leo.vegoda@icann.org>
To: "jonathan.spence@power-business.co.nz"
<jonathan.spence@power-business.co.nz>
Cc: "nznog@list.waikato.ac.nz" <nznog@list.waikato.ac.nz>
Subject: Re: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <B7C861B6-983E-4A7B-9E02-CCFA6A302162@icann.org>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
On 1 Sep 2013, at 07:08, Jonathan Spence <jonathan.spence@power-business.co.nz> wrote:
> Hi everyone,
> Google have just started enforcing PTR records for IPv6 addresses delivering to Gmail. Our IPv6 works great with Orcon but having serious issues getting delegation back to our nameservers setup. I have been told a few times that everything is setup on their end but I don't think it is.
>
> Our IP space: 2400:4800:4017::/48 is meant to be sent to ns1.power-business.co.nz and ns2.power-business.co.nz. However it doesn't seem to.
The reverse domain for 2400:4800:4017::/48 is 7.1.0.4.0.0.8.4.0.0.4.2.ip6.arpa. Your supposition is correct and ns1.orcon.net.nz does not seem to have delegated the domain to your nameservers.
Regards,
Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
URL: <http://list.waikato.ac.nz/pipermail/nznog/attachments/20130901/6d99404e/attachment-0001.bin>
------------------------------
Message: 3
Date: Sun, 1 Sep 2013 19:47:05 +0000
From: Paul Tinson <Paul.Tinson@team.orcon.net.nz>
To: "nznog@list.waikato.ac.nz" <nznog@list.waikato.ac.nz>
Subject: Re: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <kmvggkxrqhsrvq9ml6ddt4ml.1378064823925@email.android.com>
Content-Type: text/plain; charset="iso-8859-1"
I will take a look when I get to the office.
Sadly IPv6 records are manual at the moment, and its entirely possible its a typo.
Paul
Leo Vegoda <leo.vegoda@icann.org> wrote:
Hi,
On 1 Sep 2013, at 07:08, Jonathan Spence <jonathan.spence@power-business.co.nz> wrote:
> Hi everyone,
> Google have just started enforcing PTR records for IPv6 addresses delivering to Gmail. Our IPv6 works great with Orcon but having serious issues getting delegation back to our nameservers setup. I have been told a few times that everything is setup on their end but I don't think it is.
>
> Our IP space: 2400:4800:4017::/48 is meant to be sent to ns1.power-business.co.nz and ns2.power-business.co.nz. However it doesn't seem to.
The reverse domain for 2400:4800:4017::/48 is 7.1.0.4.0.0.8.4.0.0.4.2.ip6.arpa. Your supposition is correct and ns1.orcon.net.nz does not seem to have delegated the domain to your nameservers.
Regards,
Leo
------------------------------
Message: 4
Date: Sun, 1 Sep 2013 21:59:44 +0000
From: Paul Tinson <Paul.Tinson@team.orcon.net.nz>
To: "nznog@list.waikato.ac.nz" <nznog@list.waikato.ac.nz>
Subject: Re: [nznog] Orcon IPv6 rDNS delegation
Message-ID: <89CA63C1-BED3-4DF4-8E27-A27B0ABB9F5D@team.orcon.net.nz>
Content-Type: text/plain; charset="us-ascii"
OK we have had a good look into this and you have an issue you need to resolve.
A trace of your name servers shows this:
; <<>> DiG 9.3.4 <<>> +trace ns1.power-business.co.nz<http://ns1.power-business.co.nz>
;; global options: printcmd
. 19071 IN NS j.root-servers.net<http://j.root-servers.net>.
. 19071 IN NS m.root-servers.net<http://m.root-servers.net>.
. 19071 IN NS e.root-servers.net<http://e.root-servers.net>.
. 19071 IN NS i.root-servers.net<http://i.root-servers.net>.
. 19071 IN NS c.root-servers.net<http://c.root-servers.net>.
. 19071 IN NS l.root-servers.net<http://l.root-servers.net>.
. 19071 IN NS h.root-servers.net<http://h.root-servers.net>.
. 19071 IN NS d.root-servers.net<http://d.root-servers.net>.
. 19071 IN NS k.root-servers.net<http://k.root-servers.net>.
. 19071 IN NS g.root-servers.net<http://g.root-servers.net>.
. 19071 IN NS b.root-servers.net<http://b.root-servers.net>.
. 19071 IN NS f.root-servers.net<http://f.root-servers.net>.
. 19071 IN NS a.root-servers.net<http://a.root-servers.net>.
;; Received 512 bytes from 60.234.1.1#53(60.234.1.1) in 29 ms
nz. 172800 IN NS ns4.dns.net.nz<http://ns4.dns.net.nz>.
nz. 172800 IN NS ns6.dns.net.nz<http://ns6.dns.net.nz>.
nz. 172800 IN NS ns2.dns.net.nz<http://ns2.dns.net.nz>.
nz. 172800 IN NS ns5.dns.net.nz<http://ns5.dns.net.nz>.
nz. 172800 IN NS ns3.dns.net.nz<http://ns3.dns.net.nz>.
nz. 172800 IN NS ns1.dns.net.nz<http://ns1.dns.net.nz>.
nz. 172800 IN NS ns7.dns.net.nz<http://ns7.dns.net.nz>.
;; Received 428 bytes from 192.58.128.30#53(j.root-servers.net<http://j.root-servers.net>) in 13 ms
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns1.power-business.co.nz<http://ns1.power-business.co.nz>.
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns3.power-business.co.nz<http://ns3.power-business.co.nz>.
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns2.power-business.co.nz<http://ns2.power-business.co.nz>.
power-business.co.nz<http://power-business.co.nz>. 86400 IN NS ns4.power-business.co.nz<http://ns4.power-business.co.nz>.
;; Received 230 bytes from 202.46.189.130#53(ns4.dns.net.nz<http://ns4.dns.net.nz>) in 0 ms
ns1.power-business.co.nz<http://ns1.power-business.co.nz>. 10800 IN CNAME bia.power-business.co.nz<http://bia.power-business.co.nz>.
bia.power-business.co.nz<http://bia.power-business.co.nz>. 10800 IN A 60.234.77.213
;; Received 76 bytes from 60.234.77.213#53(ns1.power-business.co.nz<http://ns1.power-business.co.nz>) in 1 ms
The CNAME is illegal, this means we dont follow it.
RFC2181 section 10.3: Copied below:
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed. In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.
Let me know if you need further assistance.
Paul
On 2/09/2013, at 7:47 AM, Paul Tinson <Paul.Tinson@team.orcon.net.nz<mailto:Paul.Tinson@team.orcon.net.nz>>
wrote:
I will take a look when I get to the office.
Sadly IPv6 records are manual at the moment, and its entirely possible its a typo.
Paul
Leo Vegoda <leo.vegoda@icann.org<mailto:leo.vegoda@icann.org>> wrote:
Hi,
On 1 Sep 2013, at 07:08, Jonathan Spence <jonathan.spence@power-business.co.nz<mailto:jonathan.spence@power-business.co.nz>> wrote:
Hi everyone,
Google have just started enforcing PTR records for IPv6 addresses delivering to Gmail. Our IPv6 works great with Orcon but having serious issues getting delegation back to our nameservers setup. I have been told a few times that everything is setup on their end but I don't think it is.
Our IP space: 2400:4800:4017::/48 is meant to be sent to ns1.power-business.co.nz<http://ns1.power-business.co.nz> and ns2.power-business.co.nz<http://ns2.power-business.co.nz>. However it doesn't seem to.
The reverse domain for 2400:4800:4017::/48 is 7.1.0.4.0.0.8.4.0.0.4.2.ip6.arpa. Your supposition is correct and ns1.orcon.net.nz<http://ns1.orcon.net.nz> does not seem to have delegated the domain to your nameservers.
Regards,
Leo
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz<mailto:NZNOG@list.waikato.ac.nz>
http://list.waikato.ac.nz/mailman/listinfo/nznog
--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------
Teach Email Guard if this mail (ID 09KjUC5mG) is spam:
Spam: https://emailguard.orcon.net.nz/canit/b.php?i=09KjUC5mG&m=ae916b2c1e4b&t=20130902&c=s
Not spam: https://emailguard.orcon.net.nz/canit/b.php?i=09KjUC5mG&m=ae916b2c1e4b&t=20130902&c=n
Forget vote: https://emailguard.orcon.net.nz/canit/b.php?i=09KjUC5mG&m=ae916b2c1e4b&t=20130902&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.waikato.ac.nz/pipermail/nznog/attachments/20130901/6fc86e67/attachment-0001.html>
------------------------------
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
End of NZNOG Digest, Vol 129, Issue 1
*************************************