Dns tries to qualify a domain not found by appending its domain

[The Borg]

Hello Kevin,

My hat is off to you. This was exactly the answer I was looking for. Just
made my night a little better (It's 4am and I'm awake because my support
people called paniced that our T3 line was down. Turns out UU.net is
performing maintenance on a router in Boston)

My company is a webhosting company who puts about 200 user's domains on each
Solaris 7 box. Each virtual domain's users use Sendmail to send their email.
We have a rule in place that each client must check his pop account before
he sends email to the smtp server. When the user checks his or her email the
we grap his IP from the poplog and append it to a txt file. Sendmail then
checks this text file to see if it should allow the sending of mail for this
IP.

We have been getting spam complaints lately that email people are receiving
has in the header an entry like...

spammer at bogusdomain.com.mydomain.com

I believe that it was sent somehow on our Sendmail server Probably through a
valid IP but had a bogus return address. When Sendmail tried to resolve the
sending domain it failed with the bogusdomain.com but worked when the
resolver appended Mydomain.com to it. I don't fully understand the details.
I am an NT admin who is still learning unix tricks. Any info you could lend
would be greatly appreciated. I feel that the spam could have also been
generated programatically using something like formail.pl in this case I
imagine that Sendmail knows enough to allow an IP from it's own class C
block to send. I don't know if it tries to resolve the "from" or "reply-to"
address (I wouldn't think so). I would think that sendmail would only ask
the resolver to resolve the "to" address (or maybe that's what the "address
could be forged" message is about?)

Anyway sorry to write such a long response. I think it's great that people
like yourself take the time to share the knowledge that you have to with
anonymous network admins.

- Marty Lonergan (A.K.A. Lonie,The Borg)

"Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
news:3907743E.740811CE at daimlerchrysler.com...
> The Borg wrote:
>
> > I have a Solaris box that when you try to do an nslookup on a domain, if
it
> > can not find the domain then it appends it's own domain to the end of
the
> > domain and then resolves it.
> > example
> > nslookup nonexistantdomain.com
> > answer nonexistantdomain.com.mydomain.com
> >                208.230.11.1
> >
> > it resolves to my main domain because I have a record with an * in the
> > db.mydomain.com file to catch all nonexistant hostnames.
> >
> > Any answers... please send email to lonie at mediaone.net -  greatly
> > appreciated
>
> The domain-appending is a function of the resolver, not the nameserver. If
you
> rip the "domain" and/or "search" directives out of /etc/resolv.conf, and
have
> no so-called "NIS domain" set via the "domainname" command (see
> /etc/rc2.d/S69inet, which uses the contents of the /etc/defaultdomain
file),
> then the Solaris resolver won't have any idea what domain you're in and
won't
> append anything. Of course, this will inhibit the ability to use short
names
> for hosts (probably no big loss), and may also have a negative impact on
> things like sendmail, which use the "NIS domain" by default to
> "canonify" names and format headers correctly (although, as the man page
for
> "domainname" describes, it is possible to make separate arrangements for
> sendmail).
>
> Another option is to leave the resolver behavior as is, but "block" bogus
> matches by defining all of the TLD's in your main domain, e.g.
> com.mydomain.com, net.mydomain.com, org.mydomain.com, all of the
> country-codes, etc. You could just put something innocuous like TXT
records
> for each of these. Once those records exist, they will take precedence
over
> the wildcard and thus prevent bogus matches.
>
> Just out of curiosity, why do you need a wildcard A record anyway? As you
can
> see, they tend to be problematic.
>
>
> - Kevin
>
>
>
>