|
Ticket ID: SIXXS #1115432 Ticket Status: User PoP: (not applicable)
strange result for zonecheck
![[de]](/s/countries/de.gif) Shadow Hawkins on Monday, 15 June 2009 12:25:51
I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there:
I (SRF4-SIXXS) recently got a new subnet R9150 from SixXS. I added two nameservers for reverse delegation: ns1.coresystems.de and ns2.coresystems.de.
Both work nicely with an identical setup for subnet R8895, but with R9150 I get the following result from
https://www.sixxs.net/tools/zonecheck/?zone=2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa
Unable to find primary nameserver (SOA)
The denic zonecheck seems to not have this problem:
http://zonecheck.denic.de/zonecheck/cgi-bin/zc.cgi?zone=2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa&ns0=ns1.coresystems.de&ips0=&ns1=ns2.coresystems.de&ips1=&ns2=&ips2=&ns3=&ips3=&ns4=&ips4=&intro=t&explain=t&details=t&progress=counter&report=byseverity&format=html&lang=en&errorlvl=&profile=automatic&chkzone=t&chkrir=t&transp3=ipv4&transp4=std
However, for R8895 everything looks ok (besides that I have not fixed the reverse for the name servers yet, which is kind of a hen-egg problem):
ZoneCheck: 2.e.3.0.8.9.1.0.1.0.a.2.ip6.arpa.
Test results
---- warning ----
w: Reverse for the nameserver IP address doesn't match
* ns2.coresystems.de./80.190.231.112
* ns1.coresystems.de./80.81.252.129
* ns2.coresystems.de./2A01:138:A014::1
* ns1.coresystems.de./2A01:198:200:4AF::2
Final status
SUCCESS (but 4 warning(s))
Can you help? Or do you suggest to just ignore the zone check for R9150?
State change: user
The state of this ticket has been changed to user
strange result for zonecheck
The denic zonecheck seems to not have this problem:
http://zonecheck.denic.de/zonecheck/cgi-bin/zc.cgi?zone=2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa&ns0=ns1.coresystems.de&ips0=&ns1=ns2.coresystems.de&ips1=&ns2=&ips2=&ns3=&ips3=&ns4=&ips4=&intro=t&explain=t&details=t&progress=counter&report=byseverity&format=html&lang=en&errorlvl=&profile=automatic&chkzone=t&chkrir=t&transp3=ipv4&transp4=std
That contains: ns0=ns1.coresystems.de and ns1=ns2.coresystems.de and thus that queries those nameserver directly.
Try http://zonecheck.denic.de/zonecheck/cgi-bin/zc.cgi?zone=2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa
and you will get exactly the same result as with the SixXS zonecheck.
However, for R8895 everything looks ok (besides that I have not fixed the reverse for the name servers yet, which is kind of a hen-egg problem): [..]
* ns2.coresystems.de./2A01:138:A014::1 * ns1.coresystems.de./2A01:198:200:4AF::2
Both of those already have reverses, but which point to something else. The report is again correct.
strange result for zonecheck
Shadow Hawkins on Sunday, 21 June 2009 17:02:59
Hi Jeroen,
thanks a lot for looking into this.
Ok, but why does it not try to query the nameservers ns1.coresystems.de. and ns2.coresystems.de. when not specifying them? I entered them for both R8895 and R9150. It worked for one but not for the other. What piece of the puzzle am I missing?
Stefan
strange result for zonecheck
Because maybe at the time you queried them those entries where not synced into DNS yet or that the cache still had nothing listed?
strange result for zonecheck
Shadow Hawkins on Thursday, 09 July 2009 13:39:38
But, shouldn't the problem be gone by now in that case?
http://zonecheck.denic.de/zonecheck/cgi-bin/zc.cgi?zone=2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa
still says: Unable to find primary nameserver (SOA)
and it has been a few weeks since I touched the DNS settings. It seems to me that for the one zone it didn't take the name servers at all, but I have no idea why. The same setup on my side worked fine for the other zone, almost immediately.
strange result for zonecheck
Shadow Hawkins on Thursday, 16 July 2009 11:55:24
Ok, some more information:
This is the zone that is not working:
dig 2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa
; <<>> DiG 9.4.3-P1 <<>> 2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44418
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;2.1.4.0.8.9.1.0.1.0.a.2.ip6.arpa. INA
;; AUTHORITY SECTION:
8.9.1.0.1.0.a.2.ip6.arpa. 3567INSOAns1.dnspartner.de. hostmaster.speedpartner.de. 2008111100 28800 7200 604800 86400
;; Query time: 1 msec
;; SERVER: 192.168.0.254#53(192.168.0.254)
;; WHEN: Thu Jul 16 11:48:27 2009
;; MSG SIZE rcvd: 127
And this is the zone that is working:
dig 2.e.3.0.8.9.1.0.1.0.a.2.ip6.arpa
; <<>> DiG 9.4.3-P1 <<>> 2.e.3.0.8.9.1.0.1.0.a.2.ip6.arpa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64920
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;2.e.3.0.8.9.1.0.1.0.a.2.ip6.arpa. INA
;; AUTHORITY SECTION:
2.e.3.0.8.9.1.0.1.0.a.2.ip6.arpa. 3600 IN SOAns1.coresystems.de. hostmaster.openbios.org. 2009050103 86400 7200 604800 86400
;; Query time: 201 msec
;; SERVER: 192.168.0.254#53(192.168.0.254)
;; WHEN: Thu Jul 16 11:49:22 2009
;; MSG SIZE rcvd: 127
Both have ns1.coresystems.de as their primary nameserver entered here:
https://www.sixxs.net/home/routeinfo/?8895
https://www.sixxs.net/home/routeinfo/?9150
Yet, the non-working one (9150) does not try to look at the nameserver ns1.coresystems.de but instead at ns1.dnspartner.de (91.184.32.34) which belongs to
SpeedPartner GmbH
Neukirchener Str. 57
41470 Neuss
No idea who those guys are, or why the zone points to them..
strange result for zonecheck
Yet, the non-working one (9150) does not try to look at the nameserver ns1.coresystems.de but instead at ns1.dnspartner.de (91.184.32.34) which belongs to SpeedPartner GmbH [..]
No idea who those guys are, or why the zone points to them..
Ever thought of looking at the dedus01 aka SpeedPartner PoP page...???
Just to re-state: the ticket is confirmed, we are aware of the issue. It is being resolved in due time.
|
![[ch]](/s/countries/ch.gif)
on Monday, 15 June 2009 12:32:25
Posting is only allowed when you are