1

I'm sure I'm overlooking something so simple, but I'm just not seeing it... I'm trying to delegate the /24 and /64 reverse zones for our Test network to hosts within the Test network. I'm seeing the same issue with both the IPv4 /24 and IPv6 /64 delegation, so I'll focus on the IPv4 for the moment.

We use 172.31.0.0/16 internally, with 172.31.99.0/24 being the Test network.

I want to delegate 99.31.172.in-addr.arpa. to the 2 new Domain Controllers in the Test network at 172.31.99.11 and .12

$ORIGIN 99.31.172.in-addr.arpa.
@       NS      svr-addc1.ad.example.com.au.
@       NS      svr-addc2.ad.example.com.au.

Obviously I've replaced our actual domain with 'example'.

After a complete reload of named, I get NXDOMAIN from the local resolver:

# dig -x 172.31.99.11 @localhost

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 172.31.99.11 @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50720
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;11.99.31.172.in-addr.arpa. IN  PTR

;; Query time: 29 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Jul  9 16:38:33 2013
;; MSG SIZE  rcvd: 43

Meanwhile, a directed lookup to the IP that I've delegated to works fine:

# dig -x 172.31.99.11 @172.31.99.11

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 172.31.99.11 @172.31.99.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44598
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;11.99.31.172.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
11.99.31.172.in-addr.arpa. 1200 IN  PTR svr-addc1.ad.example.com.au.

;; Query time: 2 msec
;; SERVER: 172.31.99.11#53(172.31.99.11)
;; WHEN: Tue Jul  9 15:49:51 2013
;; MSG SIZE  rcvd: 81

This is the delegation for the forward lookup, which works as expected:

$ORIGIN ad.example.com.au.
@             NS    svr-addc1
@             NS    svr-addc2
; glue records:
svr-addc1 A     172.31.99.11
          AAAA  2001:xxxx:xxxx:c699::addc:21
svr-addc2 A     172.31.99.12
          AAAA  2001:xxxx:xxxx:c699::addc:22

Reverse lookups for other /24 networks still works fine:

# dig -x 172.31.42.101 @localhost +short
sw-sana.example.com.au.

EDIT

If I add the zone to named.conf as a type forward zone, then everything works correctly:

### TEST network delegated to the new AD controllers
zone "99.31.172.in-addr.arpa" IN {
    type forward;
    forwarders { 172.31.99.11; 172.31.99.12; };
};
zone "9.9.6.c.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa" IN {
    type forward;
    forwarders { 2001:xxxx:xxxx:c699::addc:21; 2001:xxxx:xxxx:c699::addc:22; };
};

And a dig using the local resolver works:

# dig -x 172.31.99.11 +short
svr-addc1.ad.example.com.au.

I really don't understand what I'm doing wrong :-/

fukawi2
  • 5,327
  • 3
  • 30
  • 51
  • You might want to look at the named logs at the time you reloaded. – smarthall Jul 09 '13 at 06:01
  • Nothing useful; just the usual: `Jul 9 15:40:44 fw1 named[21542]: zone example.com.au/IN/internal: loaded serial 2013070301` and the query: `client 127.0.0.1#37492: view internal: query: 11.99.31.172.in-addr.arpa IN PTR + (127.0.0.1)` – fukawi2 Jul 09 '13 at 06:23
  • So the logs say its loading 2013070301 but the serial number that its serving in the SOA record is 2013070904. – smarthall Jul 09 '13 at 06:29
  • Sorry, wrong zone. You're right, there was errors with "out of zone data", but I've fixed that and it loads correctly now, still doesn't work, and I don't even get an authority section in the reply now. I'll update the question with the new output. – fukawi2 Jul 09 '13 at 06:39
  • A tcpdump on the test network interface shows that named isn't sending a single packet to the DC, whereas I can see the traffic when doing a forward lookup. – fukawi2 Jul 09 '13 at 06:42

2 Answers2

1

Once a domain is delegated on your main dns server, it won't respond to dns queries for those domains unless recursion is ON. The reason the forwarding is working is, a forwarder does recursion by default. You might try to enable recursion first.

Daniel t.
  • 9,061
  • 1
  • 32
  • 36
  • Recursion is enabled in the 'internal' view, which the logs confirm is the view that the request is hitting: `client 127.0.0.1#37492: view internal: query: 11.99.31.172.in-addr.arpa IN PTR + (127.0.0.1)` – fukawi2 Jul 11 '13 at 00:27
  • when you set NS records for delegation, have you specified the 'glue records', which is the A records for the two new domain controllers in your zone file? – Daniel t. Jul 11 '13 at 02:09
  • Yes; I've delegated the '`ad.example.com.au`' subdomain of '`example.com.au`' in the forward zone to the same servers. It works perfectly. – fukawi2 Jul 11 '13 at 06:22
1

I want to delegate 99.31.172.in-addr.arpa. to the 2 new Domain Controllers in the Test network at 172.31.99.11 and .12

$ORIGIN 99.31.172.in-addr.arpa.
@       NS      svr-addc1.ad.example.com.au.
@       NS      svr-addc2.ad.example.com.au.

Into which file are you putting the lines above? The delegations should be in the containing zone (i.e. the delegation records for 99.31.172.in-addr.arpa. should exist inside the zone for 31.172.in-addr.arpa.) Also, as a stylistic question, what do you gain by changing the $ORIGIN? It makes the records less explicitly clear and can possibly cause side effects if you have other zone contents defined further on in the file.

Finally does your named.conf file on the main nameserver (not the one in the test network) still contain a zone declaration for 99.31.172.in-addr.arpa. in its views?

Michael McNally
  • 1,450
  • 9
  • 14
  • Thanks for your input Michael. Those lines are going into the zone file for `31.172.in-addr.arpa`. Using $ORIGIN is a personal preference I guess; I find it easier to read by segregating the file into blocks. FWIW, I have tried it without $ORIGIN and making each line fully-qualified. There is no named on the TEST network (AD Domain Controllers), and no there wasn't an explicit zone for 99.31.172 in any view in the named.conf when I was doing this (there is now, as per the last edit to my OP) – fukawi2 Jul 17 '13 at 06:28