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.
>>
>> 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).
>
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list