DNS forward zone will not resolve new records

Question

I have a master DNS server (BIND9, IP 172.23.129.24) configured to point a forwarding zone to another master server that is configured for DDNS services. This directive is in the /etc/named.conf file.

zone "forward.example.com" {
    type forward;
    forwarders {172.23.129.130;};
};

On the 172.23.129.130 server, my config has the following zone (and omapi-key settings in other sections):

zone "forward.example.com" {
    type master;
    file "/var/named/forward.example.com.hosts";
    allow-update {
            key omapi-key;
            172.23.129.21;
            172.23.129.22;
            };
    };

The "forward.example.com" zone file looks like the following:

$ORIGIN .
$TTL 38400  ; 10 hours 40 minutes
forward.example.com        IN SOA  ns.example.com. myemail.example.com. (
                            1486523615 ; serial
                            10800      ; refresh (3 hours)
                            3600       ; retry (1 hour)
                            604800     ; expire (1 week)
                            38400      ; minimum (10 hours 40 minutes)
                            )
                    NS  ns.example.com.
$ORIGIN ns.example.com.
$TTL 3600   ; 1 hour
first-host A     172.17.7.5
              TXT   "ID_STRING"
...etc.

When I add an entry manually (after first freezing the zone then unfreezing since its dynamic), it appears and I can resolve it by targeting the server with the forwarding zone using dig:

dig @172.23.129.130 manual-entry.forward.example.com

This will work with success, and I get an answer. However, if I do the same for the main server that forwards, then it fails:

dig @172.23.129.24 manual-entry.forward.example.com

; <<>> DiG 9.8.3-P1 <<>> manual-entry.forward.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65339
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;manual-entry.forward.example.com.  IN  A

;; AUTHORITY SECTION:
manual-entry.forward.example.com.   3474    IN  SOA ns.example.com.    myemail.example.com. 1486523594 10800 3600 604800 38400

;; Query time: 47 msec
;; SERVER: 172.23.129.24#53(172.23.129.24)
;; WHEN: Fri Dec 15 22:37:49 2017
;; MSG SIZE  rcvd: 107

At the same time, using "dig" to target other entries in the "forward.example.com" zone works just fine. I've applied the zone, restarted BIND, and numerous other efforts to reload the zone. The file shows the entries, and the server targeted with the dig command should just forward all requests for the "forward.example.com" domain to the second server. It does so in some cases, but not in others, and this is somewhat perplexing to me. Are there any suggestions for where to look?

You understand that a 'forward' zone still caches right? – Zoredache Dec 16 '17 at 06:55 — Zoredache, Dec 16 '17 at 06:55

BillThor · Answer 1 · 2017-12-16T18:15:49.930

1

You may want to configure this as a slave zone rather than a forwarding zone. This will require that the the primary server allow zone transfers of this zone from the slave. You can also configure the primary zone to notify the slave zone when the zone changes.

There are two caching values for a domain. For positive matches, the caching time can be set for each domain but is usually but defaults to the value specified in the $TTL line. For negative matches, bind uses the minimum value of max-ncache-ttl (default 3 hours) and the minimum value from the SOA record.

If you don't search for the domain before the primary is loaded, the forwarding domain should forward the request, find it and cache it.

edited Dec 16 '17 at 18:15

answered Dec 16 '17 at 15:09

BillThor

27,737
3
37
69

Minor correction: the zone-specified negative cache TTL is [`MIN(SOA TTL, SOA.MINIMUM)`](https://tools.ietf.org/html/rfc2308#section-5) while, as you noted, the default max value in BIND's resolver-side policy ([`max-ncache-ttl`](https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html#tuning))) is 3h. So there's those three values (rather than just two) that are taken into account. – Håkan Lindqvist Dec 16 '17 at 16:01

DNS forward zone will not resolve new records

1 Answers1