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

Paolo Bonzini pbonzini at redhat.com
Tue Mar 29 14:59:21 UTC 2011


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




More information about the libvir-list mailing list