Hi,<br><br><div class="gmail_quote">On 25 May 2012 16:11, Simon Kelley <span dir="ltr"><<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 25/05/12 12:14, Jan-Piet Mens wrote:<br>
>> relaxing the hex parsing to make colons and leading zeros optional gets<br>
>> the possibility of something that's almost an natural encoding in this<br>
>> case, and may be generally useful if less easy to use.<br>
>><br>
>> dns-rr=44,2:1:123456789abcdef67890123456789abcdef67890<br>
>><br>
>> Opinions?<br>
><br>
> Go for it!<br>
><br>
> I recommend reading RFC 3597, Section 5 on the text-representation of<br>
> arbitrary DNS RR types, and if possible lean towards that, making lives<br>
> of people who copy paste RDATA easier. :)<br>
><br>
<br>
</div>I'll support that as well.<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br></div><div>I like the approach of supporting arbitrary RR types, since it is a very flexible, future oriented solution and it covers my original question also :-)</div>
<div>After some investigation it pointed out that using DNSSEC would be a bit too much overhead because we are inside a secure network (just as a feedback to JP).</div><div><br></div><div>How is the workflow for adding a new functionality, some kind of rules for working @dnsmasq source ?!?!</div>
<div>I'm not a C guru, but I'd like to contribute as much as I can to speed up the implementation of supporting arbitrary RR types......immediately after my Corpus Christi vacation ;-) ....</div><div><br></div><div>
br Gerd</div></div>