samba - Feb 2013 - BIND9_DLZ CNAME Records Not Resolving from Windows Workstations

Hello,
In an effort to get MX and CNAME records working, I have migrated from
Samba's internal DNS to bind9_dlz. I am now seeing strange behavior where
CNAME records resolve correctly on the S4 DC, but not from workstations.
Please see the case below where I have foo.internal.testdom.com aliased to
google.com using a CNAME record. I do not understand why this is occurring
This should work, correct? Does anyone see something that I am missing? I
am completely stumped and greatly appreciate any input. Thanks, Thomas.

First, I ensure the Windows system and the DC are pointing to the same DNS
server (DC is pointing to itself)...

C:\Users\Admin1>ipconfig /all
Windows IP Configuration
...
   DNS Suffix Search List. . . . . . : internal.testdom.com
...
   DNS Servers . . . . . . . . . . . : 10.1.1.254

[root at DC1 ~]# cat /etc/resolv.conf
nameserver 10.1.1.254
search internal.testdom.com

Just to be sure the Windows workstation is using the correct DNS, I alter
the record for my vpn server to a nonsense IP of 1.2.3.4...

C:\Users\Admin1>ping vpn.internal.testdom.com -n 1
Pinging vpn.internal.testdom.com [1.2.3.4] with 32 bytes of data:
Request timed out.
Ping statistics for 1.2.3.4:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
[root at DC1 ~]# ping vpn.internal.testdom.com -c 1
PING vpn.internal.testdom.com (1.2.3.4) 56(84) bytes of data.
--- vpn.internal.testdom.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 10000ms

Works as expected. Now I test the CNAME on the DC (samba-tool dns query,
dig, ping)...

[root at DC1 ~]# samba-tool dns query dc1 internal.testdom.com foo CNAME
  Name=, Records=1, Children=0
    CNAME: google.com. (flags=f0, serial=62, ttl=0)
[root at dc1 ~]# dig foo.internal.testdom.com CNAME

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>>
foo.internal.testdom.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62924
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;foo.internal.testdom.com.      IN      CNAME

;; ANSWER SECTION:
foo.internal.testdom.com. 0     IN      CNAME   google.com.

;; AUTHORITY SECTION:
internal.testdom.com.   900     IN      NS      dc1.internal.testdom.com.

;; ADDITIONAL SECTION:
dc1.internal.testdom.com. 900 IN     A       10.1.1.254

;; Query time: 2 msec
;; SERVER: 10.1.1.254#53(10.1.1.254)
;; WHEN: Thu Feb 14 21:01:24 2013
;; MSG SIZE  rcvd: 100

[root at DC1 ~]# ping foo.internal.testdom.com -c 1
PING google.com (74.125.228.98) 56(84) bytes of data.
64 bytes from iad23s08-in-f2.1e100.net (74.125.228.98): icmp_seq=1 ttl=54
time=18.6 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 20ms
rtt min/avg/max/mdev = 18.696/18.696/18.696/0.000 ms

Perfect! Now from the Windows workstation.

C:\Users\Admin1>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

C:\Users\Admin1>ping foo.internal.testdom.com
Ping request could not find host foo.internal.testdom.com. Please check the
name
and try again.

-SNIP-

TS> Perfect! Now from the Windows workstation.

C:\Users\Admin1>>ipconfig /flushdns
TS> Windows IP Configuration
TS> Successfully flushed the DNS Resolver Cache.

C:\Users\Admin1>>ping foo.internal.testdom.com
TS> Ping request could not find host foo.internal.testdom.com. Please check
the
TS> name
TS> and try again.

A NSLookup trace would probably be more helpful, than just a non
resolution from ping. Perhaps it won't show us anything, but it might.

---
Provided the nslookup trace show that the server you expect isn't
giving answers, rather than some other problem...

Is BIND configured to answer queries from hosts in the IP
block that the station is in? [See listen-on and allow-query in BIND
docs]


-Greg

Hello Greg,

It was actually the allow-query directive that you noted in your previous
email.

Thanks for your help!


On Fri, Feb 15, 2013 at 2:11 PM, Gregory Sloop <gregs at sloop.net> wrote:
>  -SNIP-
>
>
>
> ---
> Provided the nslookup trace show that the server you expect isn't
> giving answers, rather than some other problem...
>
> Is BIND configured to answer queries from hosts in the IP
> block that the station is in? [See listen-on and allow-query in BIND
> docs]
>
> The server can answer queries from the Windows workstation. This vpn
> resolution test verifies this:
>
> Just to be sure the Windows workstation is using the correct DNS, I alter
> the record for my vpn server to a nonsense IP of 1.2.3.4...
>
> But it's authoritative for that zone. [It has to answer (practically),
by
> definition, for auth zones.]
> That doesn't mean it's going to answer queries for just anyone for
zones
> it's not authoritative for.
>
> I'm no BIND guru, but I think if you do some searches you'll find
there
> are options/changes that will allow it to resolve queries for some hosts
> for non-auth zones.
> I wish I could tell you just what options to change, but I've run into
> this kind of thing before and I'm pretty sure it's a BIND config
issue -
> and that BIND isn't configured to answer queries to hosts other than
itself
> for non-auth zones.
>
> -Greg
>