<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 17, 2015 at 12:48 AM, Woodworth, John R <span dir="ltr"><<a href="mailto:John.Woodworth@centurylink.com" target="_blank">John.Woodworth@centurylink.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> -----Original Message-----<br>
> From: Mark Andrews [mailto:<a href="mailto:marka@isc.org">marka@isc.org</a>]<br>
> Sent: Friday, October 16, 2015 7:08 PM<br>
> To: Woodworth, John R<br>
> Cc: '<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>'<br>
> Subject: Re: Best practices for coding new RR Types<br>
><br>
><br>
> In message <A05B583C828C614EBAD1DA920D92866BA5DDF69D@PODCWMBXEX501.ctl.intranet<br>
> >, "Woodworth, John R" writes:<br>
> ><br>
> > Hello,<br>
> ><br>
> > I am trying to implement logic for an experimental (Internet Draft) RR<br>
> > type and follow most of the code flow but am curious if there is a<br>
> > common methodology beyond trying to duplicate another record with<br>
> > similar attributes.<br>
><br>
> That's basically what we do.  Cut and paste different field types from existing RR<br>
> types.  Take extreme care as this is a extremely security sensitive area of the<br>
> nameserver as it is parsing data received from untrusted sources.  Think edge cases.<br>
><br>
<br>
</span>Mark, thanks for the quick response and letting me know I was on the right track.  I am<br>
using some of bind's safety-nets I find along the way to sanitize the records by-example<br>
and have attempted to keep an eye on potential misuse.<br>
<span class=""><br>
<br>
> B.T.W. which RR are you trying to implement?  All the ones with assigned values<br>
> are implemented.<br>
<br>
<br>
</span>This is fairly early in the process and we are still waiting for assignments.  I figured<br>
it would be a good idea to first get some reference code ready for a few nameserver<br>
implementations to aid in quick adoption once things <optimism>fall into place</optimism>.<br>
<br>
We were looking at bind (de facto), unbound and powerDNS (for live DNSSEC signing) but it<br>
appears bind now has in-line signing so we may be able to limit our efforts.<br>
<br>
If you are interested, I've provided the link below but keep in mind while we are very<br>
enthusiastic about the RR this is only a first draft.<br>
<br>
[ <a href="https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/</a> ]<br>
<br>
<br>
Thanks again,<br>
John<br>
<div class=""><div class="h5"><br></div></div></blockquote>Section 2.3, example 2 (PTR) looks wrong:<br><br> [0-255].[0-255].55.10.in-addr.arpa.<br>                                    pool-A-${1}-${2}.<a href="http://example.com">example.com</a>.<br><br>Should be reversed {1} and {2}:<br> [0-255].[0-255].55.10.in-addr.arpa.<br>                                    pool-A-${2}-${1}.<a href="http://example.com">example.com</a>.<br></div><div class="gmail_quote">--  But I see now that 3.4.1.1.8 reverses the order.  I find that confusing, and would rather have a consistent order, and use 3.4.1.1.9 if needed.<br></div><div class="gmail_quote"><br><br>Section 3.4.1.1.5. Backreference delimiter<br><br>For AAAA, would ":" be a better default delimiter?  Do AAAA records use dots anywhere?<pre><span class=""><br></span></pre></div></div></div>