Posting to Newsgroup

[Kevin Darcy]

Bryan A. Zimmer wrote:

> On Monday 09 July 2001 07:09 pm, you wrote:
> > Bryan A. Zimmer wrote:
> > > Dear Paul:
> > >
> > > I had this exact problem once before and tore my hair out for a whole
> > > weekend recreating and testing my zone and conf files. I really have
> > > sympathy for your plight.
> > >
> > > In the following examples, imagine your domain is "yourdomain.com" and
> > > your address range is
> > > 201.202.123.176, netmask 255.255.255.240 (201.202.123.176 thru 191)
> > >
> > > Check the following:
> > > 1. The first lines in your /etc/resolv.conf should read
> > >
> > > search yourdomain.com
> > > nameserver host1.yourdomain.com
> > > (etc.)    ......
> >
> > No, you can't use DNS names in the "nameserver" directive, at least this
> > doesn't work on any OS I know of. Doing so creates a nasty chicken-and-egg
> > problem: how is your resolver supposed to resolve "host1.yourdomain.com" if
> > it can't resolve "host1.yourdomain.com" to know where to send the DNS
> > query? You *have* to use an IP address here (unless somehow your OS'es
> > resolver has been hacked to resolve this from /etc/hosts or something
> > asinine like that).
> >
>
> Absolutely right, my mistake. Sorry! The "nameserver" directives in
> /etc/resolv.conf need to point at dotted-quad IP addresses and NOT to host
> names.
>
> "nameserver 192.168.1.5 "
>
> is what I should have had the presence of mind to remember.
>
> My apologies for that blunder.
>
> > > Finally, allow me to put in a good word for the utility "h2n", which is a
> > > Perl program that essentially takes your /etc/hosts file and, with a
> > > bunch of command line parms, creates some pretty nice zone and
> > > configuration files. You may have to go in and clean up a bit, but the
> > > utility will give you a good start if you are stuck. It is available on
> > > ftp.isc.org.
> >
> > GRRR, pet peeve... "You may have to go in and clean up a bit". If you've
> > outgrown "h2n" to the point where you have to "clean up a bit", then DON'T
> > USE h2n!!!! Make DNS your central repository for hostname information;
> > there are a plethora of tools available to maintain DNS directly without
> > having to go through a hosts file and/or h2n. And, of course, with DNS as
> > your central repository, you can still generate an /etc/hosts file from
> > DNS, if for some extraterrestrial reason you still need an /etc/hosts
> > file...
> >
>
> Yes, I understand you, I just meant that h2n can create the basic db files at
> a time when someone untrained at creating zone and conf files is having fits
> because of minor syntax errors, etc. and needs to get named up and running
> pronto.
>
> I still have a lot to learn (obviously); but I certainly would be interested
> in the "plethora" of tools for maintaining DNS which you mentioned. I'm only
> aware of a scant few, so if you have any recommendations, I am all ears.
> Personally I favor open-source but I will pay a reasonable amount for an
> excellent tool.

Actually, I should probably have qualified that with "I understand there is a
plethora...". I wrote my own DNS maintenance tools, so I actually haven't had
any need to look for others. Some other folks here adapted some code from the
University of Utah, which has a much prettier web interface. (Now that we're all
in the same group, we're working on integrating their frontend to my Dynamic
Update-based backend). And many folks swear by the DNS module of webmin. There's
Ganymede, too. There are other free ones which don't immediately come to mind.
Then of course there are the commercial offerings like NetID, QIP and so
forth...

> -------------------------------------------------------
> Sudden topic switch:
>
> I am still trying to figure out the programming API for the resolver and name
> server library/interface on a Unix/BIND (or even Win2000) system. The DNS and
> BIND book (the O'Reilly one) says in chapter 14, "the easiest way to learn
> how to parse a DNS packet is to look at the code that already does it...".
> Then he recommends studying "res_debug.c" (from BIND 8.1.2) and the p_query
> and fp_query routines.
>
> Yet, things are different now with BIND version 9. Is there any sort of
> guidebook for programmers, or is this sort of guruhood only acquired by
> grinding, nitty experience?

I certainly don't consider myself a BIND 9 "guru". Probably no-one is a BIND 9
source-code guru except the people who wrote it. And as for "grinding, nitty
experience", BIND 9 hasn't been out that long...

> Or by poring over RFC's?

Knowing the protocol certainly helps to understand the code, but on the other
hand many things in a DNS implementation aren't defined by the protocol, or are
left optional or unclearly specified. The RFCs serve only as a reference point.

> I am trying to get down as far as I can go, perhaps I will be able to have a
> go at the actual BIND source code someday.

A word of advice: don't bother with the BIND 8 source code if you're eventually
planning on working with BIND 9. When they say "complete rewrite", they mean
it! There's really *no* similarity at all between the two code bases. Obviously
the rewrite is a good thing in the long run. But the learning/familiarization
curve for BIND 9 is much steeper. At least, that's my experience so far.

> For now I just want to create and
> parse resolver packets and resource records, to have a fine grained control
> over my servers and incidentally understand more about DNS as a whole. ( If
> IPv6 became current tomorrow, I would have to return to grade school).
>
> For now, I need a programming API that can do the basic stuff. Perl is fine,
> but C, assembly (really!) or other languages (C++, Java, Python?) have the
> low-level capabilities I'm looking for. Particularly C or similar languages.
> Maybe even Forth.

How low-level do you need to go? I've been using the Net::DNS Perl module
lately, and it gives you access at the RR level, differentiated by section, and
all of the relevant bits of the header. You can even do Dynamic Update with it,
theoretically (although I haven't used that part yet). About the only thing it's
missing is the newer A6 and DNSSEC stuff. What's more, since it's Perl, you
don't have to fart around with defining your own data structures; you can use
Perl's lists, hashes, references, etc., and you don't have to compile anything
or worry about version- or platform-compatibility. Also, if you're doing
DNS stuff in conjunction with some other API (e.g. most of my Net::DNS stuff
lately has consisted of cute little CGI scripts), you can just pull in some
other module (e.g. the CGI module, LDAP module, mysql module or whatever) and do
what you need with that module from the same script, without having to deal with
some blecherous, over-engineered "C" API and link with a zillion bloated
libraries.

Gee, I sound like an advertisement...

> Any resource pointers would be appreciated. Old, public-domain programs,
> whatever.
>
> If it tells you anything about why I would want to do this, I spent probably
> three or four long (22-hour) weekends plus some late nights troubleshooting
> BIND and Sendmail, which both "broke" unexpectedly after I physically moved
> equipment and reconfigured my LAN ethernet topology, switches, routers, etc.
>
> I was a named and sendmail maniac during those times, studying how they work
> together, learning the arcane syntax that both tend to use, etc., and trying
> to the utmost to have working mail and name service (and http and ftp and ssh
> and so on). Without DNS and Sendmail, my operations came screeching to a
> halt. Workstation PC's, unable to reach their servers, ground to a bleeding
> halt, It was a mess --- although I learned quite a bit from it all.
>
> So I am not exactly a newbie at either BIND or Sendmail, but the more I learn
> about these and other internet programs, the more I realize I don't know.
> Surprise! There is always more...

BIND and sendmail. One could almost make an entire career (if not a religion :-)
out of just those two software packages


- Kevin