Hi Adam, thanks for the prompt reply.
This functionality already (mostly) exists. My patch, which switched
> something to use host-record instead, did not remove the existing
> functionality. (...)
Now I notice that I linked to your patch in my email, but forgot to mention
the relation between your patch and my proposed patch.
> Specifically there's this configuration structure:
>
> config 'domain'
> option 'name' 'typhoon'
> option 'ip' '192.168.1.140'
>
> This is parsed with the following function in the current dnsmasq.init:
>
> dhcp_domain_add() {
> (...)
}
(...)
Your patch seems to be nearly identical except you are adding the domain to
> the end. I'm not sure I see the need to have a nearly identical function to
> append the domain to the end.
As you notice, the function I added (dhcp_address_add) is nearly identical
to dhcp_domain_add, as it's based on it, and also on a chunk (the "fqdn"
part) of a version previous to r36943.
The reason or motivation for creating this new dhcp_address_add function
was to keep some separation of concerns. I knew I could have used
dhcp_domain_add, as I did a few months ago [1].
But then, it seems to me that (ab)using dhcp_domain_add just because it
generates the same output wasn't a correct solution.
Also, dhcp_domain_add expects a "domain" config, not a "host" config. Even
if both config objects are similar (if not identical), I preferred to keep
the code more future-proof (and, again, go for some SoC).
So, instead, a new dhcp_address_add function would fit better and the
purpose of it even clearer, as it relates to corresponding option
(--address), and it expects a "host" object as a parameter.
[1] https://dev.openwrt.org/ticket/12722
Wouldn't it be easier to define it as such:
> config 'domain'
> option 'name' 'typhoon.domain.name'
> option 'ip' '192.168.1.140'
> That would accomplish the same thing using existing functionality.
>
Problem I see is that 'domain' is different from 'host', both as concept
and as a configuration option in dnsmasq (and in a OpenWRT config file &
GUI). Domain is a manually configured, LAN-wide setting, while my patch is
after dynamically setting the "--address" option for each 'host' defined on
/etc/config/dhcp.
Take into consideration that the main (only?) goal of this patch is to
solve wildcard subdomain requests for hostnames (static leases) in LAN.
> Regarding the wildcards, are you really looking to resolve, in keeping
> with the above example:
> *.typhoon.domain.name --> 192.168.1.140
> So, essentially, everything possible, that ends in typhoon.domain.name to
> 192.168.1.140?
Yes, that's the goal of this patch, as this functionality brings, for
example, the possibility of easily working with virtual hosts on different
webservers across the LAN.
Even more, the dnsmasq man page states that that's the functionality of the
--address option:
"Specify an IP address to return for any host in the given
domains."
(example: myhost.domain.com)
Which could be reworded:
"Specify an IP address to return for any (virtual) host in the
given (sub)domains."
(example: projectA.mywebserver.domain.lan)
Keep in mind that using --address does not get you the proper reverse DNS
> records, only A records are created.
>
Adam, I must admit that I totally ignore the consequences of this (not
having a proper reverse DNS records), particularly on a humble LAN setup.
I will really appreciate you shedding some light.
--
Julián
PS: sorry for the long reply, English is not my primary language and I tend
to be overly verbose when trying to explain :)
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
