wget not resolving domain names

[Paul Howarth]

On Wed, 2005-11-02 at 12:36 -0500, Derek Martin wrote:
> On Wed, Nov 02, 2005 at 05:06:47PM +0000, Paul Howarth wrote:
> > > > Hmm, that's interesting. Your nameserver appears to be returning bad 
> > > > data, though curiously the first answer was the right one in this case.
> > > 
> > > No, I don't think so...  The address returned is the same as in the
> > > first query; the answer is correct.  I believe the reason the data is
> > > different is because the first query showed authoritative data that
> > > the name server looked up, whereas the second query returned
> > > non-authoritative data that the name server had cached.
> > > 
> > > There seems to be nothing wrong with this -- the client got the same
> > > address in both cases.
> > 
> > No, the answer is wrong in the second case. Dig is a tool for doing
> > low-level DNS lookups, and the first response indicates that www.uit.no
> > is an alias for w3s2.uit.no (www.uit.no CNAME w3s2.uit.no in DNS), which
> > has IP address 129.242.5.89. Tbe second response misses out this
> > important distinction.
> 
> Ah yes, I overlooked that, for good reason.  While true, we're not
> talking about mail here... what was asked for using the dig command
> which was used was an A record, which was supplied.  It was the
> correct address.  The user was complaining that there was NO
> answer....  but that was not the case here.  The correct address WAS
> returned, albeit the CNAME was overlooked.  Granted this behavior is a
> little broken, but it does not account for the OP's problem.  It would
> not prevent wget from fetching the page.

You're right that it doesn't explain the OP's problem, but it does
indicate that there is a problem with the nameserver. Dig's normal
behaviour here would be to show the CNAME record and the A record every
time, because that's what should be being returned from the nameserver.

> > The distinction is important because, if say someone was to try sending
> > mail to webmaster at www.uit.no, what *should* happen is that the sender's
> > MTA should spot the CNAME record and rewrite the address as
> > webmaster at w3s2.uit.no, 
> 
> Well, what is supposed to happen is that the MTA first looks up the MX
> record for the host that you specified, and THAT is used -- ater that,
> if no MX record exists, it should do an A lookup and convert CNAMEs.

That's debatable because there should not be any MX records for a name
that has a CNAME record - see for example RFC 1912, section 2.4 "CNAME
records":

   A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.

> I don't think there's any indication in RFC 1123 that the MTA should
> then do an MX lookup on the canonicalized host, though this does make
> some sense.

This is also the behaviour of sendmail; don't know about other MTAs but
I would expect it to be the same.

> But this is just another example of a good reason not to
> use CNAMEs.  I never use them... they only create problems.

They're useful as long as you know what you're doing :-)
Too bad too many people don't :-(

Paul.
-- 
Paul Howarth <paul at city-fan.org>