Hi Greg,
I have the same configuration and the same issue as yours. Actually
nothing is wrong if you understand how bind works under the hood.
I asked the same question twice in the past. No body understands our
question.
See my comments below. Hope you get the question answered.
On 12/8/2022 3:02 PM, Greg Sloop <gregs--- via samba
wrote:> Looking for general theory here - perhaps this will devolve into more
"how
> to" later, but right now I need overall understanding.
>
> We handle DHCP outside AD. We also do DDNS there, and handle DNS lookups.
>
> Here's what the current setup looks like
>
> We have a pair of DHCP servers (ISC DHCPD) and those same boxes handle DNS
> for the network. They're in the DNS domain of, lets say; xyz.local.
(Yes,
> we're using local. Can't easily dig it out. We'll live with any
AVAHI
> side-effects, I think - at least for now.)
>
> The AD domain is ad.xyz.local. (so a server is something like
> s1.ad.xyz.local)
So we ended up with two FQDN names for one PC/server:? s1.xyz.local and
s1.ad.xyz.local. Somebody told me it *is* a problem, but I don't see any
problems so far.> The DHCP/DNS servers handle multiple ip subnets and setup the forwards and
> reverses for dhcp leases - into the xyz.local domain.
This is OKay. It is not related to AD.>
> These xyz.local BIND servers forward all queries about *.ad.xyz.local to
> the AD servers, so queries about the AD domain get handled properly. All
> non AD queries they handle internally - recursively or not.
Correct.>
> However, we also get DDNS entries into AD. (I've never set this up,
> explicitly, up this, so it's happening "automagically.")
> Something like station-1.ad.xyz.local.
Yes, you don't need to set up anything. If a PC is in the AD domain, it
will do it by itself.> But we'll sometimes end up with mismatches between the ad and non-ad
> forwards/reverses. (station1.ad.xyz.local points to a "wrong" ip,
where
> station1.xyz.local doesn't)
We do get a mismatch when ip changes. This is because our PC uses the
bind server as the DNS server, and the bind server caches it. You have
to wait for the TTL to elapse. AD has the default to 20 minutes(I
think). So your bind server holds the ip for 20 minutes, then asks the
AD to get the new ip.>
> So, the base question is;
> Is there any reason for us to worry about ad.xyz.local DDNS entries being
> "correct" in AD's DNS entries?
Now you know why this happens.>
> I suppose if we share resources via AD for a host that gets a DHCP
> addresses, and we references those resources via name, we'll have
issues.
> But outside of that case, is there any reason to try to keep the
> ad.xyz.local forwards "correct?"
There is no solution. This is how DNS works. Just like if we change the
ip for a public web site, the whole world needs to wait for the TTL to
finish to see your new ip.>
> If I can live with DNS lookups like station1.xyz.local - can I just ignore
> the DDNS entries in AD for stations? (Without dire outcomes somewhere that
> I haven't considered.)
station1.xyz.local or station1.ad.xyz.local? It is hard to choose.
What I can see is:
1. if station1 is powered off for some time, station1.xyz.local will
disappear from DDNS, but station1.ad.xyz.local is still resolvable. I
don't know how long AD will keep it resolvable.
2. if ip changes, station1.xyz.local will work, and
station1.ad.xyz.local will work after within 20 minutes.
>
> Thoughts?
> Is there a wiki article that covers this? (I didn't find one and I
can't
> easily find a discussion thread that seems closely relevant.
One solution is to change the order of your DNS server: your PC's DNS
points to AD, and AD forwards queries to your bind server. But I don't
this: how do you deal with the DDNS and the ip change of AD?
Otherwise just use static IP for your station1 or server.
Allen