Best practices for coding new RR Types

Woodworth, John R John.Woodworth at CenturyLink.com
Sat Oct 17 04:48:01 UTC 2015


> -----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

>
> Mark
>
> > Any help/ tips to get ramped up quickly with the process and avoid
> > pitfalls would be greatly appreciated.  I am new to the codebase so
> > any documents to limit silly questions are also appreciated.
> >
> >
> > Thanks,
> > 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.
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>
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.


More information about the bind-users mailing list