The ever-changing nature of dig

[McNutt, Justin M.]

> I've been using dig since BIND 4.9.x (dig 2.2), and I've found that
> each new major release of BIND seems to change the way that dig works
> - and not always for the better.

Like most developers, I'm sure the people at ISC get caught in the same two
traps as everyone else.  "Change" all too often looks like "progress", and
then there's "we thought it would be better, but it wasn't."  :-)

> The result of this is that I'm still using the old dig 2.2 because
> otherwise none of my DNS scripts will work, and I'm loathed to change
> the scripts for fear of the next change breaking them again.

This is unwise.  You can't choose not to change just because you might have
to change again.  In fact, if you wrote robust scripts, they would change
their behavior based on the version of dig.  What are you using for your
scripting?  This all sounds like it would be fairly simple in Perl using
hashes to contain your regexp's and the dig version number as the hash key.

> However, I don't want to keep using dig 2.2 because it's an old libc5
> binary, and I can't compile the source any more on my libc6 system
> (Debian GNU/Linux 2.2r4) - I get lots of compilation errrors.

Now there's a good reason to change.  :-)

> Here's what I've noticed:
> 
> dig 2.2 - Still the best version as far as I'm concerned.

"Remember when dig usda work right?  And all the women were strong, the men
were good-looking, and all the children were above-average..."  Heh.

> dig 8.2 
> 
> a) Displays TTLs in user-friendly format rather than seconds e.g. 4H
> rather than 14400

Perl:

# Sting is only numbers.
if ( $timeval =~ /^(\d+)$/ ) {
	# Time is in seconds.
	$time = $1;
# String is numbers, then a letter.
} elsif ( $timeval =~ /^(\d+)(\w)$/ ) {
	# Time is in seconds, $timeval is 'user-friendly'.
	$time = $1;
	if ( $2 eq 'M' ) { $time *= 60; }
	if ( $2 eq 'H' ) { $time *= 3600; }
	if ( $2 eq 'D' ) { $time *= 86400; }
 	...
}

> b) Uses spaces rather than tabs to separate  the fields.
> e.g. "domain<sp><sp>ttl<sp><sp>IN<sp><sp>A<sp><sp>IP-Addr" rather than
> "domain<tab>ttl<tab>A<tab>IP-Addr".

Perl:

The regexp /\s+/ matches one or more whitespace characters, including spaces
or tabs.  If you don't want to use Perl for everything, you could also still
use Perl to make your life easier by doing:

@TEMP = `dig ...`;
foreach ( @TEMP ) {
	# Replace tabs with spaces.
	$_ =~ s/\t/ /g;

	# Print to STDOUT.
	print;
}

Then your other scripts can expect spaces for dig output from any version.

> c) Includes the class (e.g. IN) in the output, and provides no way to
> remove it.  "dig +nocl" does not work (c.f. dig 2.2 where "dig +cl"
> _did_ add the class if you happened to want it).  It looks like the
> print flags are not being handled properly.

Probably a genuine bug.  Have you reported it to ISC?

> dig 9.1.x
> 
> a) TTLs have gone back to seconds (thank goodness).

So your scripts only need to detect the (digits)(char) for dig 8.x.

> b) Most of the print flags seem to have been removed - e.g. no
> "+pfmin".

Perhaps they are phasing these out then?  Or they have changed and are
undocumented?  Again, might be worth contacting the developers at ISC to see
what their plan is and modify your scripts based on that answer.  If they're
going to support the flags, you might wait until they're fixed.  If not,
you'll have to modify your scripts, but at least you'll know it isn't for
nothing.

> Has anyone else found the same problems?  Am I looking at this the
> wrong way, or using the wrong tool for scripting DNS stuff?

If you mean dig, no I'd say dig is the right tool, but you didn't mention
what scripting language you're using.  Bourne shell scripts?  Perl?  Tcl?
Python?

I have found the same problem before, but not just with dig.  Since all
software has a tendency to change its 'look' over time, I've taken to
looking for patterns in text (patterns that are as generic as possible)
rather than specific things.  It makes the scripts more tolerant of version
changes.  My suggestion would be to contact the developers for dig and ask
them what's up.  They may not give you the answers you'd like, but at least
you'll have an idea of what direction they're headed.  Let that guide your
own scripting.

--J