samba - Oct 2024 - AD/DNS: Cannot Create a CNAME record with a blank name...

On 10/12/24 13:33, Kees van Vloten via samba wrote:
>
> On 12-10-2024 17:15, John R. Graham via samba wrote:
>>
>> ...
>>
>> A question for you (and perhaps Rowland). Would creating a zone of 
>> just "example.com"? _without_ the "samdom"
subdomain and then
>> creating DNS records with the individual machine names not work for 
>> some structural reason? For example:
>>
>> ~ # samba-tool dns zonecreate localhost "example.com" -U
administrator
>> ~ # samba-tool dns add localhost example.com myserver 
>> CNAME?myserver.samdom.example.com -U administrator
>> ~ # samba-tool dns add localhost example.com myotherserver 
>> CNAME?myotherserver.samdom.example.com -U administrator
>>
> Your internal machine will do DNS queries at your DC first. So indeed 
> this will provide a different DNS view for internal machines, and they 
> will never resolve to any of the externally known *.example.com domains.
>
> It is totally valid to do something like this, bind9 even provides the 
> concept of dns-views, a. o. for this reason.
>
> I am using it to provide different (internal) IPs for the externally 
> known domain-name of my environment. With this mobile devices which 
> sometimes connect over internet and sometimes over the LAN / wifi can 
> use the same DNS-name to connect to services (e.g. email) but they 
> resolve differently depending on their location.
>
> Do note that you have to set the TTL pretty low so that they won't use 
> a cached result after changing location from internal to external or 
> vice-versa. In order to allow samba-tool to set a TTL on a DNS record 
> I have made a small patch. I can share it if that has any value for you.
>
> - Kees.
>
>> This would have the advantage that a single dummy zone would be able 
>> to contain aliases for _all_ externally visible machines. (I
haven't
>> tried this yet; it just occurred to me...and struck me as being 
>> "tidier".)
>>
>> ...
>>
It turns that the scheme that I asked about above *doesn't* do what I 
hoped it might. Creating an "example.com" zone and then a CNAME record
that maps between the external name and the internal one for my server 
does indeed work, but the existence of the "example.com" zone also 
blocks resolution of the names of all the externally hosted machines 
that have URLs that end in "example.com". (Just as one example, my
mail
server is externally hosted.) This is probably just Samba behaving as 
designed, namely that it's designed to be authoritative for the zones 
that it manages.

So this leads me to *another* question. If my surmise is correct, would 
it be considered a worthwhile feature to add an attribute to a zone 
record so that a zone could be declared--I'm not exactly sure what the 
term should be--selectively authoritative? The behavior being, if a DNS 
records exists in the zone, then use it; otherwise, forward the request 
to upstream DNS and then use that result?

The reason I think this might be a reasonable and worthwhile feature is 
because the wiki describes a "trick" that has apparently already
ceased
to function *once*. It's good for me that an alternative embodiment of 
the trick is still available, but it also might one day cease to work. 
Relying on documented features and behavior is always preferred.

On Mon, 14 Oct 2024 10:09:14 -0400
"John R. Graham via samba" <samba at lists.samba.org> wrote:
> It turns that the scheme that I asked about above *doesn't* do what I 
> hoped it might. Creating an "example.com" zone and then a CNAME
> record that maps between the external name and the internal one for
> my server does indeed work, but the existence of the
"example.com"
> zone also blocks resolution of the names of all the externally hosted
> machines that have URLs that end in "example.com". (Just as one
> example, my mail server is externally hosted.) This is probably just
> Samba behaving as designed, namely that it's designed to be
> authoritative for the zones that it manages.
> 
> So this leads me to *another* question. If my surmise is correct,
> would it be considered a worthwhile feature to add an attribute to a
> zone record so that a zone could be declared--I'm not exactly sure
> what the term should be--selectively authoritative? The behavior
> being, if a DNS records exists in the zone, then use it; otherwise,
> forward the request to upstream DNS and then use that result?
The problem with that idea is that Microsoft would also have to accept
it and they probably wouldn't.
> 
> The reason I think this might be a reasonable and worthwhile feature
> is because the wiki describes a "trick" that has apparently
already
> ceased to function *once*. It's good for me that an alternative
> embodiment of the trick is still available, but it also might one day
> cease to work. Relying on documented features and behavior is always
> preferred.
Well a trick is just that, a trick (aka workaround), now we know it
doesn't work, I will remove it from the wiki.

Rowland
> 
>

Op 14-10-2024 om 16:09 schreef John R. Graham via samba:
> On 10/12/24 13:33, Kees van Vloten via samba wrote:
>>
>> On 12-10-2024 17:15, John R. Graham via samba wrote:
>>>
>>> ...
>>>
>>> A question for you (and perhaps Rowland). Would creating a zone of 
>>> just "example.com"? _without_ the "samdom"
subdomain and then
>>> creating DNS records with the individual machine names not work for
>>> some structural reason? For example:
>>>
>>> ~ # samba-tool dns zonecreate localhost "example.com" -U
administrator
>>> ~ # samba-tool dns add localhost example.com myserver 
>>> CNAME?myserver.samdom.example.com -U administrator
>>> ~ # samba-tool dns add localhost example.com myotherserver 
>>> CNAME?myotherserver.samdom.example.com -U administrator
>>>
>> Your internal machine will do DNS queries at your DC first. So indeed 
>> this will provide a different DNS view for internal machines, and 
>> they will never resolve to any of the externally known *.example.com 
>> domains.
>>
>> It is totally valid to do something like this, bind9 even provides 
>> the concept of dns-views, a. o. for this reason.
>>
>> I am using it to provide different (internal) IPs for the externally 
>> known domain-name of my environment. With this mobile devices which 
>> sometimes connect over internet and sometimes over the LAN / wifi can 
>> use the same DNS-name to connect to services (e.g. email) but they 
>> resolve differently depending on their location.
>>
>> Do note that you have to set the TTL pretty low so that they won't 
>> use a cached result after changing location from internal to external 
>> or vice-versa. In order to allow samba-tool to set a TTL on a DNS 
>> record I have made a small patch. I can share it if that has any 
>> value for you.
>>
>> - Kees.
>>
>>> This would have the advantage that a single dummy zone would be
able
>>> to contain aliases for _all_ externally visible machines. (I
haven't
>>> tried this yet; it just occurred to me...and struck me as being 
>>> "tidier".)
>>>
>>> ...
>>>
> It turns that the scheme that I asked about above *doesn't* do what I 
> hoped it might. Creating an "example.com" zone and then a CNAME
record
> that maps between the external name and the internal one for my server 
> does indeed work, but the existence of the "example.com" zone
also
> blocks resolution of the names of all the externally hosted machines 
> that have URLs that end in "example.com". (Just as one example,
my
> mail server is externally hosted.) This is probably just Samba 
> behaving as designed, namely that it's designed to be authoritative 
> for the zones that it manages.
If you use Bind on the DC with bind-dlz to interface with Samba, you can 
choose where to put the example.com zone. You can put it in AD with 
samba-tool (as you did now) but you can also decide to host it in Bind 
directly (in /etc/bind/named.conf.local). Bind has all the options you 
are looking for. You just have to take care of replication over the DCs 
yourself.

- Kees.
>
> So this leads me to *another* question. If my surmise is correct, 
> would it be considered a worthwhile feature to add an attribute to a 
> zone record so that a zone could be declared--I'm not exactly sure 
> what the term should be--selectively authoritative? The behavior 
> being, if a DNS records exists in the zone, then use it; otherwise, 
> forward the request to upstream DNS and then use that result?
>
> The reason I think this might be a reasonable and worthwhile feature 
> is because the wiki describes a "trick" that has apparently
already
> ceased to function *once*. It's good for me that an alternative 
> embodiment of the trick is still available, but it also might one day 
> cease to work. Relying on documented features and behavior is always 
> preferred.
>
>