[libvirt] [PATCH] Add support for DNS TXT records

Hi, this is the patch to add DNS TXT record support to libvirt networking driver since this is feature that's supported by DNSMasq that's being used by the bridge driver. Maybe you fail to understand the reasons why to implement such a feature however it's a good thing IMHO since user could provide some information in the DNS TXT record headers. The headers are, of course, configurable in the network XML description and the idea got to me when I was reading an article about DKIM (DomainKeys Identified Mail) since it's using TXT records in the DNS to provide the public keys. This inspired me to implement the DNS TXT record support to libvirt bridge driver to allow users expose some information to the guest if they want to do so etc. Limitations: - Records names and values containing space (' ') arguments are altered to change spaces to underscores ('_'). This is because of proper argument handling when spawning dnsmasq. Technical details: The --txt-record argument should be supported by all version of DNSMasq which allows us to use it in all of the cases for the libvirt bridge driver. The only thing user has to do is to edit the network XML description in libvirt and append: <dns> <txt_record name='some name' value='some value' /> </dns> after the DHCP elements of network IP (<ip>) tree. After creating such a definition user has to restart this virtual network for changes to take effect, i.e. to spawn DNSMasq with new --txt-record arguments. User can confirm the proper configuration of DNS TXT records both by looking to the dnsmasq command-line (i.e. `ps aux | grep dnsmasq`) where information about --txt-record=some_name,some_value should be present or test it in the host/guest itself by digging the TXT record from there, i.e. using `dig TXT some_name @ip` from the host (since the it's running on the @ip and not the gateway for host) or `dig TXT some_name` from the guest where the value "some_value" should be output in both cases. This has been developed and tested on Fedora i386 box and everything was working fine. Michal Signed-off-by: Michal Novotny <minovotn@redhat.com> --- src/conf/network_conf.c | 64 +++++++++++++++++++++++++++++++++++++++++++ src/conf/network_conf.h | 16 +++++++++++ src/network/bridge_driver.c | 28 +++++++++++++++++++ 3 files changed, 108 insertions(+), 0 deletions(-) diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c index dcab9de..3e07496 100644 --- a/src/conf/network_conf.c +++ b/src/conf/network_conf.c @@ -435,6 +435,53 @@ virNetworkDHCPRangeDefParseXML(const char *networkName, } static int +virNetworkDNSDefParseXML(virNetworkIpDefPtr def, + xmlNodePtr node) +{ + + xmlNodePtr cur; + + if (VIR_ALLOC(def->dns)) { + virReportOOMError(); + return -1; + } + + cur = node->children; + while (cur != NULL) { + if (cur->type == XML_ELEMENT_NODE && + xmlStrEqual(cur->name, BAD_CAST "txt_record")) { + char *name, *value; + + if (!(name = virXMLPropString(cur, "name"))) { + cur = cur->next; + continue; + } + if (!(value = virXMLPropString(cur, "value"))) { + VIR_FREE(name); + cur = cur->next; + continue; + } + + if (VIR_REALLOC_N(def->dns->txtrecords, def->dns->ntxtrecords + 1) < 0) { + virReportOOMError(); + return -1; + } + + def->dns->txtrecords[def->dns->ntxtrecords].name = strdup(name); + def->dns->txtrecords[def->dns->ntxtrecords].value = strdup(value); + def->dns->ntxtrecords++; + + VIR_FREE(name); + VIR_FREE(value); + } + + cur = cur->next; + } + + return 0; +} + +static int virNetworkIPParseXML(const char *networkName, virNetworkIpDefPtr def, xmlNodePtr node, @@ -550,6 +597,12 @@ virNetworkIPParseXML(const char *networkName, goto error; } else if (cur->type == XML_ELEMENT_NODE && + xmlStrEqual(cur->name, BAD_CAST "dns")) { + result = virNetworkDNSDefParseXML(def, cur); + if (result) + goto error; + + } else if (cur->type == XML_ELEMENT_NODE && xmlStrEqual(cur->name, BAD_CAST "tftp")) { char *root; @@ -828,6 +881,17 @@ virNetworkIpDefFormat(virBufferPtr buf, virBufferAddLit(buf, " </dhcp>\n"); } + if ((def->dns != NULL) && (def->dns->ntxtrecords)) { + int ii; + + virBufferAddLit(buf, " <dns>\n"); + for (ii = 0 ; ii < def->dns->ntxtrecords ; ii++) { + virBufferVSprintf(buf, " <txt_record name='%s' value='%s' />\n", + def->dns->txtrecords[ii].name, + def->dns->txtrecords[ii].value); + } + virBufferAddLit(buf, " </dns>\n"); + } virBufferAddLit(buf, " </ip>\n"); diff --git a/src/conf/network_conf.h b/src/conf/network_conf.h index 281124b..5f47595 100644 --- a/src/conf/network_conf.h +++ b/src/conf/network_conf.h @@ -57,6 +57,20 @@ struct _virNetworkDHCPHostDef { virSocketAddr ip; }; +typedef struct _virNetworkDNSTxtRecordsDef virNetworkDNSTxtRecordsDef; +typedef virNetworkDNSTxtRecordsDef *virNetworkDNSTxtRecordsDefPtr; +struct _virNetworkDNSTxtRecordsDef { + char *name; + char *value; +}; + +struct virNetworkDNSDef { + unsigned int ntxtrecords; + virNetworkDNSTxtRecordsDefPtr txtrecords; +} virNetworkDNSDef; + +typedef struct virNetworkDNSDef *virNetworkDNSDefPtr; + typedef struct _virNetworkIpDef virNetworkIpDef; typedef virNetworkIpDef *virNetworkIpDefPtr; struct _virNetworkIpDef { @@ -75,6 +89,8 @@ struct _virNetworkIpDef { unsigned int nranges; /* Zero or more dhcp ranges */ virNetworkDHCPRangeDefPtr ranges; + virNetworkDNSDefPtr dns; /* DNS related settings for DNSMasq */ + unsigned int nhosts; /* Zero or more dhcp hosts */ virNetworkDHCPHostDefPtr hosts; diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index c30620a..89c1431 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -442,6 +442,19 @@ networkSaveDnsmasqHostsfile(virNetworkIpDefPtr ipdef, return 0; } +static char * +replace_all(char *input, int chr1, int chr2) +{ + int pos; + char *tmp; + char *out; + + out = strdup(input); + while ((tmp = strchr(out, chr1)) != NULL) + out[ strlen(input) - strlen(tmp) ] = chr2; + + return out; +} static int networkBuildDnsmasqArgv(virNetworkObjPtr network, @@ -497,6 +510,21 @@ networkBuildDnsmasqArgv(virNetworkObjPtr network, if (network->def->forwardType == VIR_NETWORK_FORWARD_NONE) virCommandAddArg(cmd, "--dhcp-option=3"); + if (ipdef->dns != NULL) { + int i; + + for (i = 0; i < ipdef->dns->ntxtrecords; i++) { + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferVSprintf(&buf, "%s,%s", + replace_all(ipdef->dns->txtrecords[i].name, ' ', '_'), + replace_all(ipdef->dns->txtrecords[i].value, ' ', '_')); + + virCommandAddArgPair(cmd, "--txt-record", virBufferContentAndReset(&buf)); + VIR_FREE(buf); + } + } + /* * --interface does not actually work with dnsmasq < 2.47, * due to DAD for ipv6 addresses on the interface. -- 1.7.3.2

I haven't had time yet to look at the code in detail, but thought I should send this preliminary commentary. On 03/24/2011 09:58 AM, Michal Novotny wrote:
Hi, this is the patch to add DNS TXT record support to libvirt networking driver since this is feature that's supported by DNSMasq that's being used by the bridge driver.
Maybe you fail to understand the reasons why to implement such a feature however it's a good thing IMHO since user could provide some information in the DNS TXT record headers.
As a matter of fact, I think that not only is this useful, but configuring other capabilities presented by dnsmasq would be good. I think you'll find a kindred spirit in Paweł Krześniak, who was also wanting some other dnsmasq capabilities exposed (I forget which now).
The headers are, of course, configurable in the network XML description and the idea got to me when I was reading an article about DKIM (DomainKeys Identified Mail) since it's using TXT records in the DNS to provide the public keys. This inspired me to implement the DNS TXT record support to libvirt bridge driver to allow users expose some information to the guest if they want to do so etc.
Limitations: - Records names and values containing space (' ') arguments are altered to change spaces to underscores ('_'). This is because of proper argument handling when spawning dnsmasq.
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.
Technical details:
The --txt-record argument should be supported by all version of DNSMasq which allows us to use it in all of the cases for the libvirt bridge driver. The only thing user has to do is to edit the network XML description in libvirt and append:
<dns> <txt_record name='some name' value='some value' /> </dns>
I was told awhile back that putting underscores in XML element names was strongly frowned upon (although there are certainly already examples of it in libvirt xml). Also, it would be really nice (especially it would make Eric happy :-) if you included with your patch some changes to docs/formatnetwork.html.in to add this to the documentation. Have you thought about how this config model would apply to adding the other dns-related stuff that can be done with dnsmasq. It would be unfortunate if we took this first step and it turned out to not be a good match for the natural followons. Maybe we should take a short bit of time to consider the larger picture to make sure we'lll be able to easily and logically add the other stuff later (this might be the right way, I just haven't had time yet to think about it)
after the DHCP elements of network IP (<ip>) tree. After creating such a definition user has to restart this virtual network for changes to take effect, i.e. to spawn DNSMasq with new --txt-record arguments.
User can confirm the proper configuration of DNS TXT records both by looking to the dnsmasq command-line (i.e. `ps aux | grep dnsmasq`) where information about --txt-record=some_name,some_value should be present or test it in the host/guest itself by digging the TXT record from there, i.e. using `dig TXT some_name @ip` from the host (since the it's running on the @ip and not the gateway for host) or `dig TXT some_name` from the guest where the value "some_value" should be output in both cases.
This has been developed and tested on Fedora i386 box and everything was working fine.

Hi Laine, thanks for your reply. Comments inline... On 03/25/2011 10:02 PM, Laine Stump wrote:
I haven't had time yet to look at the code in detail, but thought I should send this preliminary commentary.
Hi, this is the patch to add DNS TXT record support to libvirt networking driver since this is feature that's supported by DNSMasq that's being used by the bridge driver.
Maybe you fail to understand the reasons why to implement such a feature however it's a good thing IMHO since user could provide some information in the DNS TXT record headers. As a matter of fact, I think that not only is this useful, but configuring other capabilities presented by dnsmasq would be good. I
On 03/24/2011 09:58 AM, Michal Novotny wrote: think you'll find a kindred spirit in Paweł Krześniak, who was also wanting some other dnsmasq capabilities exposed (I forget which now).
Well, I have to agree that there are some options/capabilities that would be good to be configurable. Now, the dnsmasq command line is: /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override where only listen-address and just some DHCP related options are configurable using the XML -> like dhcp-range, I don't know whether we need to configure lease file and dhcp-lease-max value is being configurable indirectly since if we have the 192.168.122.0/24 network (defined by gateway IP address of 192.168.122.1, netmask of 255.255.255.0 and dhcp range from .2 to .254 because of reserved IP addresses) we can easily calculate the DHCP lease max value. The option that would be worth considering to be configurable could be --dhcp-no-override option for this but I don't know whether this could be useful. There's the description from DNSMasq man page: --dhcp-no-override Disable re-use of the DHCP servername and filename fields as extra option space. If it can, dnsmasq moves the boot server and filename information (from dhcp-boot) out of their dedicated fields into DHCP options. This make extra space available in the DHCP packet for options but can, rarely, confuse old or broken clients. This flag forces "simple and safe" behaviour to avoid problems in such a case. So I don't know whether we really need this configurable although it may be a good thing. For other DNSMasq option it may be good to make --local-ttl (and/or --neg-ttl) and maybe --strict-order configurable but I don't know how good it could be for the options. If we make some kind of default value and make this optional this could be good however we don't want to dump everything in the XML (if set to default for libvirt network) since we don't want our XML to be extra-complex AFAIK (and DNSMasq is having really many argument options).
The headers are, of course, configurable in the network XML description and the idea got to me when I was reading an article about DKIM (DomainKeys Identified Mail) since it's using TXT records in the DNS to provide the public keys. This inspired me to implement the DNS TXT record support to libvirt bridge driver to allow users expose some information to the guest if they want to do so etc.
Limitations: - Records names and values containing space (' ') arguments are altered to change spaces to underscores ('_'). This is because of proper argument handling when spawning dnsmasq.
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, that's the reason since if we quote this we can't use dig to dig it correctly without the quotes. This was simply the way to disallow ' ' by changing it to underscores since I didn't want the definition to fail because of this.
Technical details:
The --txt-record argument should be supported by all version of DNSMasq which allows us to use it in all of the cases for the libvirt bridge driver. The only thing user has to do is to edit the network XML description in libvirt and append:
<dns> <txt_record name='some name' value='some value' /> </dns>
I was told awhile back that putting underscores in XML element names was strongly frowned upon (although there are certainly already examples of it in libvirt xml).
Well, there are some of them used in libvirt XML files and that's why I used them. Do you think I'd rather change it not to use it and trim from "txt_record" just to "txt" ?
Also, it would be really nice (especially it would make Eric happy :-) if you included with your patch some changes to docs/formatnetwork.html.in to add this to the documentation.
Good point. I'll add it there once we make up some form how to have this in the XML file and also what to make configurable by this patch, i.e. once the patch design is having the final form.
Have you thought about how this config model would apply to adding the other dns-related stuff that can be done with dnsmasq. It would be unfortunate if we took this first step and it turned out to not be a good match for the natural followons. Maybe we should take a short bit of time to consider the larger picture to make sure we'lll be able to easily and logically add the other stuff later (this might be the right way, I just haven't had time yet to think about it)
You're right. I completely agree since there are many DNS related options as I'm looking into the DNSMasq man page. From what I know the port, txt-record, query-port, edns UDP packet max-size and SRV, TXT, PTR, NAPTR and also CNAME records are supported to be added/changed so I guess making some larger picture of what my patch should implement could be a good thing. I wrote the patch to introduce just passing the TXT records to the dnsmasq arguments however passing those information for SRV, PTR, NAPTR and CNAME records could be a good thing as well. This patch should be about DNS options only and if want some other dnsmasq options that are not DNS related we may put that into a separate patch IMHO. What do you think about implementing these? Which do you think are good to be implemented and which are not required to be supported? Thanks, Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/28/2011 01:34 PM, Michal Novotny wrote:
Hi Laine, thanks for your reply. Comments inline...
On 03/25/2011 10:02 PM, Laine Stump wrote:
I haven't had time yet to look at the code in detail, but thought I should send this preliminary commentary.
Hi, this is the patch to add DNS TXT record support to libvirt networking driver since this is feature that's supported by DNSMasq that's being used by the bridge driver.
Maybe you fail to understand the reasons why to implement such a feature however it's a good thing IMHO since user could provide some information in the DNS TXT record headers. As a matter of fact, I think that not only is this useful, but configuring other capabilities presented by dnsmasq would be good. I
On 03/24/2011 09:58 AM, Michal Novotny wrote: think you'll find a kindred spirit in Paweł Krześniak, who was also wanting some other dnsmasq capabilities exposed (I forget which now).
Well, I have to agree that there are some options/capabilities that would be good to be configurable.
It would be great to: 1) add <user-class> and <vendor-class> tags inside <dhcp> that allow filtering according to user/vendor classes 2) allow to specify <bootp> inside those as well as inside <range> or <host> elements. 3) add support for DHCP options besides bootp, with a tag like <option force="yes|no" name="..." value="...">. For example, my router's DHCP configuration would look like this: <dhcp> <range ...> <user-class prefix="iPXE"> <bootp file="http://playground.usersys.redhat.com/pxe/boot.ipxe"> </user-class> <bootp file="undionly.kpxe"> </dhcp>
The headers are, of course, configurable in the network XML description and the idea got to me when I was reading an article about DKIM (DomainKeys Identified Mail) since it's using TXT records in the DNS to provide the public keys. This inspired me to implement the DNS TXT record support to libvirt bridge driver to allow users expose some information to the guest if they want to do so etc.
Limitations: - Records names and values containing space (' ') arguments are altered to change spaces to underscores ('_'). This is because of proper argument handling when spawning dnsmasq.
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, that's the reason since if we quote this we can't use dig to dig it correctly without the quotes. This was simply the way to disallow ' ' by changing it to underscores since I didn't want the definition to fail because of this.
It must be possible to use record values containing a space. $ dig TXT gmail.com [...] ;; QUESTION SECTION: ;gmail.com. IN TXT ;; ANSWER SECTION: gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" Paolo

[snip]
It would be great to:
1) add <user-class> and <vendor-class> tags inside <dhcp> that allow filtering according to user/vendor classes
Well, I didn't know this is supported by DNSMasq but it seems to be (according to the manpage at least): -U, --dhcp-vendorclass=<network-id>,<vendor-class> Map from a vendor-class string to a network id tag. Most DHCP clients provide a "vendor class" which represents, in some sense, the type of host. This option maps ven‐ dor classes to tags, so that DHCP options may be selectively delivered to different classes of hosts. For example dhcp-vendorclass=printers,Hewlett-Packard JetDirect will allow options to be set only for HP printers like so: --dhcp-option=printers,3,192.168.4.4 The vendor-class string is substring matched against the vendor-class supplied by the client, to allow fuzzy matching. -j, --dhcp-userclass=<network-id>,<user-class> Map from a user-class string to a network id tag (with substring matching, like vendor classes). Most DHCP clients provide a "user class" which is configurable. This option maps user classes to tags, so that DHCP options may be selectively delivered to different classes of hosts. It is possible, for instance to use this to set a different printer server for hosts in the class "accounts" than for hosts in the class "engineering". There's also MAC mapping: -4, --dhcp-mac=<network-id>,<MAC address> Map from a MAC address to a network-id tag. The MAC address may include wildcards. For example --dhcp-mac=3com,01:34:23:*:*:* will set the tag "3com" for any host whose MAC address matches the pattern.
2) allow to specify <bootp> inside those as well as inside <range> or <host> elements.
Right, there's bootp option: -M, --dhcp-boot=[net:<network-id>,]<filename>,[<servername>[,<server address>]] Set BOOTP options to be returned by the DHCP server. Server name and address are optional: if not provided, the name is left empty, and the address set to the address of the machine running dnsmasq. If dnsmasq is providing a TFTP service (see --enable-tftp ) then only the filename is required here to enable network booting. If the optional network-id(s) are given, they must match for this configuration to be sent. Note that network-ids are prefixed by "net:" to distinguish them.
3) add support for DHCP options besides bootp, with a tag like <option force="yes|no" name="..." value="...">.
For example, my router's DHCP configuration would look like this:
<dhcp> <range ...> <user-class prefix="iPXE"> <bootp file="http://playground.usersys.redhat.com/pxe/boot.ipxe"> </user-class> <bootp file="undionly.kpxe"> </dhcp>
That's not a bad idea at all and I think it's worth it however originally my patch was about DNS and not DHCP. I have to admit that DNS TXT record only patch was not the right thing to be implemented since I should have implemented all the DNS records supported (mentioned in this thread but from what I recall it would be support for PTR, TXT, SRV, NAPTR and CNAME records to support all of the DNS records).
It must be possible to use record values containing a space.
$ dig TXT gmail.com [...]
;; QUESTION SECTION: ;gmail.com. IN TXT
;; ANSWER SECTION: gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"
Well, I've been investigating a little more and it's possible to have it in the value of the record for this but not the name of the record. I tried following invocations of dnsmasq (I tried it on port 52 instead not to mess up with my current networking): first-term# dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon -p 52 --txt-record="some name","some value" second-term$ dig TXT some name @192.168.122.1 -p 52 connection timed out; no servers could be reached second-term$ dig TXT "some name" @192.168.122.1 -p 52 ;; ANSWER SECTION: some\032name. 0 IN TXT "some value" first-term# dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon -p 52 --txt-record=some-name,"some value" $ dig TXT some-name @192.168.122.1 -p 52 ;; ANSWER SECTION: some-name. 0 IN TXT "some value" So I guess we should disable the spaces in the name since it's being interpreted like \032 characters as can be seen in the dig output - we should either disable such a definition entirely or change spaces (' ') to dashes ('-'). But escaping the value of the record to the quotes is a good thing since this is working fine. So what do you think about this? Also, do you think we should implement everything connected to DNSMasq mentioned there (i.e. both DNS and DHCP stuff) in one commit, just few separate patches (e.g. one for DNS and second for DHCP/BOOTP) ? Thanks, Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/29/2011 12:52 PM, Michal Novotny wrote:
[snip]
It would be great to:
1) add<user-class> and<vendor-class> tags inside<dhcp> that allow filtering according to user/vendor classes
Well, I didn't know this is supported by DNSMasq but it seems to be
Yes, I am using it. :)
-4, --dhcp-mac=<network-id>,<MAC address> Map from a MAC address to a network-id tag. The MAC address may include wildcards. For example --dhcp-mac=3com,01:34:23:*:*:* will set the tag "3com" for any host whose MAC address matches the pattern.
Interesting.
2) allow to specify<bootp> inside those as well as inside<range> or<host> elements.
Right, there's bootp option:
It's already supported by libvirt.
3) add support for DHCP options besides bootp, with a tag like<option force="yes|no" name="..." value="...">.
For example, my router's DHCP configuration would look like this:
<dhcp> <range ...> <user-class prefix="iPXE"> <bootp file="http://playground.usersys.redhat.com/pxe/boot.ipxe"> </user-class> <bootp file="undionly.kpxe"> </dhcp>
That's not a bad idea at all and I think it's worth it however originally my patch was about DNS and not DHCP.
Yes, of course. Thinking more about it, <range ...> could also be (optionally) placed inside <user-class> and <vendor-class> ("serve this range only to this user class or vendor class").
I have to admit that DNS TXT record only patch was not the right thing to be implemented since I should have implemented all the DNS records supported
Should you? I am not sure of that. Are they really so useful, except for CNAME (whose functionality dnsmasq more or less supports using A and PTR records) and maybe SRV? Remember that A and PTR records are added automatically by dnsmasq based on /etc/hosts. Perhaps, you could implement (instead of tags for PTR, CNAME, etc.) <dns> <host ip="192.168.122.1"> <hostname>host1</hostname> <hostname>host2</hostname> <hostname>host3</hostname> </host> </dns> instead, which would write a file 192.168.122.1 host1 host2 host3 and pass it to dnsmasq via --addn-hosts. But every feature should be added as a separate patch.
I tried following invocations of dnsmasq (I tried it on port 52 instead not to mess up with my current networking):
first-term# dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon -p 52 --txt-record="some name","some value"
second-term$ dig TXT some name @192.168.122.1 -p 52 connection timed out; no servers could be reached
second-term$ dig TXT "some name" @192.168.122.1 -p 52 ;; ANSWER SECTION: some\032name. 0 IN TXT "some value"
This is just how dnsmasq prints the request. You can see with wireshark that the request is really for "some name". BTW, please test your patch with commas in the name. Those should be forbidden probably (not sure about the value).
So what do you think about this? Also, do you think we should implement everything connected to DNSMasq mentioned there (i.e. both DNS and DHCP stuff) in one commit, just few separate patches (e.g. one for DNS and second for DHCP/BOOTP) ?
Many many separate patches. BTW, regarding this particular series, you should update the XML schema, and add many many testcases. Do this for TXT, then you can start thinking about everything else. Paolo

On 03/29/2011 01:16 PM, Paolo Bonzini wrote:
On 03/29/2011 12:52 PM, Michal Novotny wrote:
[snip]
It would be great to:
1) add<user-class> and<vendor-class> tags inside<dhcp> that allow filtering according to user/vendor classes Well, I didn't know this is supported by DNSMasq but it seems to be Yes, I am using it. :)
Great. Good to implement this then however I'm not sure about the <network-id> parameter for DNSMasq. What should network-id tag mean and what should it match?
-4, --dhcp-mac=<network-id>,<MAC address> Map from a MAC address to a network-id tag. The MAC address may include wildcards. For example --dhcp-mac=3com,01:34:23:*:*:* will set the tag "3com" for any host whose MAC address matches the pattern.
Interesting.
Well, should we support this as well?
2) allow to specify<bootp> inside those as well as inside<range> or<host> elements. Right, there's bootp option: It's already supported by libvirt.
Good. So the patch won't implement this.
3) add support for DHCP options besides bootp, with a tag like<option force="yes|no" name="..." value="...">.
For example, my router's DHCP configuration would look like this:
<dhcp> <range ...> <user-class prefix="iPXE"> <bootp file="http://playground.usersys.redhat.com/pxe/boot.ipxe"> </user-class> <bootp file="undionly.kpxe"> </dhcp>
Basically this is using boot.ipxe file for the prefix of iPXE and falling back to default undionly.kpxe... right? Is this what you mean by your definition?
That's not a bad idea at all and I think it's worth it however originally my patch was about DNS and not DHCP. Yes, of course.
Thinking more about it, <range ...> could also be (optionally) placed inside <user-class> and <vendor-class> ("serve this range only to this user class or vendor class").
Well, this could be a good thing as well since for various vendor/user-classes we should be having different ranges.
I have to admit that DNS TXT record only patch was not the right thing to be implemented since I should have implemented all the DNS records supported Should you? I am not sure of that. Are they really so useful, except for CNAME (whose functionality dnsmasq more or less supports using A and PTR records) and maybe SRV? Remember that A and PTR records are added automatically by dnsmasq based on /etc/hosts.
Perhaps, you could implement (instead of tags for PTR, CNAME, etc.)
<dns> <host ip="192.168.122.1"> <hostname>host1</hostname> <hostname>host2</hostname> <hostname>host3</hostname> </host> </dns>
instead, which would write a file
192.168.122.1 host1 host2 host3
and pass it to dnsmasq via --addn-hosts. But every feature should be added as a separate patch.
Well, that's a good idea IMHO. If we write a file and pass it directly to dnsmasq using -addn-hosts then the implementation could be much better since you'll still be able to define it in the XML file and the libvirt network configuration and the file will be generate for you on network-start only.
I tried following invocations of dnsmasq (I tried it on port 52 instead not to mess up with my current networking):
first-term# dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon -p 52 --txt-record="some name","some value"
second-term$ dig TXT some name @192.168.122.1 -p 52 connection timed out; no servers could be reached
second-term$ dig TXT "some name" @192.168.122.1 -p 52 ;; ANSWER SECTION: some\032name. 0 IN TXT "some value" This is just how dnsmasq prints the request. You can see with wireshark that the request is really for "some name". BTW, please test your patch with commas in the name. Those should be forbidden probably (not sure about the value).
You're right. It's really "some name" and it's matter of how dnsmasq prints the request. Also, for the commas, I did try in both name and value and it was not working at all in the name and for the value is was showing 2 values basically: ;; ANSWER SECTION: some\032name. 0 IN TXT "some" "value" Value in wireshark is presented separated by a NULL byte, i.e. "some\0value" (although wireshark shows comma character instead of \0 since it doesn't escape that way) so I guess we should disallow usage of commas as well. To sum this up, we should disallow usage of commas and quotes (or we should at least escape the quotes).
So what do you think about this? Also, do you think we should implement everything connected to DNSMasq mentioned there (i.e. both DNS and DHCP stuff) in one commit, just few separate patches (e.g. one for DNS and second for DHCP/BOOTP) ? Many many separate patches.
BTW, regarding this particular series, you should update the XML schema, and add many many testcases. Do this for TXT, then you can start thinking about everything else.
Ok. Good. Thanks! Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/29/2011 01:37 PM, Michal Novotny wrote:
On 03/29/2011 01:16 PM, Paolo Bonzini wrote:
On 03/29/2011 12:52 PM, Michal Novotny wrote:
[snip]
It would be great to:
1) add<user-class> and<vendor-class> tags inside<dhcp> that allow filtering according to user/vendor classes Well, I didn't know this is supported by DNSMasq but it seems to be Yes, I am using it. :)
Great. Good to implement this then however I'm not sure about the <network-id> parameter for DNSMasq. What should network-id tag mean and what should it match?
It can be a progressive number. You use it later to limit the "scope" of --dhcp-boot options.
-4, --dhcp-mac=<network-id>,<MAC address> Map from a MAC address to a network-id tag. The MAC address may include wildcards. For example --dhcp-mac=3com,01:34:23:*:*:* will set the tag "3com" for any host whose MAC address matches the pattern.
Interesting.
Well, should we support this as well?
One step at a time...
3) add support for DHCP options besides bootp, with a tag like<option force="yes|no" name="..." value="...">.
For example, my router's DHCP configuration would look like this:
<dhcp> <range ...> <user-class prefix="iPXE"> <bootp file="http://playground.usersys.redhat.com/pxe/boot.ipxe"> </user-class> <bootp file="undionly.kpxe"> </dhcp>
Basically this is using boot.ipxe file for the prefix of iPXE and falling back to default undionly.kpxe... right? Is this what you mean by your definition?
Yes.
second-term$ dig TXT "some name" @192.168.122.1 -p 52 ;; ANSWER SECTION: some\032name. 0 IN TXT "some value" This is just how dnsmasq prints the request. You can see with wireshark that the request is really for "some name". BTW, please test your patch with commas in the name. Those should be forbidden probably (not sure about the value).
You're right. It's really "some name" and it's matter of how dnsmasq prints the request. Also, for the commas, I did try in both name and value and it was not working at all in the name and for the value is was showing 2 values basically:
;; ANSWER SECTION: some\032name. 0 IN TXT "some" "value"
Value in wireshark is presented separated by a NULL byte, i.e. "some\0value" (although wireshark shows comma character instead of \0 since it doesn't escape that way) so I guess we should disallow usage of commas as well.
Perhaps no, it does have a meaning after all. I don't know much about TXT records though.
To sum this up, we should disallow usage of commas and quotes (or we should at least escape the quotes).
Commas only in the name, please. libvirt helpers should take care of escaping quotes. Paolo

[snip]
Great. Good to implement this then however I'm not sure about the <network-id> parameter for DNSMasq. What should network-id tag mean and what should it match? It can be a progressive number. You use it later to limit the "scope" of --dhcp-boot options.
Oh, I see. It could make sense however for the MAC the value of network-id has been set to "3com" so this confused me however it's just the naming tag after all.
-4, --dhcp-mac=<network-id>,<MAC address> Map from a MAC address to a network-id tag. The MAC address may include wildcards. For example --dhcp-mac=3com,01:34:23:*:*:* will set the tag "3com" for any host whose MAC address matches the pattern.
Interesting. Well, should we support this as well? One step at a time...
Ok, however vendor-class and user-class should be used together and therefore it could be committed into one commit, right? The next commit could be the dhcp-mac one... right ?
3) add support for DHCP options besides bootp, with a tag like<option force="yes|no" name="..." value="...">.
For example, my router's DHCP configuration would look like this:
<dhcp> <range ...> <user-class prefix="iPXE"> <bootp file="http://playground.usersys.redhat.com/pxe/boot.ipxe"> </user-class> <bootp file="undionly.kpxe"> </dhcp>
Basically this is using boot.ipxe file for the prefix of iPXE and falling back to default undionly.kpxe... right? Is this what you mean by your definition? Yes.
second-term$ dig TXT "some name" @192.168.122.1 -p 52 ;; ANSWER SECTION: some\032name. 0 IN TXT "some value" This is just how dnsmasq prints the request. You can see with wireshark that the request is really for "some name". BTW, please test your patch with commas in the name. Those should be forbidden probably (not sure about the value). You're right. It's really "some name" and it's matter of how dnsmasq prints the request. Also, for the commas, I did try in both name and value and it was not working at all in the name and for the value is was showing 2 values basically:
;; ANSWER SECTION: some\032name. 0 IN TXT "some" "value"
Value in wireshark is presented separated by a NULL byte, i.e. "some\0value" (although wireshark shows comma character instead of \0 since it doesn't escape that way) so I guess we should disallow usage of commas as well. Perhaps no, it does have a meaning after all. I don't know much about TXT records though.
Well, I already have this done and I think it could be useful.
To sum this up, we should disallow usage of commas and quotes (or we should at least escape the quotes). Commas only in the name, please. libvirt helpers should take care of escaping quotes.
Paolo
What do you mean? To apply the restriction only to "name" attribute and not "value" attribute? I'm having it applied for both now so I'd like to know whether it's OK to let it this way or not :) Thanks, Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/29/2011 05:08 PM, Michal Novotny wrote:
Ok, however vendor-class and user-class should be used together and therefore it could be committed into one commit, right? The next commit could be the dhcp-mac one... right ?
No, they can be one patch series, but they should be separate commits.
Commas only in the name, please. libvirt helpers should take care of escaping quotes.
What do you mean? To apply the restriction only to "name" attribute and not "value" attribute? I'm having it applied for both now so I'd like to know whether it's OK to let it this way or not :)
I'll let others chime in, but I think that if dnsmasq documents that "The value of TXT record is a set of strings, so any number may be included, split by commas" we can keep the same definition. Paolo

On 03/29/2011 05:12 PM, Paolo Bonzini wrote:
On 03/29/2011 05:08 PM, Michal Novotny wrote:
Ok, however vendor-class and user-class should be used together and therefore it could be committed into one commit, right? The next commit could be the dhcp-mac one... right ? No, they can be one patch series, but they should be separate commits.
Commas only in the name, please. libvirt helpers should take care of escaping quotes. What do you mean? To apply the restriction only to "name" attribute and not "value" attribute? I'm having it applied for both now so I'd like to know whether it's OK to let it this way or not :) I'll let others chime in, but I think that if dnsmasq documents that "The value of TXT record is a set of strings, so any number may be included, split by commas" we can keep the same definition.
Paolo Ok, that's fine for me :)
Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/29/2011 12:52 PM, Michal Novotny wrote:
[snip]
It would be great to:
1) add<user-class> and<vendor-class> tags inside<dhcp> that allow filtering according to user/vendor classes
Well, I didn't know this is supported by DNSMasq but it seems to be
Yes, I am using it. :)
-4, --dhcp-mac=<network-id>,<MAC address> Map from a MAC address to a network-id tag. The MAC address may include wildcards. For example --dhcp-mac=3com,01:34:23:*:*:* will set the tag "3com" for any host whose MAC address matches the pattern.
Interesting.
2) allow to specify<bootp> inside those as well as inside<range> or<host> elements.
Right, there's bootp option:
It's already supported by libvirt.
That's not a bad idea at all and I think it's worth it however originally my patch was about DNS and not DHCP.
Yes, of course. Thinking more about it, <range ...> could also be (optionally) placed inside <user-class> and <vendor-class> ("serve this range only to this user class or vendor class").
I have to admit that DNS TXT record only patch was not the right thing to be implemented since I should have implemented all the DNS records supported
Should you? I am not sure of that. Are they really so useful for libvirt's use case, except for CNAME (whose functionality dnsmasq more or less supports using A and PTR records) and maybe SRV? Remember that A and PTR records are added automatically by dnsmasq based on /etc/hosts. Perhaps, you could implement (instead of tags for PTR, CNAME, etc.) <dns> <host ip="192.168.122.1"> <hostname>host1</hostname> <hostname>host2</hostname> <hostname>host3</hostname> </host> </dns> instead, which would write a file 192.168.122.1 host1 host2 host3 and pass it to dnsmasq via --addn-hosts. But every feature should be added as a separate patch.
I tried following invocations of dnsmasq (I tried it on port 52 instead not to mess up with my current networking):
first-term# dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon -p 52 --txt-record="some name","some value"
second-term$ dig TXT some name @192.168.122.1 -p 52 connection timed out; no servers could be reached
second-term$ dig TXT "some name" @192.168.122.1 -p 52 ;; ANSWER SECTION: some\032name. 0 IN TXT "some value"
This is just how dig prints the request. You can see with wireshark that the request is really for "some name". BTW, please test your patch with commas in the name. Those should be forbidden probably (not sure about the value).
So what do you think about this? Also, do you think we should implement everything connected to DNSMasq mentioned there (i.e. both DNS and DHCP stuff) in one commit, just few separate patches (e.g. one for DNS and second for DHCP/BOOTP) ?
Many many separate patches. BTW, regarding this particular series, you should update the XML schema, and add many many testcases. Do this for TXT, then you can start thinking about everything else. Paolo

[snip]
Perhaps, you could implement (instead of tags for PTR, CNAME, etc.)
<dns> <host ip="192.168.122.1"> <hostname>host1</hostname> <hostname>host2</hostname> <hostname>host3</hostname> </host> </dns>
instead, which would write a file
192.168.122.1 host1 host2 host3
and pass it to dnsmasq via --addn-hosts. But every feature should be added as a separate patch. Paolo, I'm having interesting results on this matter. I was unable to see it working now whereas I saw it working fine yesterday so I've been investigating this further.
Results of my investigation were obtained when running it manually and they are: 1) /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --txt-record="txt-record","some value, which is something" --addn-hosts=/var/run/libvirt/network/default.hosts --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override -> the guest was unable to access the records from --addn-hosts (tested using nslookup) 2) /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --txt-record="txt-record","some value, which is something" --addn-hosts=/var/run/libvirt/network/default.hosts --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon -> the --no-daemon option made it working for the --addn-hosts but it was not working without it, i.e. in the daemon mode. Based on this I guess this is the bug in Fedora-14 DNSMasq (which is the same as the one for Fedora-14 since I'm unable to get any update and the version I'm having is dnsmasq-2.52-1.fc13.i686). Should I file a bug against DNSMasq about this? Also, I've been testing the --txt-record once again and not grabbed it with wireshark and I had to query the "txt-record" TXT record for this and the wireshark was showing the quotes there as well now. Should I disable it then and use the working syntax for record name which (according to my testing) is to use *--txt-record=txt-record,"some value, which is something"* instead, i.e. to not use quotes in the name? Thanks, Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/30/2011 12:41 PM, Michal Novotny wrote:
1) /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --txt-record="txt-record","some value, which is something" --addn-hosts=/var/run/libvirt/network/default.hosts --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override
-> the guest was unable to access the records from --addn-hosts (tested using nslookup)
2) /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --txt-record="txt-record","some value, which is something" --addn-hosts=/var/run/libvirt/network/default.hosts --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon
-> the --no-daemon option made it working for the --addn-hosts but it was not working without it, i.e. in the daemon mode. Based on this I guess this is the bug in Fedora-14 DNSMasq (which is the same as the one for Fedora-14 since I'm unable to get any update and the version I'm having is dnsmasq-2.52-1.fc13.i686). Should I file a bug against DNSMasq about this?
I think you should triage it a bit more, e.g. with strace -ff. Anyway, there is no hurry of doing this I think.
Also, I've been testing the --txt-record once again and not grabbed it with wireshark and I had to query the "txt-record" TXT record for this and the wireshark was showing the quotes there as well now. Should I disable it then and use the working syntax for record name which (according to my testing) is to use *--txt-record=txt-record,"some value, which is something"* instead, i.e. to not use quotes in the name?
I absolutely cannot parse this sentence. Paolo

1) /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --txt-record="txt-record","some value, which is something" --addn-hosts=/var/run/libvirt/network/default.hosts --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override
-> the guest was unable to access the records from --addn-hosts (tested using nslookup)
2) /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --txt-record="txt-record","some value, which is something" --addn-hosts=/var/run/libvirt/network/default.hosts --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --no-daemon
-> the --no-daemon option made it working for the --addn-hosts but it was not working without it, i.e. in the daemon mode. Based on this I guess this is the bug in Fedora-14 DNSMasq (which is the same as the one for Fedora-14 since I'm unable to get any update and the version I'm having is dnsmasq-2.52-1.fc13.i686). Should I file a bug against DNSMasq about this? I think you should triage it a bit more, e.g. with strace -ff. Anyway,
On 03/30/2011 12:41 PM, Michal Novotny wrote: there is no hurry of doing this I think.
Well, you mean to use strace on the daemonized process?
Also, I've been testing the --txt-record once again and not grabbed it with wireshark and I had to query the "txt-record" TXT record for this and the wireshark was showing the quotes there as well now. Should I disable it then and use the working syntax for record name which (according to my testing) is to use *--txt-record=txt-record,"some value, which is something"* instead, i.e. to not use quotes in the name? I absolutely cannot parse this sentence.
Well, what I meant was that if I invoked dnsmasq with --txt-record="txt-record", "some value" then I had to dig for "txt-record" with quotes, i.e. using the dig TXT \"txt-record\" syntax in bash. In Wireshark it was showing request for record with the quotes, i.e. "txt-record" instead of querying just for txt-record, i.e. without quotes. To be able to query it without quotes I had to invoke dnsmasq with --txt-record=txt-record, "some value" arguments. Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/30/2011 01:00 PM, Michal Novotny wrote:
I think you should triage it a bit more, e.g. with strace -ff. Anyway, there is no hurry of doing this I think.
Well, you mean to use strace on the daemonized process?
Wherever it helps understanding what's happening. :)
Also, I've been testing the --txt-record once again and not grabbed it with wireshark and I had to query the "txt-record" TXT record for this and the wireshark was showing the quotes there as well now. Should I disable it then and use the working syntax for record name which (according to my testing) is to use *--txt-record=txt-record,"some value, which is something"* instead, i.e. to not use quotes in the name? I absolutely cannot parse this sentence.
Well, what I meant was that if I invoked dnsmasq with --txt-record="txt-record", "some value" then I had to dig for "txt-record" with quotes, i.e. using the dig TXT \"txt-record\" syntax in bash. In Wireshark it was showing request for record with the quotes, i.e. "txt-record" instead of querying just for txt-record, i.e. without quotes. To be able to query it without quotes I had to invoke dnsmasq with --txt-record=txt-record, "some value" arguments.
Who was escaping the double-quotes? Paolo

On 03/30/2011 01:00 PM, Michal Novotny wrote:
I think you should triage it a bit more, e.g. with strace -ff. Anyway, there is no hurry of doing this I think. Well, you mean to use strace on the daemonized process? Wherever it helps understanding what's happening. :)
Also, I've been testing the --txt-record once again and not grabbed it with wireshark and I had to query the "txt-record" TXT record for this and the wireshark was showing the quotes there as well now. Should I disable it then and use the working syntax for record name which (according to my testing) is to use *--txt-record=txt-record,"some value, which is something"* instead, i.e. to not use quotes in the name? I absolutely cannot parse this sentence. Well, what I meant was that if I invoked dnsmasq with --txt-record="txt-record", "some value" then I had to dig for "txt-record" with quotes, i.e. using the dig TXT \"txt-record\" syntax in bash. In Wireshark it was showing request for record with the quotes, i.e. "txt-record" instead of querying just for txt-record, i.e. without quotes. To be able to query it without quotes I had to invoke dnsmasq with --txt-record=txt-record, "some value" arguments. Who was escaping the double-quotes?
I had to put the quotes there manually since they were not given there automatically using virBufferVSprintf() call and invocation without them failed for case you used space in name or value of the TXT record, i.e. --txt-record=some name, some value since it was taking name (and value) as the next arguments. Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/30/2011 01:00 PM, Michal Novotny wrote:
I think you should triage it a bit more, e.g. with strace -ff. Anyway, there is no hurry of doing this I think. Well, you mean to use strace on the daemonized process? Wherever it helps understanding what's happening. :)
It was a good idea to run it under strace since I've been able to see that when it daemonizes then the user is changed from current user to nobody. This is what caused the issue since there was no read permission for others. Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/30/2011 01:00 PM, Michal Novotny wrote:
I think you should triage it a bit more, e.g. with strace -ff. Anyway, there is no hurry of doing this I think. Well, you mean to use strace on the daemonized process? Wherever it helps understanding what's happening. :)
Also, I've been testing the --txt-record once again and not grabbed it with wireshark and I had to query the "txt-record" TXT record for this and the wireshark was showing the quotes there as well now. Should I disable it then and use the working syntax for record name which (according to my testing) is to use *--txt-record=txt-record,"some value, which is something"* instead, i.e. to not use quotes in the name? I absolutely cannot parse this sentence. Well, what I meant was that if I invoked dnsmasq with --txt-record="txt-record", "some value" then I had to dig for "txt-record" with quotes, i.e. using the dig TXT \"txt-record\" syntax in bash. In Wireshark it was showing request for record with the quotes, i.e. "txt-record" instead of querying just for txt-record, i.e. without quotes. To be able to query it without quotes I had to invoke dnsmasq with --txt-record=txt-record, "some value" arguments. Who was escaping the double-quotes?
Paolo
Well, it's working without the quotes and I just made a typo there before and that's why invocation failed. Now it's OK without the quotes. Michal -- Michal Novotny <minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On 03/29/2011 06:52 AM, Michal Novotny wrote:
[snip]
So I guess we should disable the spaces in the name since it's being interpreted like \032 characters as can be seen in the dig output - we should either disable such a definition entirely or change spaces (' ') to dashes ('-'). But escaping the value of the record to the quotes is a good thing since this is working fine.
I think giving an error on an illegal character is a better idea than silently changing it to something else. If it's not supported, it's not supported; the admin should be made aware of that, and manually change it to something that is allowed.
So what do you think about this? Also, do you think we should implement everything connected to DNSMasq mentioned there (i.e. both DNS and DHCP stuff) in one commit, just few separate patches (e.g. one for DNS and second for DHCP/BOOTP) ?
Sorry - you're moving much too fast for me to keep up! :-) I think it's a good idea for your patch to just cover DNS-related items, and we can put the others into a different patch.

[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@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

On Fri, Mar 25, 2011 at 22:02, Laine Stump <laine@laine.org> wrote:
As a matter of fact, I think that not only is this useful, but configuring other capabilities presented by dnsmasq would be good. I think you'll find a kindred spirit in Paweł Krześniak, who was also wanting some other dnsmasq capabilities exposed (I forget which now).
For me the most interesting dnsmasq's options are no-hosts, no-resolv, addn-hosts, server, log-queries. Our initial discussion about dnsmasq options is here https://www.redhat.com/archives/libvir-list/2010-December/msg00857.html -- Pawel
participants (4)
-
Laine Stump
-
Michal Novotny
-
Paolo Bonzini
-
Paweł Krześniak