GTM query regarding Internal and external zone views.

Nice one John works great, changing the internal listener (ACLs) and the view list did the trick indeed! If I do a netstat -an | grep 127.10 I see that the Big IP is listening internally for DNS requests on 127.10.0.0 and 127.10.0.1 and also 127.0.0.1.

Darren if I change both ACL to the same IP 127.0.0.0 than I am not able to access the zones anymore, so it seems it is needed to have two listeners. I believe these are only for ACL functionality internally within BIND, because the real listener in the named conf is 127.0.0.1

listen-on port 53 {
    127.0.0.1;
    "zrd-acl-000-001";
    "zrd-acl-000-000";
};

listen-on-v6 port 53 {
    ::1;
};

acl "zrd-acl-000-000" {
127.10.0.0;
};

acl "zrd-acl-000-001" {
127.10.0.1;
};


[root@F5:Active:In Sync] namedb  netstat -an | grep :53
tcp        0      0 **127.10.0.1:53**               0.0.0.0:*                   LISTEN
tcp        0      0 **127.10.0.0:53**               0.0.0.0:*                   LISTEN
tcp        0      0 **127.0.0.1:53**                0.0.0.0:*                   LISTEN
tcp        0      0 ::1:53                          :::*                        LISTEN
udp        0      0 **127.10.0.1:53**               0.0.0.0:*
udp        0      0 **127.10.0.0:53**               0.0.0.0:*
udp        0      0 **127.0.0.1:53**                0.0.0.0:*
udp        0      0 ::1:53                          :::*
udp        0      0 ::1:5353                        :::*

I was able to get this working finally, but there are a few tricks to doing so. Namely, the GTM always takes the first view match if the source IP is allowed, so "internal" needs to be listed ahead of "external" in DNS -> Zones -> ZoneRunner -> View List.

The other gotcha is each view has its own loopback IP address. This IP will be 127.10.0.X, so be sure to include that IP by itself for each view, otherwise the GTM will not be able to query itself. Here's what the named.conf file would look like when all said and done:

acl "zrd-acl-000-001" {
    127.10.0.1;
};
acl "zrd-acl-000-002" {
    127.10.0.2;
};
acl "rfc_1918" {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
};
view "internal" {
    match-clients {
        "zrd-acl-000-001";
        "rfc_1918";
    };
    allow-transfer {
        "zrd-acl-000-001";
    };
};
view "external" {
    match-clients {
        "zrd-acl-000-002";
        "any";
    };
    allow-transfer {
        "zrd-acl-000-002";
    };        
};

Were you ever able to find a solution? I created a view called 'internal' with 'match-clients' and 'allow-transfer' both set to 'any'. But when attempting to view the RRs I get 01150b21:3: RCODE returned from query: 'NOTAUTH'

Changing the view to 'external' and everything behaves exactly as configured.

My only other thought would be file permissions which you say you've verified. Anything under /var/named should be owned by named. From bash, if you run 'ls -lR', do you see anything not owned by named?

Thanks for your reply Cory.

I can confirm that the behavior happens whether or not the Create Reverse record box is checked (and if there is a reverse zone present or not).

In regards to the latter, I did add an ACL for the internal view to the named.conf. I've tried this with and without that ACL in place, and the issue continues. I opened a support case; just waiting to hear back from the engineer.

Thanks again!

The 'Zone not authoritative during update' message could be because you have the 'Create Reverse Record' checkbox enabled and the reverse zone isn't authoritative (or even created) within ZoneRunner.

It sounds like the NOTAUTH issue could be related to permissions within named.conf. Have you changed any controls or ACLs within your named.conf file?