Here is me again with the same (well, almost) question.
Why CNAMEs does not work in local-data? I mean, unbound
recognizes them and returns them, but it does not expand
them. A stub resolver, when asked for an A record,
expects the returned CNAME record(s) to be expanded to
the final A record, it does not expect to repeat the query
with a new name (the one which CNAME points to).
What's the issue with recursive expanding CNAMEs in local-data?
And lacking that, what's the other way to configure site-
or location-specific overrides for certain names, which
should be CNAMEs (A records don't work due to Kerberos
SPNs).
For example, we've a domain and a few geographically-spread
offices, each office is supposed to have its own proxy, email
server, file server and stuff like that. This is also an
AD DC domain. I thought about a single domain zone and local
overrides for certain commonly used names. But once again
faced this issue with unbound who is unable to resolve
(expand) CNAMEs in local-data or somesuch.
(Yes, I know there's another way, to give each office a
subdomain with the local names specified there, and specify
all other names in the main domain. But that doesn't work
because windows machines always query in its AD Domain
name first, and in DHCP-provided suffix next, - so I have
to override this at the resolver level).
For example, we've a domain and a few geographically-spread
offices, each office is supposed to have its own proxy, email
server, file server and stuff like that. This is also an
AD DC domain. I thought about a single domain zone and local
overrides for certain commonly used names. But once again
faced this issue with unbound who is unable to resolve
(expand) CNAMEs in local-data or somesuch.
(Yes, I know there's another way, to give each office a
subdomain with the local names specified there, and specify
all other names in the main domain. But that doesn't work
because windows machines always query in its AD Domain
name first, and in DHCP-provided suffix next, - so I have
to override this at the resolver level).
Well, MS AD does support location-aware routing. I suggest using that instead of hacking in your own way.
I know how to locate the AD DC closes to the client (site-specific),
that portion works.
Now I want to a) provide a short name (fs) which is used by all our
users to mean their closest local file server, - I can't find a way
to do that in AD. And b) to store user profiles only on the site-
specific server, so home server is different depending on the current
location a user logs in. If a) is solved, b) is solved too. For 2
weeks I tried to implement this in samba, - to discover a ton of
bugs and unexpected behavior. Now I did implement this in DNS, in
a test environment *finally*, - but it turned out I'll have to
replace whole our unbound infrastructure with something else b/c
this very unbound limitation - it can't expand CNAMEs in local-data
and local-zone.
I want it to locate a closest file server given short name.
I'd *love* to do that on the AD side, but so far it didn't work.
And still, there question which I asked: *why* unbound can't
expand CNAMEs in local-data? I'm looking at the source now, -
but with any code which you see for the first time, this is
not exactly a quick thing to do
Did you try with RPZ instead of using local-data inside the config file? Both methods don't give exactly the same results with CNAMEs.
Also, don't forget that you cannot put a CNAME on top of a zone.
And if I want to configure another such name, I'll have to
create another rpz zonefile and another rpz section?
Lemme try... hmm, immediately this file (rpz) has been overwritten,
with contents of example.com zone. It looks like I don't see how
this works, and why it removed the data I've put there.
Or does this need another indirection, to configure this "rpz zone"
on some other primary? And to serve different contents to different
sites, I'll have to configure SEVERAL primaries?
Or am I out of track completely?
I'll try to configure this one test zone in nsd. But this whole
thing quickly becomes unmanageable...
For example, we've a domain and a few geographically-spread
offices, each office is supposed to have its own proxy, email
server, file server and stuff like that. This is also an
AD DC domain. I thought about a single domain zone and local
overrides for certain commonly used names. But once again
faced this issue with unbound who is unable to resolve
(expand) CNAMEs in local-data or somesuch.
Did you try with RPZ instead of using local-data inside the config file? Both methods don't give exactly the same results with CNAMEs.
Also, don't forget that you cannot put a CNAME on top of a zone.
I've never come across RPZ before, haven't heard of it.
But I'm not sure what do you mean here. How is it possible
to use RPZ for this task, to override a name with an (expanded)
CNAME?
For example, in example.com domain I want to add an "fs" CNAME
record pointing to foo.example.com. How would I do that with
RPZ?
That should be a qname trigger, but I'm lost for now about the action.
The zone needs to be a properly formatted zone with SOA and NS records.
localrpz.example.com. 3600 IN SOA elrond.arnor.org. maintainer.mail.com. 2022112113 60 60 432000 60
localrpz.example.com. 3600 IN NS localhost.
fs.example.com 3600 IN CNAME foo.example.com.
fs2.microsoft.com 3600 IN CNAME somewhereelse.mydomain.com.
Notice the absence of a dot after the first term. You can also put it in full, but that's less readable IMO.
You can put as many RPZ as you want, but one might be enough as you can put multiple domains data inside
config would look like this in nsd.
zone:
name: "localrpz.example.com"
zonefile: "rpz/localrpz.example.com"
provide-xfr: 192.0.2.1 NOKEY
And in inbound
rpz:
name: localrpz.example.com
zonefile: /var/unbound/db/localrpz.example.com
allow-notify: 192.0.2.20
master: 192.0.2.20
