[CentOS] Split dns issues

[Les Mikesell]

Jason Pyeron wrote:
>> -----Original Message-----
>> From: centos-bounces at centos.org 
>> [mailto:centos-bounces at centos.org] On Behalf Of Les Mikesell
>> Sent: Sunday, August 02, 2009 16:21
>> To: CentOS mailing list
>> Subject: Re: [CentOS] Split dns issues
>>
>> Christoph Maser wrote:
>>> Am Sonntag, den 02.08.2009, 21:16 +0200 schrieb Jason Pyeron:
>>>> We have internal DNS servers that will override the A 
>> record for selected hosts.
>>>> Example mail.pdinc.us will have a different internal ip than 
>>>> external. This has always been a fine way to handle it as the zone 
>>>> files are for that specific host, and there have never 
>> been subdomains before.
>>>> Now we want to just override the MX records for pdinc.us without 
>>>> having to merge or manage all the records for every 
>> entry/subdoamin 
>>>> in the zone file for pdinc.us.
>>>>
>>>> Any ideas/questions?
>>> Bind supports split view out of the box check the documentation the 
>>> keywod is "view"
>> Bind will do split views, but unless you are short on 
>> machines it is easier to just point internal machines at 
> 
> That is what we currently have, separate machines for each role and task.
> 
>> different servers which are configured as primary/secondary 
>> for the zone and put only the public view on exposed machines 
>> that are registered as the official masters.  And if you are 
>> short of machines, you might want to outsource the public DNS 
> 
> We do that too.
> 
>> anyway.  The public side typically only needs a few addresses 
>> that rarely change so it is not difficult to maintain 
> 
> They frequently change, and it can be problematic.
> 
>> separately and if they are separate there is no need to 
>> permit recursive lookups on the public-facing servers.
> 
> INTERNET                               DMZ
> INTRANET
> _____________________            ______________________
> __________________________________
> [ns1&2.outsourced] -> [firewall]-> [ns1.pdinc.us] -\
>                                 \->[ns2.pdinc.us] ----> [firewall] -->
> [nsmaster.pdinc.us] -> [ns.intranet.pdinc] ------|
> [mail/spam.outsourced] -> [firewall] <-> [mail.pdinc.us] <-> [firewall] <->
> [mail.pdinc.us]  <-->  [internal clients]<--/
> [any joe's smtp] <-------/
> 
> 
> See:
> 
> [root at localhost ~]# host -t mx pdinc.us
> pdinc.us mail is handled by 200 pdinc.us.s8a2.psmtp.com.
> pdinc.us mail is handled by 300 pdinc.us.s8b1.psmtp.com.
> pdinc.us mail is handled by 400 pdinc.us.s8b2.psmtp.com.
> pdinc.us mail is handled by 100 pdinc.us.s8a1.psmtp.com.
> [root at localhost ~]# host mail.pdinc.us
> mail.pdinc.us has address 67.90.184.27
> [root at localhost ~]# host mail.pdinc.us 192.168.1.10
> <snip/>
> mail.pdinc.us has address 192.168.1.50
> [root at localhost ~]#
> 
> On ns.intranet.pdinc.us:
> Named.conf: 
> zone "mail.pdinc.us." IN{ type master; file "zones/us/pdinc/mail.zone";};
> 
> [root at localhost pdinc]# cat mail.zone
> $TTL    86400
> mail.pdinc.us.          IN SOA  mail.pdinc.us.       root (
>                                         42              ; serial (d. adams)
>                                         3H              ; refresh
>                                         15M             ; retry
>                                         1W              ; expiry
>                                         1D )            ; minimum
> 
>                 IN NS           192.168.1.10
>                 IN A            192.168.1.50
> 
> 
> While our dns setup works fine for our client laptops traveling in and out of
> our intranet, every default sendmail is pushing mail out of our intranet, just
> to be spam checked and returned later that day.
> 
> Now if we do this with the pdinc zone file we would have to keep all the
> subdomains (hundreds, changing daily) in sync.
> 
> Ug.
> 

You could just firewall port 25 on the spam-checking MX relays from the trusted 
networks  and add a high-numbered MX record for the target you want them to hit 
instead.  As long as the firewall sends an ICMP 'denied' message instead of just 
dropping the packet (and no other firewall blocks it), the sending sendmail will 
retry the alternatives very quickly.  The public side should always try the 
lowest valued MX first and not be affected.

-- 
   Les Mikesell
    lesmikesell at gmail.com