[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] lsocket - Another library for sockets in lua
- From: Sean Conner <sean@...>
- Date: Thu, 28 Mar 2013 03:10:50 -0400
It was thus said that the Great Hadriel Kaplan once stated:
>
> On Mar 28, 2013, at 12:36 AM, William Ahern <william@25thandClement.com> wrote:
>
> >> [3] It handles 32 DNS record types---about 26 more types than other DNS
> >> resolving libraries.
Well, my "handles" I mean "parses the wire format and presents the record
in an easy to use format for upper level code".
> > I can't find any code which handles NAPTR pattern matching in SPCDNS. Do you
> > just use the POSIX regex library in your applications? (Presuming you
> > actually use NAPTR records.) I was always afraid to execute regular
> > expressions from untrusted third-parties, _especially_ with builtin POSIX
> > regex engines, which are mostly pretty horrible.
>
> It looks like it returns the regex pattern as a string, so presumably the
> calling app has to decide how to handle it. That makes sense for
> telephony applications - since NAPTR is used in ENUM (RFC 3761)
> resolution, as well as calling name based on a popular draft, among other
> more proprietary uses. Regardless, the "original" string to apply the
> regex to, and replace its matched portion, is only truly known by the
> upper-layer calling application. (ie, it's not the DNS query key) And of
> course letting the calling application do it means it can make some
> decisions about whether to only handle regex patterns it knows about
> in-advance (which some telephony vendors do), or optimize for common ones,
> or truly compile it on the fly, or whatever.
Yup, this is pretty much the case. How the two projects use NAPTR records
was beyond the scope of SPCDNS; they're just happy to be able to use a
simple API (there's only two calls) to parse the DNS packets.
-spc