Top posting.
?
I'm puzzled.
I note, specifically, that ALL dns queries for the 3rd level domain that AD is
in, get forwarded to the AD internal DNS servers.
?
It's not that DNS lookups are failing, but that the *DDNS* records for
stations aren't updated in AD.
(So a AD joined station moves from one subnet to another, or gets a new IP lease
on a different IP, but the *DDNS* A record (in AD only) doesn't get updated
to point at the new lease it got from the non-AD-aware DHCP server.)
?
So, lets just assume I want to "fix" this - and ignore if I *should*
or not.
You suggest that clients could update their AD records on their own. (Not having
DHCPD do so.)
Can you point me at a wiki article that describes how to do this?
?
[I'm worried that we don't understand each other well, and that you
misunderstand what's going on, due to your saying I should point all AD dns
queries to AD DNS servers, which I'm already doing.]
-Greg
> On 16/12/2022 18:02, Greg Sloop <gregs--- via samba wrote:
>> Bump.
>> Anyone?
>>> On Thu, Dec 8, 2022 at 12:02 PM Greg Sloop <gregs at
sloop.net> <
gregs at sloop.net>>> 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)
>>> The DHCP/DNS servers handle multiple ip subnets and setup the
forwards and
>>> reverses for dhcp leases - into the xyz.local domain.
>>> 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.
>>> 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.
>>> 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)
>>> 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?
>>> 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?"
>>> 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.)
>>> 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.
> Your problem is that, whilst you may ignore the dns records in AD, your
domain clients might not. You have seen that your clients are trying to update
their records in AD (you can turn this off), they will also be doing other
things under the hood.
> I have always suggested that if you are going to use an external dns
server, this server should always forward anything for the AD domain to an AD
DC. This way, you do not get any problems. If you check on the internet for AD
problems, there are long running responses, 'it is DNS' or 'it was
DNS'.
> Rowland
?