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

[snip] 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. 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. 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). 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(a)redhat.com&gt;, RHCE Virtualization Team (xen userspace), Red Hat