Stumped and at a loss: rDNS bind9

penguinness · May 19, 2009, 11:17:22 PM

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.

Code Select

; 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:

Code Select

; <<>> 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:

Code Select

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

Code Select

$ 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 · May 20, 2009, 12:01:54 AM

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 · May 20, 2009, 03:40:07 AM

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 · May 20, 2009, 03:42:57 AM

could also be caching on the remote side not updating.

penguinness · May 20, 2009, 04:09:40 AM

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:

Code Select

$ 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 · May 20, 2009, 12:16:30 PM

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 · May 20, 2009, 12:22:47 PM

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 · May 20, 2009, 08:10:08 PM

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:

Code Select

; 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:

Code Select

; 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:

Code Select

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 · May 21, 2009, 12:52:08 PM

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 · May 21, 2009, 12:55:39 PM

Ah, duh, didn't read it 100%

Good luck!

penguinness · May 21, 2009, 07:32:06 PM

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

Code Select

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

Code Select

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

Code Select

$ 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

Code Select

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 · May 22, 2009, 02:30:34 PM

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 · May 22, 2009, 08:21:17 PM

Code Select

$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 · May 23, 2009, 10:59:49 AM

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 · May 23, 2009, 11:57:59 AM

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.

News:

Stumped and at a loss: rDNS bind9