Best practices for coding new RR Types

Woodworth, John R John.Woodworth at CenturyLink.com
Mon Oct 19 20:21:41 UTC 2015


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

Bob, thanks so much for your feedback.  It helps to get more eyes on this and I
feel strongly the more the community is involved the better this feature will
be for everyone.  We discussed changing the default delimiter to ':' for AAAA
but must have missed it in editing before submitting this version.  I
personally feel the automatic ordering of backreferences feels more intuitive
but you may be right. Ease of use is one of our primary motivations for this
effort.


Thanks again,
John

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151019/8da91365/attachment-0001.html>


More information about the bind-users mailing list