Overriding MX records to internal gateways
Mark Andrews
Mark_Andrews at isc.org
Thu May 8 04:55:23 UTC 2008
> Mark Andrews wrote:
> >> Phaniraj Ranganath wrote:
> >>
> >>> On Tue, May 6, 2008 at 6:52 AM, Barry Margolin <barmar at alum.mit.edu> wrote:
> >>>
> >>>
> >>>> In article <fvn7a4$1ire$1 at sf1.isc.org>,
> >>>> "Pedro Espinoza" <raindoctor at gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Sat, May 3, 2008 at 11:47 AM, Josh Smith <juicewvu at gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>> Why not just configure your MTA to use your internal gateway(s) as
> >>>>>>
> >>>>>>
> >>>> smart
> >>>>
> >>>>
> >>>>>> hosts?
> >>>>>>
> >>>>>>
> >>>>> I asked this question, because my shop has this setup; and I am trying
> >>>>> to understand how they set up. Here is the sample dig results, for
> >>>>> google.com A, MX, NS
> >>>>>
> >>>>>
> >>>> Are they running BIND?
> >>>>
> >>>> It's curious that the A response has the AA flag set, even though it's
> >>>> returning a response that's apparently cached, while the MX response
> >>>> does NOT have the AA flag set, even though it's returning the local
> >>>> override.
> >>>>
> >>>>
> >>>>
> >>>>> # dig @a.b.example.com google.com ns
> >>>>>
> >>>>> ; <<>> DiG 9.3.2 <<>> @a.b.example.com google.com ns
> >>>>> ; (1 server found)
> >>>>> ;; global options: printcmd
> >>>>> ;; Got answer:
> >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3595
> >>>>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
> >>>>>
> >>>>> ;; QUESTION SECTION:
> >>>>> ;google.com. IN NS
> >>>>>
> >>>>> ;; AUTHORITY SECTION:
> >>>>> com. 1800 IN NS abc200.a.example.com.
> >>>>> com. 1800 IN NS abc201.a.example.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>> # dig @a.b.example.com google.com a
> >>>>>
> >>>>> ; <<>> DiG 9.3.2 <<>> @a.b.example.com google.com a
> >>>>> ; (1 server found)
> >>>>> ;; global options: printcmd
> >>>>> ;; Got answer:
> >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3193
> >>>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
> >>>>>
> >>>>> ;; QUESTION SECTION:
> >>>>> ;google.com. IN A
> >>>>>
> >>>>> ;; ANSWER SECTION:
> >>>>> google.com. 19 IN A 72.14.207.99
> >>>>> google.com. 19 IN A 64.233.187.99
> >>>>> google.com. 19 IN A 64.233.167.99
> >>>>>
> >>>>>
> >>>>>
> >>>>> # dig @a.b.example.com google.com mx
> >>>>>
> >>>>> ; <<>> DiG 9.3.2 <<>> @a.b.example.com google.com mx
> >>>>> ; (1 server found)
> >>>>> ;; global options: printcmd
> >>>>> ;; Got answer:
> >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18239
> >>>>> ;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 6
> >>>>>
> >>>>> ;; QUESTION SECTION:
> >>>>> ;google.com. IN MX
> >>>>>
> >>>>> ;; ANSWER SECTION:
> >>>>> google.com. 1800 IN MX 6 relay1.example.com.
> >>>>> google.com. 1800 IN MX 6 relay2.example.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Thanks,
> >>>>>> Josh
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, May 2, 2008 at 3:56 PM, Kevin Darcy <kcd at chrysler.com> wrote:
> >>>>>> >
> >>>>>> > Pedro Espinoza wrote:
> >>>>>> > > Gurus:
> >>>>>> > >
> >>>>>> > > is it possible with BIND to replace authoritative MX records
> >>>>>>
> >>>>>>
> >>>> with
> >>>>
> >>>>
> >>>>>> > > internal gateways, so that the MTA can route the email to
> >>>>>>
> >>>>>>
> >>>> internal
> >>>>
> >>>>
> >>>>>> > > gateways? Of course, sendmail/postfix provides a solution to do
> >>>>>>
> >>>>>>
> >>>> that.
> >>>>
> >>>>
> >>>>>> > > But I am looking at DNS level, as follows:
> >>>>>> > >
> >>>>>> > >
> >>>>>> > >
> >>>>>> > > ;; QUESTION SECTION:
> >>>>>> > > ;gmail.com. IN MX
> >>>>>> > >
> >>>>>> > > ;; ANSWER SECTION:
> >>>>>> > > gmail.com. 870 IN MX 10
> >>>>>> > > localrelay1.example.com.
> >>>>>> > > gmail.com. 870 IN MX 50
> >>>>>> > > localrelay2.example.com
> >>>>>> > >
> >>>>>> > >
> >>>>>> > You'd have to have a "private" version of the whole gmail.comzone.
> >>>>>> >
> >>>>>> >
> >>>>>> > -Kevin
> >>>>>> >
> >>>>>> >
> >>>>>> >
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Josh Smith
> >>>>>> email/jabber: juicewvu at gmail.com
> >>>>>> phone: 304.237.9369(c)
> >>>>>>
> >>>>>> () ascii ribbon campaign - against html e-mail
> >>>>>> /\ www.asciiribbon.org - against proprietary attachments
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> --
> >>>> Barry Margolin, barmar at alum.mit.edu
> >>>> Arlington, MA
> >>>> *** PLEASE don't copy me on replies, I'll read them in the group ***
> >>>>
> >>>>
> >>>>
> >>> Does it work like this ...
> >>>
> >>> Following entry should direct all mails to relay host which in turn tries t
> >>>
> >> o
> >>
> >>> resolve destination domain name.
> >>> If relay host is able to resolve domain name in internet namespace mail
> >>> deliver happens.
> >>> google.com. 1800 IN MX 6 relay1.example.com.
> >>> google.com. 1800 IN MX 6 relay2.example.com.
> >>>
> >>>
> >>> Please let me know if my observation is correct.
> >>>
> >>>
> >>>
> >> Well, yes, but
> >> 1. relay1.example.com and relay2.example.com would, in fact, need to be
> >> configured to allow relaying of google.com mail (most mail software
> >> these days disable relaying by default, since open relays are used
> >> extensively by spammers).
> >> 2. In BIND, in order to override the google.com MX records, you'd have
> >> to define a private version of the whole google.com *zone*. How then are
> >> your users going to access Google, unless you have some way to
> >> constantly keep that private zone (except for the MX records) in sync
> >> with the "real" google.com zone on the Internet? Bit of a conundrum eh?
> >>
> >>
> >> - Kevin
> >>
> >
> > For google.com I would just overide smtp1.google.com ...
> > smtp4.google.com.
> >
> > google.com. 10800 IN MX 10 smtp2.google.com.
> > google.com. 10800 IN MX 10 smtp3.google.com.
> > google.com. 10800 IN MX 10 smtp4.google.com.
> > google.com. 10800 IN MX 10 smtp1.google.com.
> >
> If Google ever changed the targets of those MX records it would break of
> course...
Correct.
> - Kevin
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users
mailing list