Question about dynamic IPv6-PTR-Generation

Woodworth, John R John.Woodworth at
Sat Aug 27 23:23:34 UTC 2016

Apologies for the double post, I was not finished with edits in my
previous post:

> John Levine wrote:
> > >It is true at first glance the regex-esque syntax in our I-D may seem
> > >a bit complex but I don't believe anywhere near the complexity of
> > >NAPTR
> >
> > None of the complexity of NAPTR is in the DNS or the DNS servers; it's
> > all in the applications that use NAPTR.  For DNS servers, NAPTR is
> > just a record it handles the way it does any other normal record, like
> > A or HINFO.

Apologies for the confusion.  I was under the impression there was concern
about the syntax using regex and being complicated.  My point was the
syntax "borrows" concepts from regex but precise regex patterns for numeric
ranges is too much effort to accomplish for the casual zone admin.

As far as NAPTR pushing the effort to the client, this is true but it
*has* patterns that are very complicated to the casual zone admin and
NAPTR records already exist.

Creating a protocol around use of generated records kind of defeats one
of our primary objectives which is to make this feature as transparent to
clients as possible.  For example, clients do not need to care whether
$GENERATE was used for their records, why not carry this logic over to
the the next phase?  Most of the embedded devices (IOT, etc.) will not
be updating their libraries to support a "how do I find an A record"
logic, and why should they?

> Or the URI RR, which requires authoritative nameservers to know absolutely
> nothing about the encoding of URIs.

Auth nameservers do have to know things about certain record types; NS,
CNAME and RRSIG RRs for example so this is not a completely new concept.

In fact, all the precedence for this I-D already exists:
  * $GENERATE: Pattern based record generation
               (bind proprietary, others may exist)
  * NAPTR:     Complex RDATA pattern substitution syntax
  * RRSIG:     Additional computational burden to authoritative nameserver
               and client implementations (change to existing DNS semantics)
               (record specific "awareness")
  * Wildcard:  Automatic wildcard record namespace identification
               and NXDOMAIN substitution (superimposed records)

Wouldn't you agree based on the above logic this looks to be the natural
progression of the art?  It's not always about doing what was already done
but building on what has been done and trying not to break anything along
the way.


> --
> Robert Edmonds


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