RecordAdd should ignore duplicates, but will add a record if some parameter is different. You can have 2 different A records for the same host with different IP addresses and use DNS round robin for poor man’s load balancing.

To capture the output, like most windows scripts, you can just pipe it into a file. Example:

dnscmd /enumzones > zones.txt
for /f %%a in (zones.txt) do dnscmd /enumrecords %%a @ > %%a.txt

There I am listing all the zones on my server and putting it into zones.txt. I am then using a FOR command to parse that file to be used by the /enumrecords command. I send the output for each zone into a file %zonename%.txt.

In your case for deleting records, you could then parse the approprate zone records. Just do an enumrecords on the zone, pipe it to a file, and then parse that file into variables. After that, you issue 2 record delete commands. The syntax from M$ is:

dnscmd ServerName /recorddelete ZoneName NodeName RRType RRData[/f]

You’d need 1 line for the A record and one for the PTR record. This may seem like a lot of work, but write your script once and you’ll never have to think about it again.

When using a FOR script, you can parse a multi-column text file with the value of each column being a seperate variable. You use the /delims switch to specify how the columns are seperated and the /tokens switch to specify which tokens you want. You can get the full syntax here:
http://technet.microsoft.com/en-us/library/cc754900%28WS.10%29.aspx

I hope this helps.

-Bill

How can I capture the output of one dnscmd to use as input for another? What if I want to delete records? To delete the PTR record, I’d need to query for the value of the A record. Then issue another command to delete the PTR record from the appropriate backup zone? Then delete the A record. Examples?

We also store our DNS records in a version control repository where all changes
are audited, tested, and tagged before being pushed out to production. This is
real change _control_. What you’re talking about is change monitoring. You
don’t know about changes until after they wreaked havoc without the benefit of
knowing who did it.

The DNS records are stored in plain text in the VCS with a custom grammar that
keeps the records normalized. We define the hostname -> IP address pairing once
with additional meta-data that identifies what zones the forward and reverse
belong to as well as if it should create static DHCP host entries. Using this
we can generate the zone databases on the fly with triggers from a
configuration management system that detects commits to the repository. The
configuration management system also guarantees –within reason– that what is
in the repository is what is on the production boxes. If we want another DNS
server, we setup a minimally configured box, point the CMS at it, and ten
minutes later, it’s serving up zones or anything else we need to have it doing.

I can command the entire thing –without ever touching the production boxes by
hand– with nothing but a text editor, programming environment of choice and a
git/svn client. In fact, with TortoiseSVN, we even have our first-tier user
support staff making changes to the repository. Even if they screw it up, the
changes never make it to production.

You keep talking about the right tool for the job, but if you’re maintaining a
large BIND installation using pico, ssh and for-loops, you’re not following
your own advice. No wonder you like AD.

Frankly, I can’t imagine a scenario where UNIX doesn’t have the right _set_
–not necessarily a single uber one– of tools for any particular job. The
right-tool-for-the-job mantra is usually just personal bias thinly veiled as
pragmatism. If you like MS junk, fine; keep using it. Your experience is still
only anecdotal.