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

Michal Novotny minovotn at redhat.com
Tue Mar 29 15:08:54 UTC 2011


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




More information about the libvir-list mailing list