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. Regards, John > -- > Robert Edmonds > -- THESE ARE THE DROIDS TO WHOM I REFER: 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. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users