🚀 go-pugleaf

In article <1992Nov3.033257.19681@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>In article <1992Nov3.000641.21040@synapse.bms.com> zilaitis@synapse.bms.com (Vicki Zilaitis) writes:
>>
>>   The following wildcard does not work for hosts inside our domain 
>>   if they have an A record but not an MX entry in the DNS. Yet the
>>   lookup works for hosts that do not have an A record:
>
>That is part of the definition of wildcards.  They only apply if the name
>is not otherwise present in the database structure.
>
>>   This problem is compounded by the problem that in non-literal
>>   lookups the domain name is appended twice.   
>
>You have stumbled upon one of the disadvantages of wildcards.  They match
>any bogus name, if that name is first qualified in your domain.
>
>The best advice is that if you are on Internet, avoid wildcards.  They
>are mainly useful systems not directly on Internet, and which therefore
>cannot easily maintain their own records.

If wildcard MX'es are a _requirement_, though, then there are some options
open to you:

	A) Replace your mailer with something that allows the disabling of
	   the RES_DNSRCH flag on MX lookups. This will alleviate bogosities
	   like lookups for "foo.bar.com.bar.com". However, the downside is
	   that, unless you can somehow teach your mailer to disable 
	   RES_DNSRCH on _only_ the first MX lookup, but also follow behind
	   with another lookup, with RES_DNSRCH enabled, it may become 
	   impossible for your users to employ partially-qualified addresses.
	   In other words, if you are a user on a host in the domain 
	   "a.foo.com", you may lose the ability to mail to a host in the 
	   "b.foo.com" domain by simply saying "<user>@<host>.b". Depending 
	   on your users, and their mail software, this may or may not be a 
	   problem for you.

		or...

	B) UGLY ALERT!!! "Block" bogus subdomains with fake MX'es. I've never 
	   actually brought myself to do this in production, but in theory it 
	   should be possible to add MX'es for top-level or mid-level domains 
	   _underneath_ your wildcards, so that bogus lookups will designedly
	   fail. E.g. one could have

$ORIGIN cfc.com
*			IN	MX	0 cfctech
bogus.mx.from.hell.edu	IN	MX	0 cfctech

	   Now, anyone in the "cfc.com" domain who tries to route to, say
	   "podunk.edu", will, given the RES_DNSRCH logic, first generate an 
	   MX query for "podunk.edu.cfc.com". This will fail, since 
	   "edu.cfc.com" and everything below it has been blocked in the 
	   namespace. The next query, given the algorithm, will be for 
	   "podunk.edu", which should route as expected. Successively deeper 
	   subdomains will of course require more fake MX'es, and potentially 
	   generate more wasted query traffic.  The disadvantages of this 
	   approach are many. Numbered among them is the necessity to keep 
	   every nameserver up-to-date with all of the various "blocking" 
	   MX'es. Also, if anyone (maliciously?) ever sends to the fake MX, 
	   e.g. "bogus.mx.from.hell.edu.cfc.com", you need to ensure that 
	   the receiving machine is equipped to deal with such an address 
	   without causing a mail loop.

------------------------------------------------------------------------------
kevin@cfctech.cfc.com 		  | Kevin Darcy, Unix Systems Administrator
...heifetz!cfctech!kevin 	  | Technical Services (CFC)
Voice: (313) 759-7140 		  | Chrysler Corporation
Fax:   (313) 758-8173 		  | 25999 Lawrence Ave, Center Line, MI 48015
------------------------------------------------------------------------------