Für solche split-horizon Konfigurationen verwendet man i.d.r. Views; allerdings würde ich diese dringend auf lokale Zonen begrenzen und niemals mit öffentlichen Zonen vermischen! Das endet meist im Chaos und erschwert debugging erheblich!
Die searchdomain wird _nur_ angehängt, wenn kein fqdn gesucht wird (=kein Punkt im suchstring). bei "search domain.tld" in der /etc/resolv.conf wird aus "host" "host.domain.tld" aber niemals aus "host.domain.tld" ein "host.domain.tld.domain.tld" - das wäre völliger humbug und würde DNS komplett unbrauchbar machen. I.d.r setzt man "search" auf eine lokale zone (company.lan), nicht auf eine öffentliche zone - sonst landen u.U. haufenweise queries nach lokalen hosts offen im internet und ggf sogar bei NS aus übergeordneten zonen; ausser man nutzt die selbe domain auch komplett im internen Netz mit lokalen resolvern/nameservern, was auch relativ schnell ziemlich haarig wird, speziell wenn nicht alles wirklich auch 'lokal' erreichbar ist und/oder manche Dienste intern und extern mit der selben url/fqdn erreichbar sind. Zudem verwischt man sich jegliche "Lesbare" Unterscheidung zwischen lokalen Netzen/Servern/Diensten und öffentlich zugänglichen Netzen/Servern/Diensten, was IMHO ein ziemliches sicherheitsrisiko darstellt.
In deinem Fall würde ich einfach bei Einwahl ins VPN auch den internen NS am Client setzen lassen (10.0.100.2), der für die lokalen Subnetze (also bei dir aus 10.0.100/24) authorativ ist. Dieser kann innerhalb des privaten Netzes auch problemlos als authorativer NS für die example.tld zone gesetzt werden, um z.b. ldap.example.tld zu beantworten.
Für die extern erreichbare zone + subnetz bleibt weiterhin auch der externe NS authorativ, der aber auch nur in öffentlich routbare IPs auflöst! RFC1819-Adressen sind explizit nur innerhalb lokaler Netze zulässig, somit darf auch kein öffentlich zugänglicher NS solche Adressen zurückgeben.
Mittels views kann/können die selben Server für die internen und externen Zonen zuständig sein. Mittels ACLs (z.b. IP-range 10.0.100/24) wird entschieden in welchem view ein query ausgeführt wird; lokal oder öffentlich.
Ich nutze views hier um in verschiedenen VLANs und Niederlassungen z.B. mit identischen Hostnamen für generische Dienste arbeiten zu können. So wird z.b. für ntp.domain.loc in jedem VLAN und jeder Niederlassung der jeweils lokale bzw im selben subnet befindliche NTP-server aufgelöst oder, falls nur einmal vorhanden, z.b. die IP des entsprechenden Servers in der DMZ am Hauptstandort.
Kurznamen werden nur per CNAME definiert, nie direkt mit IP - im Hintergrund wird alles hierarchisch in eigenen zonen verwaltet: <hostname>.<netz>.<standort>.<localdomain>.lan; also z.b. ns1.wlan.a.localdomain.lan ist der primäre NS für das wlan an standort a - die clients in diesem Netz lösen aber einfach nur ns1.localdomain.lan auf, was in deren view ein CNAME auf den genannten langen fqdn ist.
DNS ist ein hierarchischer dienst; man sollte ihn also auch so nutzen um die logischen Strukturen abzubilden und nicht alles krampfhaft direkt in der domain-zone zusammenwursten - und erst recht nicht globale und lokale Adressen vermischen!
Für externe domains sind ausschließlich unsere externen NS zuständig; das Subnetz das hier lokal von unserem AS announced wird und in das einige Einträge in den öffentlichen zonen aufgelöst werden, bleibt beim routing hier intern aber immer komplett von lokalen netzen isoliert; was dann auch immer durch die domainnamen sofort ersichtlich ist. Ich würde wahnsinnig werden wenn z.b. lokaler und externer mailserver in den logs mit dem selben fqdn auftauchen würden, weil lokal die selbe domain genutzt wird.
Zur eigentlichen Frage: Subdomain und Hostnamen können natürlich identisch sein; es können auch beliebige weitere Subdomains angelegt werden, was meistens wesentlich sinnvoller ist.
So habe ich auch meine "private" externe Infrastruktur im DNS logisch/hierarchisch komplett unterteilt um schnell und einfach zuordnen zu können wo sich was befindet. Als Schema kommt bei mir [jail|dienst].hostname.region.land.domain.tld zum Einsatz: Z.B. postfix.prometheus.fra1.de.domain.tld ist ein jail mit Hostname "postfix" (=Dienst der darin läuft) auf host (=server/VPS) prometheus im DC FRA1, Deutschland und gehört zu domain.tld.
Der host ist ganz normal per prometheus.fra1.de.domain.tld erreichbar.
Diese hierarchische Unterteilung vermeidet auch kollisionen bei SSL-Zertifikaten von Let's Encrypt und man kann die access tokens z.b. für die DNS-API zum erneuern der Zertifikate stark begrenzen - kein Host hat per API zugriff auf die übergeordnete Zone, immer nur auf eine möglichst tiefe subdomain (i.d.r. den hostnamen). Die höchste zone (domain.tld) wird nur manuell von mir verwaltet.
Das was dann von Menschen oder Usern (ja,
oder 
) per URL erreicht werden soll, bekommt einfach einen CNAME direkt in der primären zone; also z.B. webmail.domain.tld CNAME squirrelmail.atlas.ams2.nl.domain.tld. Das macht load-balancing, migrationen und updates wesentlich einfacher.
