gabriel rosenkoetter on Mon, 14 Jul 2003 19:47:15 -0400

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] dig returns "Transfer failed", what to do?

A: Because of this problem.
Q: Why do top replies suck so much?


> On Mon, Jul 14, 2003 at 08:46:54AM -0400, kaze wrote:
> > Does anyone know, is there some software or web sites that generate
> > all the info that would be in a zone file (doesn't have to in the
> > named zone format - I'll do that part), maybe from reverse lookups
> > against all the IPs in the domain's range or something?

And, in any case,'s reverse DNS looks to be
completely broken:

humbug:~% host is a nickname for has address mail is handled (pri=20) by mail is handled (pri=10) by
humbug:~% host
Host not found.

On Mon, Jul 14, 2003 at 10:41:07AM -0400, kaze wrote:
> Thanks, I'm getting it. But look below, I can get multiple FQDN from one IP
> using host -v doing a reverse lookup. If I knew all the Internet routable IP
> addresses of a given domain name would doing "host -v <each IP>" give me all
> the same mappings, albeit backwards, as getting the zone transfer?

Maybe, but probably (and, in this case, definitely) not. Forward and
reverse zones are wholly separate, and the forward zone contains, at
a minimum, the same amount of information as a forward zone, but
almost always more.

That is, a given IP address gets you a single PTR record (which
gives you a forward hostname, whose A record you can then query),
but there may be many forward names (by way of multiple A records or
CNAMEs, or MX records) that point to the same IP address.

> [root@rh9 root]# host
> has address
> has address

You will need to do this, forward, for each hosname in the zone. Do you know all of them?

Also, that's far from the most that you can know about
Try a host -a. And compare the output for,, and so forth.

On Mon, Jul 14, 2003 at 11:37:14AM -0400, epike wrote:
> that would be true if the hosts have a 1-1 mapping between
> the names and the IP's (and if the reverse mapping works
> correctly).  all yur going to get here is the canonical
> names...consider my hosts:

No, what he's getting is precisely *not* canonical names (CNAMEs).
He's getting pointer (PTR, reverse name) records and address (A)
records. That's precisely missing any extra A records and CNAMEs.

> localhost.localdomain[4]% host
> has address
> localhost.localdomain[5]% host
> has address
> you wont get these hostnames if you knew just the
> IP numbers.

... because you don't control, and you have
a (somewhat) backwards ISP that won't set reverse DNS entries for
you. (Check out the forward and reverse on, for
instance. Then do a reverse lookup on some of the neighboring IPs.)

On Mon, Jul 14, 2003 at 11:49:29AM -0400, kaze wrote:
> If I may restate the question: How can you collect the data needed to create
> zone files on an existing domain - other than simply doing a zone transfer
> from it?

By looking at the computers you think should exist within that zone
and creating new files. You simply cannot, reliably and in the
general case, replicate a zone without access to the zone's
information (and people frequently restrict zone transfers because
transferring zones is a decent way to get a feel for a network in
order to begin mounting an attack against it... if nothing else, it
lets you do a scan with a tool like nmap and set off fewer alarms by
not probing hosts that don't exist).

This isn't a wholly bad thing. It's quite possible there's out of
date garbage in the existing zone and, presuming it's not
tremendously large (I wouldn't even *consider* trying to
reconstruct, say, by hand), rebuilding from scratch
may be a good spring cleaning that would actually have been more
painful if you'd gone reading through the existing zone for stale

On Mon, Jul 14, 2003 at 01:09:30PM -0400, Ruse, Kevin KPSI wrote:
> lookup are different zone files and can contain different information. Also
> this will not include CNAMEs.

... nor duplicate A records. (Cf,,, and; my configuration
here is far from uncommon. See, even further,,,,, and

gabriel rosenkoetter

Attachment: pgpohFA73bm8u.pgp
Description: PGP signature