[CentOS] Split dns issues

Jason Pyeron jpyeron at pdinc.us
Sun Aug 2 21:45:30 UTC 2009


> -----Original Message-----
> From: centos-bounces at centos.org 
> [mailto:centos-bounces at centos.org] On Behalf Of Les Mikesell
> Sent: Sunday, August 02, 2009 17:38
> To: CentOS mailing list
> Subject: Re: [CentOS] Split dns issues
> 
> 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 

They are outsourced to google, we cannot control that.

> relays from the trusted networks  and add a high-numbered MX 
> record for the target you want them to hit instead.  As long 

Adding mail.pdinc.us to the list would beg spammers to skip our spam gateway
service.
And I think adding the non routable Ips assigned to the intranet mail.pdinc.us
server to public MX records might be a bit of bad form and add a point of
failure when the ip address changes.

> 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.



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.




More information about the CentOS mailing list