[dns-operations] ncap Perl Bindings (and about nmsg)

[Paul Vixie]

> Date: Sat, 18 Jul 2009 15:55:06 +0200
> From: Michael Friedrich <michael.friedrich at univie.ac.at>
> 
> Besides a question - mod_urstate currently analyses only udp and ipv4,
> are there any plans to extend that to tcp, ipv6? ipv6 would cause some
> problems using the swap algorithm as far as i would expect.

patches welcome.  we're working downfield of ncap at the moment, so for now
we have no plans to add more features.  however, ncap is open source, and if
the community starts doing feature development, we will integrate and release.

> From: Sidney Faber <sfaber at cert.org>
> Date: Sat, 18 Jul 2009 10:17:48 -0400
> 
> We're beating the ncap drum throughout .gov and .mil, preaching for its
> adoption and for more DNS research using it--studying DNS for more than
> just "this name resolves to this address."  Shortly you'll see some code
> contributions including a ncaptool module to search ncap files for
> hundreds or thousands of query names/domains at the same time, and a tool
> that lets you glob ncap files together as you pipe them into ncaptool.
> More to follow (our interns have been busy this summer!).

to me, as the original author of ncap, this is heartening news.  i've long
resented the limitations of pcap, and given the opportunity and the excuse
(which was ISC SIE) i had a lot of fun rethinking the problem space.  ncap
has changed the world in a good way, and all of your perl bindings, new
modules, and basic enhancements will be welcome in the base ncap distro.

> Which makes me extremely disappointed to hear that ncap is going into
> maintenance mode.  Is there _any_ chance that the nmesg stuff can be
> rolled into the ncap suite, and essentially become another input pipe
> into ncaptool?  I _really_ want to see ncap grow into an open source
> pluggable dns analysis tool suite, I'd hate to have to branch off and
> build stuff on our own.
> 
> Whatever you decide, thanks for what's been done already, everyone's very
> excited about using the ncap suite.

i don't expect that you'll have to fork ncap no matter what.  ISC will not
stop supporting it nor stop doing patch integration and release engineering
on ncap no matter what happens with nmsg.  also, the day is coming when
nmsg will be a proper superset of ncap in terms of total functionality.  we
have already got an ncap-to-nmsg stream converter, and nmsg has its own
plug-in system for analysis modules.  nmsg also supports some things we had
to have but couldn't shim into ncap, like multiple payloads per message,
fragmentation/reassembly of large payloads across multiple messages,
ability to carry orphaned fragments when sensor-level IP reassembly fails,
and etc.

if none of what's in nmsg is of interest then you won't have to switch to
it, since we're not going to stop fixing bugs or accepting community
patches or putting out new releases.

but if you do decide to switch from ncap to nmsg you'll find that the
concepts, the library, and the plug-in framework of nmsg is generally
similar to ncap, and you'll be able to port your plugins rather easily
(hours per module, not days).

i suppose i could apologize for "getting it wrong" in ncap.  the stuff that
turned out to be missing in a way that no backward-compatible format change
could add, is obvious in retrospect.  i really did shoot way to low, and i
ought to be ashamed of myself.  but i'm not -- i use ncaptool every day and
i love it.  and none of the stuff that nmsg has over ncap was in fact
obvious in a world that only had pcap in it, so, ncap was a necessary first
step.  so, ISC will have to support two suites, which is a small price for
such a large result.