DHCP search domain

[Keeper_of_the_Keys]

Hi everyone,

We have our forti setup as DHCP server for our network, it has a search domain defined in the system DNS settings and the DHCP settings for vlans are set to use system default settings, however the search domain is not being passed to clients.

Any ideas?

Tech: 2x 1100E A-A

FortiOS: 7.0.0

config system dns
    set primary x.x.x.x
    set secondary y.y.y.y
    set domain "our.search.domain"
end

config system dhcp server
    edit x
        set dns-service default
        set default-gateway x.x.x.x
        set netmask 255.255.252.0
        set interface "some-interface"
        config ip-range
            edit 1
                set start-ip x.x.x.16
                set end-ip x.x.x.254
            next
        end
   next
end

[lobstercreed]

The system domain is not supposed to be passed to DHCP clients.  You need to specify it as a DHCP option just like you do your DNS servers, etc.

The command according to the config guide is this:

config system dhcp server
    edit x
        set domain "our.search.domain"
   next
end

[Keeper_of_the_Keys]

Hey thanks for your reply!

Why is it logical that the search domain should not be passed?

If I set DNS to be "as system" (in the GUI - results in "set dns-service default" as far as I can tell) then I would expect the search domain to be passed with that after all search domain is an integral part of DNS settings.

I think I'll be opening a bug report on this.

[lobstercreed]

The setting you're referring to is for DNS servers.  I strongly disagree that the search domain (or suffix, in the terminology of DHCP option 15) is an "integral" part of DNS settings. 

I can do everything I want on the Internet without a DNS suffix .  However, I need DNS servers to do almost anything on the Internet.  I can always type the FQDN of the local resource I need and the DNS suffix becomes entirely redundant.

Another reason is you can specify multiple search domains in the FortiGate system settings.  If you had done this, which one should it pass as DHCP option 15 (DNS suffix)?  This is at least one reason why it is not a bug for you to have to specify it in the DHCP server settings.

[Keeper_of_the_Keys]

I agree with you that I don't *need* the suffix for things to function.

That being said the reason I say it is an integral part of it is that these settings are almost always configured at the same time/location (whether on Linux, Windows or macOS) thus one can see/approach them as the same "set" of settings.

As for your point about multiple domains - I can set multiple domains and/or multiple DNS servers, when the setting is to pass on the system default and not have something specific for this DHCP interface/server TBH I expect all DNS settings shown in the 

system default to be passed on including search domain(s) (option 119 - in dhcpd.conf it would be something like this - https://theitdepartment.wordpress.com/2011/08/26/multiple-dns-search-suffixes-in-dhcpd-conf/).

And when the question becomes "which" due to too many options being provided (glibc in the past had a 3 DNS server limit) then it is "the first X supported" unless stated otherwise.

[lobstercreed]

Well I learned something new today, as I had never heard of DHCP option 119 -- only ever used 15.  (Edit: reading a different post seems to indicate Windows support for 119 is actually very, very recent, so that helps explain my unfamiliarity with it)

I don't agree with your other points, but it seems it's largely a matter of preference/experience, and clearly ours differ.  I appreciate the window into another way of thinking about these settings.  :)  Maybe Fortinet support will agree with you (they clearly don't with me, about many things, lol).

[Keeper_of_the_Keys]

We'll see :) I'll be opening a bug report about this and a few other things I find weird today so that I can track progress on them.

(RSSO users being totally unusable in policy unless RSSO is also sending groups, I can't for the life of me wrap my head around that limitation, if the device "knows" the user why is it not usable for making policies)

[gfleming]

Consider a Windows AD environment. You configure your Windows DNS servers with various options and their own search domains. When you configure your Windows DHCP server, you configure individual scopes with their own settings including DNS config.

The FortiGate has its own DNS server and its own DHCP server. Yes you can tell the DHCP server to point clients to the system DNS but this is just telling those clients to poll the FortiGate DNS server for queries.

Think about a guest network. You might want them to use the FortiGate DNS server but you do not want to give then your internal search domain.

Then for your corp network you can still point them to the FortiGate DNS server and include the internal search domain(s) in the config for that DHCP scope.

That's why it is separate and why you might be configuring a search domain multiple times in different spots.

[Jacob74]

I'm very glad I came across this information. While I am still a beginner and have no ideas, but as they will write.

[AlbertSmith]

I can do anything I want on the Internet without a DNS suffix. However, I need DNS servers to do almost everything on the Internet. I can always enter the full domain name of the local resource I want, and the DNS suffix becomes completely unnecessary. I expect the lookup domain to be passed along with this after the entire lookup domain is an integral part of the DNS settings. That said, the reason I say it is an integral part is because these settings are almost always configured at the same time/in the same place (whether in Linux, Windows or macOS) if using html templates, so they can be treated/applied to as the same "set" of settings.