• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Stumped and at a loss: rDNS bind9

Started by penguinness, May 19, 2009, 11:17:22 PM

Previous topic - Next topic

penguinness

Knowing my luck, I probably missed some basic setting and will look like a total newbie, but here I go.  :)

Forward works, pings to the name servers work, but tests from sites like http://www.fpsn.net/tools&tool=web-dig fail with a timeout.

I am using the routed /48, subnetted out.  The DNS is set to be the SOA for 2001:470:8331:: with a delegation for the subnet set (at least I'm pretty sure it's done correctly).  The domain itself is a subdomain of my IPv4 domain.

; 2001:470:8331::/48
;
$TTL 3d ; Default TTL (bind 8 needs this, bind 9 ignores it)
@        IN SOA 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. root.penguinness.org. (
                2009051901      ; Serial number (YYYYMMdd)
                24h             ; Refresh time
                30m             ; Retry time
                2d              ; Expire time
                3d              ; Default TTL (bind 8 ignores this, bind 9 needs it)
)

                                                ; Name server entries
                                IN      NS      pint.ip6.penguinness.org.
                                IN      NS      fifth.ip6.penguinness.org.

$ORIGIN 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.
6762                            IN      NS      pint.ip6.penguinness.org.
6762                            IN      NS      fifth.ip6.penguinness.org.



From the http://www.fpsn.net dig tool:

; <<>> DiG 9.3.1 <<>> @::1 aaaa +trace 6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa
; (1 server found)
;; global options:  printcmd
. 444690 IN NS E.ROOT-SERVERS.NET.
. 444690 IN NS F.ROOT-SERVERS.NET.
. 444690 IN NS G.ROOT-SERVERS.NET.
. 444690 IN NS H.ROOT-SERVERS.NET.
. 444690 IN NS I.ROOT-SERVERS.NET.
. 444690 IN NS J.ROOT-SERVERS.NET.
. 444690 IN NS K.ROOT-SERVERS.NET.
. 444690 IN NS L.ROOT-SERVERS.NET.
. 444690 IN NS M.ROOT-SERVERS.NET.
. 444690 IN NS A.ROOT-SERVERS.NET.
. 444690 IN NS B.ROOT-SERVERS.NET.
. 444690 IN NS C.ROOT-SERVERS.NET.
. 444690 IN NS D.ROOT-SERVERS.NET.

;; Received 288 bytes from ::1#53(::1) in 0 ms


ip6.arpa. 172800 IN NS SEC1.APNIC.NET.
ip6.arpa. 172800 IN NS NS.ICANN.ORG.
ip6.arpa. 172800 IN NS NS-SEC.RIPE.NET.
ip6.arpa. 172800 IN NS NS2.LACNIC.NET.
ip6.arpa. 172800 IN NS TINNIE.ARIN.NET.

;; Received 221 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 86 ms


4.0.1.0.0.2.ip6.arpa. 84600 IN NS indigo.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS ns-sec.ripe.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS epazote.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS figwort.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS ns2.lacnic.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS chia.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS dill.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS sec1.apnic.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS sec3.apnic.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS basil.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS henna.arin.net.

;; Received 380 bytes from 192.0.34.126#53(NS.ICANN.ORG) in 102 ms


0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns2.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns3.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns5.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns1.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns4.he.net.

;; Received 186 bytes from 192.31.80.32#53(indigo.arin.net) in 87 ms


1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS fifth.ip6.penguinness.org.
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS pint.ip6.penguinness.org.

;; Received 148 bytes from 216.218.130.2#53(ns1.he.net) in 95 ms


;; connection timed out; no servers could be reached


From one of my machines locally:

$ dig -x 2001:470:8331:6762::66

; <<>> DiG 9.4.2-P2 <<>> -x 2001:470:8331:6762::66
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23515
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 259200 IN PTR keg.ip6.penguinness.org.

;; AUTHORITY SECTION:
2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 259200 IN NS pint.ip6.penguinness.org.
2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 259200 IN NS fifth.ip6.penguinness.org.

;; ADDITIONAL SECTION:
pint.ip6.penguinness.org. 86400 IN      AAAA    2001:470:8331:6762::69
fifth.ip6.penguinness.org. 86400 IN     AAAA    2001:470:8331:6762::65

;; Query time: 3 msec
;; SERVER: 192.168.78.65#53(192.168.78.65)
;; WHEN: Tue May 19 23:04:52 2009
;; MSG SIZE  rcvd: 222


And with +trace...

$ dig -x 2001:470:8331:6762::66 +trace

; <<>> DiG 9.4.2-P2 <<>> -x 2001:470:8331:6762::66 +trace
;; global options:  printcmd
. 353872 IN NS j.root-servers.net.
. 353872 IN NS h.root-servers.net.
. 353872 IN NS e.root-servers.net.
. 353872 IN NS d.root-servers.net.
. 353872 IN NS l.root-servers.net.
. 353872 IN NS a.root-servers.net.
. 353872 IN NS k.root-servers.net.
. 353872 IN NS f.root-servers.net.
. 353872 IN NS m.root-servers.net.
. 353872 IN NS c.root-servers.net.
. 353872 IN NS g.root-servers.net.
. 353872 IN NS b.root-servers.net.
. 353872 IN NS i.root-servers.net.
;; Received 500 bytes from 192.168.78.65#53(192.168.78.65) in 10 ms

ip6.arpa. 172800 IN NS TINNIE.ARIN.NET.
ip6.arpa. 172800 IN NS NS.ICANN.ORG.
ip6.arpa. 172800 IN NS NS-SEC.RIPE.NET.
ip6.arpa. 172800 IN NS SEC1.APNIC.NET.
ip6.arpa. 172800 IN NS NS2.LACNIC.NET.
;; Received 221 bytes from 192.112.36.4#53(g.root-servers.net) in 88 ms

4.0.1.0.0.2.ip6.arpa. 84600 IN NS indigo.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS ns-sec.ripe.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS epazote.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS figwort.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS ns2.lacnic.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS chia.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS dill.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS sec1.apnic.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS sec3.apnic.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS basil.arin.net.
4.0.1.0.0.2.ip6.arpa. 84600 IN NS henna.arin.net.
;; Received 380 bytes from 192.0.34.126#53(NS.ICANN.ORG) in 41 ms

0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns4.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns2.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns1.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns3.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns5.he.net.
;; Received 186 bytes from 192.41.162.32#53(epazote.arin.net) in 111 ms

1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS fifth.ip6.penguinness.org.
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS pint.ip6.penguinness.org.
;; Received 148 bytes from 216.218.130.2#53(ns1.he.net) in 47 ms

6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 259200 IN PTR keg.ip6.penguinness.org.
2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 259200 IN NS pint.ip6.penguinness.org.
2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 259200 IN NS fifth.ip6.penguinness.org.
;; Received 222 bytes from 2001:470:8331:6762::69#53(pint.ip6.penguinness.org) in 125 ms


I just don't understand it.  It shouldn't be timing out when I can ping and forward lookups are working fine, right?  And if it was a delegation issue on my side, then nothing would work from the inside, correct?

I ran wireshark on the interface as well and I simply do not even see any DNS related traffic hitting the incoming tunnel when trying to do the reverse.  Any hints or ideas?

kcochran

Actually, I think it's a pretty simple thing, and one that you might be able to change, or might not.

That site probably doesn't have v6 connectivity, and as such can't query your designated NS records, as they're v6-only.

penguinness

Quote from: kcochran on May 20, 2009, 12:01:54 AMActually, I think it's a pretty simple thing, and one that you might be able to change, or might not.

That site probably doesn't have v6 connectivity, and as such can't query your designated NS records, as they're v6-only.
If that is the case, I find it strange that the site would have the tool up and available but not have the connectivity needed.  But hey, go figure.  :-\

Anyway, are there any other sites around that I can test my reverse delegation?  Browsing to http://www.berkom.blazing.de/ (via lynx) doesn't show a hostname to go with the IP, hence me trying to verify that something isn't broken.

broquea

could also be caching on the remote side not updating.

penguinness

Quote from: broquea on May 20, 2009, 03:42:57 AM
could also be caching on the remote side not updating.
Might be, however, I just ran into something interesting...

I forgot to mention that I have a spilt view server.  The only difference between the two views as far as the ACL's go is that the inside-in view is allowed to recurse, the external-in is not.

I removed the ip6.penguinness.org domain from the inside view, forcing all queries against the subdomain to go out and come back in via the external view.  This is what I received from the same machine that previously was successful:

$ dig -x 2001:470:8331:6762::66 +trace

; <<>> DiG 9.4.2-P2 <<>> -x 2001:470:8331:6762::66 +trace
;; global options:  printcmd
. 337620 IN NS m.root-servers.net.
. 337620 IN NS h.root-servers.net.
. 337620 IN NS b.root-servers.net.
. 337620 IN NS i.root-servers.net.
. 337620 IN NS g.root-servers.net.
. 337620 IN NS d.root-servers.net.
. 337620 IN NS f.root-servers.net.
. 337620 IN NS k.root-servers.net.
. 337620 IN NS a.root-servers.net.
. 337620 IN NS j.root-servers.net.
. 337620 IN NS l.root-servers.net.
. 337620 IN NS e.root-servers.net.
. 337620 IN NS c.root-servers.net.
;; Received 500 bytes from 192.168.78.65#53(192.168.78.65) in 31 ms

ip6.arpa. 172800 IN NS TINNIE.ARIN.NET.
ip6.arpa. 172800 IN NS NS-SEC.RIPE.NET.
ip6.arpa. 172800 IN NS SEC1.APNIC.NET.
ip6.arpa. 172800 IN NS NS2.LACNIC.NET.
ip6.arpa. 172800 IN NS NS.ICANN.ORG.
;; Received 221 bytes from 192.112.36.4#53(g.root-servers.net) in 115 ms

0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns1.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns2.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns3.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns4.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN NS ns5.he.net.
;; Received 186 bytes from 2001:dc0:2001:a:4608::59#53(SEC1.APNIC.NET) in 362 ms

1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS fifth.ip6.penguinness.org.
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS pint.ip6.penguinness.org.
;; Received 148 bytes from 2001:470:400::2#53(ns4.he.net) in 127 ms

1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4513 IN NS fifth.ip6.penguinness.org.
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4513 IN NS pint.ip6.penguinness.org.
;; BAD (HORIZONTAL) REFERRAL
;; Received 148 bytes from 2001:470:8331:6762::65#53(fifth.ip6.penguinness.org) in 0 ms

1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4483 IN NS fifth.ip6.penguinness.org.
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4483 IN NS pint.ip6.penguinness.org.
;; BAD (HORIZONTAL) REFERRAL
;; Received 148 bytes from 2001:470:8331:6762::69#53(pint.ip6.penguinness.org) in 0 ms

;; connection timed out; no servers could be reached


Bad (horizontal) referral?  I've never seen this one before and google isn't turning up much either.

snarked

MALFORMED IPv6 REVERSE ZONE
Quote; 2001:470:8331::/48
;
$TTL 3d ; Default TTL (bind 8 needs this, bind 9 ignores it)
@        IN SOA 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. root.penguinness.org. (
                2009051901      ; Serial number (YYYYMMdd)
                24h             ; Refresh time
                30m             ; Retry time
                2d              ; Expire time
                3d              ; Default TTL (bind 8 ignores this, bind 9 needs it)
)

                                                ; Name server entries
                                IN      NS      pint.ip6.penguinness.org.
                                IN      NS      fifth.ip6.penguinness.org.

$ORIGIN 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.
6762                            IN      NS      pint.ip6.penguinness.org.   ;FIX ME
6762                            IN      NS      fifth.ip6.penguinness.org.   ;FIX ME
The last two entries have an incorrect label.  Instead of "6762", shouldn't they be "2.6.7.6"?

broquea

Actually would need to be like 2.6.7.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 since this is for a /48 since the ORIGIN is only covering those first bits of the /48

penguinness

Bah, this is driving me up a wall...  I don't know what I did, but now the slave is saying that the notification for the subnet reverse is non-authoritative.  Aside from the "6762 IN NS $FOO.ip6.penguinness.org." subnet delegation lines (which I wasn't sure about), I thought I had this correct, or do I have to do subnet delegation with more than two machines?  My original idea was to be able to split each subnet out into separate files in an attempt to keep the main config file from becoming huge with zone declarations.

named-checkzone -i full ip6.penguinness.org ./forward returns OK
named-checkzone -i full 2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa ./reverse.6762 returns OK

named-checkzone -i full 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa ./reverse returns zone 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa/IN: getaddrinfo($FOO.ip6.penguinness.org) failed: Temporary failure in name resolution before returning OK

Any help is greatly appreciated

/48 file:
; 2001:470:8331::/48
;
$TTL 3d ; Default TTL (bind 8 needs this, bind 9 ignores it)
@       IN      SOA     1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.       root.penguinness.org. (
                2009052015      ; Serial number (YYYYMMdd)
                24h             ; Refresh time
                30m             ; Retry time
                2d              ; Expire time
                3d              ; Default TTL (bind 8 ignores this, bind 9 needs it)
)

                                                IN      NS      pint.ip6.penguinness.org.
                                                IN      NS      fifth.ip6.penguinness.org.
; IPv6 PTR entries

$ORIGIN 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.

2.6.7.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      NS      pint.ip6.penguinness.org.
2.6.7.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      NS      fifth.ip6.penguinness.org.
(I tried with 2.6.7.2 alone as well)

6762/64 file:
; 2001:470:8331:6762::/64
;
$TTL 3d ; Default TTL (bind 8 needs this, bind 9 ignores it)
@       IN      SOA     2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.       root.penguinness.org. (
                2009052001      ; Serial number (YYYYMMdd)
                24h             ; Refresh time
                30m             ; Retry time
                2d              ; Expire time
                3d              ; Default TTL (bind 8 ignores this, bind 9 needs it)
)

                                        IN      NS      pint.ip6.penguinness.org.
                                        IN      NS      fifth.ip6.penguinness.org.
; IPv6 PTR entries

$ORIGIN 2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.

5.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     fifth.ip6.penguinness.org.
6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     keg.ip6.penguinness.org.
7.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     bar.ip6.penguinness.org.
8.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     page.ip6.penguinness.org.
9.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     pint.ip6.penguinness.org.


Relevant parts from the config file:
zone "ip6.penguinness.org" in {
type master;
file "forward";
};

zone "1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa" in {
type master;
file "reverse";
};

zone "2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa" in {
type master;
file "reverse.6762";
};

snarked

I disagree:
QuoteActually would need to be like 2.6.7.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 since this is for a /48 since ...
What he appears to be doing is a delegation out of his /48 for a /64:
Quotezone "1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa" in {
type master;
file "reverse";
};

zone "2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa" in {
type master;
file "reverse.6762";
};
Therefore, I stand by my answer.  All he needs is "2.6.7.6".  Notice the typo: 2.6.7.2.  That's why that version didn't work.

broquea

Ah, duh, didn't read it 100%

Good luck!

penguinness

#10
Can't believe I missed that typo.  I feel like a maroon.  :-[

So I made the change, and it's still failing in the same ways as before.

So I've simplified it, I hope...

; 2001:470:8331::/48
;
$TTL 1d ; Default TTL (bind 8 needs this, bind 9 ignores it)
@       IN      SOA     1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.       root.penguinness.org. (
                2009052106      ; Serial number (YYYYMMdd)
                1h              ; Refresh time
                15m             ; Retry time
                2d              ; Expire time
                3h              ; Default TTL (bind 8 ignores this, bind 9 needs it)
)

                                                IN      NS      pint.ip6.penguinness.org.
                                                IN      NS      fifth.ip6.penguinness.org.
; IPv6 PTR entries

$ORIGIN 2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.

5.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     fifth.ip6.penguinness.org.
6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     keg.ip6.penguinness.org.
7.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     bar.ip6.penguinness.org.
8.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     page.ip6.penguinness.org.
9.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     pint.ip6.penguinness.org.


Now the slave says the master reports that it's non-authoritative for 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa *sigh*

On a whim, I compared the master reverse to the slave from an earlier attempt (when it didn't say that it was not the SOA) and the two are identical.

However, dig -x 2001:470:8331:6762::66 +trace from a local machine (different subnet) is a bit different....
...snip...
ip6.arpa.               172800  IN      NS      NS-SEC.RIPE.NET.
ip6.arpa.               172800  IN      NS      TINNIE.ARIN.NET.
;; Received 221 bytes from 2001:500:2f::f#53(F.ROOT-SERVERS.NET) in 51 ms

0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN      NS      ns2.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN      NS      ns3.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN      NS      ns1.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN      NS      ns5.he.net.
0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN      NS      ns4.he.net.
;; Received 186 bytes from 2001:610:240:0:53::4#53(NS-SEC.RIPE.NET) in 212 ms

1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS    fifth.ip6.penguinness.org.
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS    pint.ip6.penguinness.org.
;; Received 148 bytes from 216.218.130.2#53(ns1.he.net) in 51 ms

.                       518228  IN      NS      d.root-servers.net.
.                       518228  IN      NS      e.root-servers.net.
...snip...
;; BAD REFERRAL
;; Received 301 bytes from 2001:470:8331:6762::69#53(pint.ip6.penguinness.org) in 8 ms
(I tried this by specifying fifth or pint as well, same results)

Without the +trace:
$ dig -x 2001:470:8331:6762::66

; <<>> DiG 9.5.1-P1 <<>> -x 2001:470:8331:6762::66
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44586
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 86400 IN PTR keg.ip6.penguinness.org.

;; AUTHORITY SECTION:
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 86400 IN NS   pint.ip6.penguinness.org.
1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 86400 IN NS   fifth.ip6.penguinness.org.

;; ADDITIONAL SECTION:
pint.ip6.penguinness.org. 86290 IN      AAAA    2001:470:8331:6762::69
fifth.ip6.penguinness.org. 86290 IN     AAAA    2001:470:8331:6762::65

;; Query time: 676 msec
;; SERVER: 192.168.78.65#53(192.168.78.65)
;; WHEN: Thu May 21 18:55:13 2009
;; MSG SIZE  rcvd: 222


named-checkzone 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. /etc/bind/ip6.penguinness.org/reverse
zone 1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa/IN: loaded serial 200905215
OK


Now, I don't know if it's my glue records from the master domain (ipv4 only) that point to an ipv6 address for the $FOO.ip6.penguinness.org names, or something on the registrar side (godaddy in this case).

I have a feeling that if I can figure out the non-authoritative, I may have this working, but crapola, I have no idea what could be causing this new one.

snarked

#11
Errors/comments in bold:
Quote; 2001:470:8331::/48
;
$TTL 1d ; Default TTL (bind 8 needs this, bind 9 ignores it)
@       IN      SOA     1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.       root.penguinness.org. (
                2009052106      ; Serial number (YYYYMMdd)
                1h              ; Refresh time Too low - BIND supports NOTIFY
                15m           ; Retry time
                2d              ; Expire time
                3h              ; Negative answer TTL (bind 8 ignores this, bind 9 needs it)
)
                                                IN      NS      pint.ip6.penguinness.org.
                                                IN      NS      fifth.ip6.penguinness.org.
; IPv6 PTR entries

$ORIGIN 2.6.7.6.1.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa.  ;Truncate me

5.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     fifth.ip6.penguinness.org.
6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     keg.ip6.penguinness.org.
7.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     bar.ip6.penguinness.org.
8.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     page.ip6.penguinness.org.
9.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     pint.ip6.penguinness.org.
The $ORIGIN directive (in this case) does not require a full zone name back to the DNS root.  A relative $ORIGIN 2.6.7.6 is sufficient.

SOA:  The first field is supposed to be a name server, not the zone itself.  It looks as if "pint.ip6.penguinness.org" is the master, and "fifth" is a secondary.  (You still need a secondary outside of your network.)

I also assume you've eliminated the child zone from your configuration.

The above will not prevent your zone from working (which it appears to be with revision 16 today).

penguinness

$TTL 1d ; Default TTL (bind 8 needs this, bind 9 ignores it)
@       IN      SOA     pint.ip6.penguinness.org.  root.penguinness.org. (
                2009052200      ; Serial number (YYYYMMdd)
                2d              ; Refresh time
                15m             ; Retry time
                2d              ; Expire time
                1h              ; Default TTL (bind 8 ignores this, bind 9 needs it)
)

                                                IN      NS      pint.ip6.penguinness.org.
                                                IN      NS      fifth.ip6.penguinness.org.
; IPv6 PTR entries

$ORIGIN 2.6.7.6

5.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     fifth.ip6.penguinness.org.
6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     keg.ip6.penguinness.org.
7.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     bar.ip6.penguinness.org.
8.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     page.ip6.penguinness.org.
9.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     pint.ip6.penguinness.org.


Nope, the slave still says that the master is not authoritative for the reverse, and now it's complaining that the forward is not authoritative as well.

Yes, I removed the zone file for 6762 all together and put it under a single file.

A dig -x back to one of my IP's still loops back to the root servers and stops with a BAD REFERRAL message.  And, of course, I can't leave it alone as I really want to know why it's not working and suddenly got worse (the not authoritative messages).

snarked

All I can say is that when I looked at your doman from my host, the PTR records did resolve (version 16 of your zone yesterday).  However, your slave at the same time reported version 10, so it was behind in updating (or updating broke).

penguinness

Quote from: snarked on May 23, 2009, 10:59:49 AMAll I can say is that when I looked at your doman from my host, the PTR records did resolve (version 16 of your zone yesterday).  However, your slave at the same time reported version 10, so it was behind in updating (or updating broke).
Well, thank you for checking that, I do appreciate it.  And yes, the slave isn't updating because of this master is non authoritative mess that popped up.

It's things like this that make me start looking at something besides ISC BIND or DNS appliances.  :P

My layout:
Domain: penguinness.org, registrar (godaddy) has pint.penguinness.org and fifth.penguinness.org pointed at IPv4 address

Set up the tunnel with HE, decided to try and create the IPv6 side of the domain in a subdomain.  My idea was to have penguinness.org as IPv4 only and ip6.penguinness.org as IPv6 only.

Added IP4 and 6 glue records to the master domain (pint = 173.8.193.60, pint.ip6 = 173.8.193.60/2001:470:8331:6762::69), registrar had IPv6 addresses added to the original domain records.

My idea was to have the IPv6 side separate from the IPv4 side, and as I understand it, my description should be possible and aside from those typos you pointed out (thank you again for that), everything else appears to be correct and proper.  However, it may be that I am incorrect on the layoutbeing possible.  Everything I have read and seen about subdomains all seem to deal with IPv4, I've not found anything that specifically mentions doing the same thing with a IPv4 master domain and a child IPv6 subdomain.