Re: [libvirt] [PATCH] network: fix problems with SRV

On 03/18/2014 01:09 AM, Martin Kletzander wrote: Just to make sure what I wrote made sense: my point was that, due to the fact that the current code would only be able to generate records like this: [some-name].tcp.[some-domain] [some-name].udp.[some-domain] (i.e. the protocol could only be the exact string "tcp" or "udp"), and since the RFC *requires* that the protocol be prefixed with an underscore, it is impossible that anyone has an actual working config using the existing code (although it may have been saved with no error, it wouldn't do anything useful). Because it is impossible that it could have worked before, we don't need to worry about backward compatibility problems - nothing we do could break a working config. But I *think* what you're pointing out is that, although the config may not be working, it's possible that someone could have made a config like this: <srv service='_sip' protocol='udp' domain='example.com' target='sip.example.com' port='5060'/> which they could have saved, even though it would do nothing useful, it would be saved. Then when that system was updated to the new libvirt, that network's config would generate an error while loading, so the network would be ignored. Gah!! So I *can't* add this new restriction in the parser. I could check for it during networkValidate() in the bridge driver, though. Do you think this is worthwhile? (I think I'll do it as a separate patch in any case). I was bothered by this as well, and spent quite awhile searching RFCs to get a definitive answer on what characters are allowed in a service name or a protocol name. I couldn't find this information, though. I could only find lists of currently assigned service/protocol names. I guess since it is the number that goes over the wire, the RFCs are more concerned about the number than about exactly what it is called (dhcp option names suffer the same problem - there are only official option *numbers*, but not official names). I then considered limiting the character set to what can currently be found in /etc/services and /etc/protocol on a Linux system, but after taking a quick look, it seemed like there wasn't a very strict code about it - there are even some names that use "+". Eric did find a bit in "man services" that says that basically any printable ASCII character is okay, but you should be conservative in what you use (didn't stop people from adding things like "sql*net" and "whois++" to /etc/services, though :-/) So how about this - I will define a character set that contains only alphanumerics, and those special characters currently used in /etc/services and /etc/protocol, and check it against that. (except ".", because dnsmasq uses that as a separator on the commandline, and there is no method of escaping it). (As discussed above, I have to remove the restriction on _ as the leading character.) Good point, and although our config should be affected by the RFC rather than by dnsmasq, the RFC doesn't say anything about default values because in the DNS record all the fields are mandatory. Since a service for port 0 makes no sense (port 0 is reserved for both tcp and udp), I think we can safely make the value "0" mean "unspecified, use default of 1", and then disallow config with an explicit "port='0'" to avoid ambiguity. Then if we need to put something on the commandline to fill the space, we will put "1" instead of "0". I'll squash in the changes in the attached patch and send a v2.