> -----Original Message-----
> From: centos-bounces@xxxxxxxxxx
> [mailto:centos-bounces@xxxxxxxxxx] On Behalf Of Les Mikesell
> Sent: Sunday, August 02, 2009 17:38
> To: CentOS mailing list
> Subject: Re: Split dns issues
>
> Jason Pyeron wrote:
> >> -----Original Message-----
> >> From: centos-bounces@xxxxxxxxxx
> >> [mailto:centos-bounces@xxxxxxxxxx] On Behalf Of Les Mikesell
> >> Sent: Sunday, August 02, 2009 16:21
> >> To: CentOS mailing list
> >> Subject: Re: 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@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@localhost ~]# host mail.pdinc.us mail.pdinc.us has address
> > 67.90.184.27 [root@localhost ~]# host mail.pdinc.us 192.168.1.10
> > <snip/> mail.pdinc.us has address 192.168.1.50 [root@localhost ~]#
> >
> > On ns.intranet.pdinc.us:
> > Named.conf:
> > zone "mail.pdinc.us." IN{ type master; file
> > "zones/us/pdinc/mail.zone";};
> >
> > [root@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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
