[snip]
Is this really necessary? We're not talking about a shell
commandline
here, but an array of null terminated strings. If it's a restriction
placed by dnsmasq itself, then we should just disallow ' ' during
parsing rather than silently changing it, to avoid surprises.
Well, I've been thinking about this a little bit more and I guess it
*may* be better either to fail with some libvirt's virterror saying that
spaces are not allowed in the TXT record name and value or to change the
spaces to dashes (-) instead of undescores (_) - I guess this looks better.
Also, if we add support for configuring other DNS related things we
should consider:
1) TXT records
2) SRV records
3) PTR records
4) NAPTR records
5) CNAME records
which is basically adding 5 new DNS records only since I see no point in
changing port, query-port and edns UDP packet max size and as I already
mentioned this patch should be about DNS options only and the rest of
the options should be covered by a separate patch so this should be
adding only the DNS records AFAIK.
Also, I've been talking to Jirka Denemark (jdenemar) about this and he
told me some time ago somebody wanted to pass arguments directly to XML
file and spawn dnsmasq with them which would, on the one hand, add
"flexibility" by directly setting up the parameters to the dnsmasq
however this is the implementation issue since if we change usage of
dnsmasq to usage of something else with some other parameters it would
be fail because it won't be compatible so I guess adding design like:
<dns>
<txt ...>
...
</dns>
would be much better than having dnsmasq arguments directly in the XML.
So basically having some new elements like:
<dns>
<txt name="some-name" value="some-value" />
<srv service="_service" prot="_prot" domain="domain"
target="target"
port="port" priority="priority" weight="weight" />
<ptr name="name" target="target" />
<naptr name="name" order="order" preference="pref"
flags="flags"
service="svc" regexp="re" replacement="rep" />
<cname cname="cname" target="target" />
</dns>
would serve the purpose of this.
What do you think about such an implementation? Would this be good for
v2 of the patch? :)
Thanks,
Michal
--
Michal Novotny <minovotn(a)redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat