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?
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
On Sun, Aug 02, 2009, Jason Pyeron wrote:
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?
We have been doing this with djbdns for years. The tinydns data files permit suffixes (suffices?) based on the querying IP address to return information specific to that IP range. That is a request for support@example.com from an ip in 192.168.0.0/16 may return the private LAN address while one from the outside world the public IP, perhaps on a different server.
Bill
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Bill Campbell Sent: Sunday, August 02, 2009 15:20 To: centos@centos.org Subject: Re: [CentOS] Split dns issues
On Sun, Aug 02, 2009, Jason Pyeron wrote:
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?
We have been doing this with djbdns for years. The tinydns data files permit suffixes (suffices?) based on the querying IP address to return information specific to that IP range. That is a request for support@example.com from an ip in 192.168.0.0/16 may return the private LAN address while one from the outside world the public IP, perhaps on a different server.
Sounds like what we could use, but we are deeply entrenched in bind. Secondly is it available from the upstream provider?
Bill
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792
The difference between science and the fuzzy subjects is that science requires reasoning while those other subjects merely require scholarship. -- Robert Heinlein _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jason Pyeron Sent: Sunday, August 02, 2009 15:52 To: 'CentOS mailing list' Subject: Re: [CentOS] Split dns issues
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Bill Campbell Sent: Sunday, August 02, 2009 15:20 To: centos@centos.org Subject: Re: [CentOS] Split dns issues
On Sun, Aug 02, 2009, Jason Pyeron wrote:
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?
We have been doing this with djbdns for years. The tinydns
data files
permit suffixes (suffices?) based on the querying IP
address to return
information specific to that IP range. That is a request for support@example.com from an ip in 192.168.0.0/16 may return the private LAN address while one
from the
outside world the public IP, perhaps on a different server.
Sounds like what we could use, but we are deeply entrenched in bind. Secondly is it available from the upstream provider?
Grepping through yum shows pdns, looks spiffy and may outway our bind investment. But still cannot answer the question at hand about slit dns with it.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
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"
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
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 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 anyway. The public side typically only needs a few addresses that rarely change so it is not difficult to maintain separately and if they are separate there is no need to permit recursive lookups on the public-facing servers.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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@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.
-Jason
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
Jason Pyeron wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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@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.50While 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.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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@centos.org [mailto:centos-bounces@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@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.50While 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.
Jason Pyeron wrote:
You could just firewall port 25 on the spam-checking MX
They are outsourced to google, we cannot control that.
You must have a firewall that you control on your side where these connections have to pass.
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.
That's fine, as they would be unable to connect if you leave it a private address.
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.
It's a bit of bad form to use NAT and private addresses at all because the internet really wasn't designed to be segmented, but everyone does it. Or you could use a public address in a DMZ where it is firewalled from everything but internal connections and perhaps things relayed by the external spam service. The point of being able to provide multiple MX records is that things keep working even if some of them aren't reachable.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Sunday, August 02, 2009 18:20 To: CentOS mailing list Subject: Re: [CentOS] Split dns issues
Jason Pyeron wrote:
You could just firewall port 25 on the spam-checking MX
They are outsourced to google, we cannot control that.
You must have a firewall that you control on your side where these connections have to pass.
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.
That's fine, as they would be unable to connect if you leave it a private address.
Just feels dirty.
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.
It's a bit of bad form to use NAT and private addresses at all because the internet really wasn't designed to be segmented, but everyone does it. Or you could use a public address in a DMZ where it is firewalled from everything but
We are working towards that, but our provider does not want to allocate any more IPs beyond our two current class C blocks. Hoping to migrate to IPv6 soon.
internal connections and perhaps things relayed by the external spam service. The point of being able to provide multiple MX records is that things keep working even if some of them aren't reachable.
I think for now we are going to leave it as status quo.
We have been tossing using a sql backend to generate our zone files, now I see that pdns supports oracle and mysql we might do up a whole new thing.
I am going to start a new thread on pdns
Thanks everyone for your patience and help.
-Jason
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
It's a bit of bad form to use NAT and private addresses at all because the internet really wasn't designed to be segmented, but everyone does it.
Why is NAT bad form?
From my standpoint as an admin, private IP's & NAT are another tool to
help secure my network. You can't attack what you can't see and even a misconfigured router or firewall won't expose my network to prying eyes.
Drew wrote:
It's a bit of bad form to use NAT and private addresses at all because the internet really wasn't designed to be segmented, but everyone does it.
Why is NAT bad form?
I don't mean to imply it shouldn't be used - it is pretty much a necessary evil now, but it doesn't fit the original IP design very well.
From my standpoint as an admin, private IP's & NAT are another tool to
help secure my network. You can't attack what you can't see and even a misconfigured router or firewall won't expose my network to prying eyes.
There are small problems like often needing split DNS, not being able to offer public services easily, not being able to track the source addresses meaningfully in logs, etc., but the real killer comes when your large organization merges with another using the same private address range and you need to connect the networks.
On Monday 03 August 2009 00:36, Les Mikesell wrote:
Drew wrote:
It's a bit of bad form to use NAT and private addresses at all because the internet really wasn't designed to be segmented, but everyone does it.
Why is NAT bad form?
I don't mean to imply it shouldn't be used - it is pretty much a necessary evil now, but it doesn't fit the original IP design very well.
From my standpoint as an admin, private IP's & NAT are another tool to
help secure my network. You can't attack what you can't see and even a misconfigured router or firewall won't expose my network to prying eyes.
There are small problems like often needing split DNS, not being able to offer public services easily, not being able to track the source addresses meaningfully in logs, etc., but the real killer comes when your large
Say what? How do you figure this? Unless you are not NAT'ing correctly. When NAT'ing only the destination address is changes and on the outbound only the source address is changed. So if you are logging you should still see the ip addresses.
organization merges with another using the same private address range and you need to connect the networks.
This can be worked around and has on many occasions at the office. The bigger problem is when you are just partnering with another company using the same range.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Christoph Maser Sent: Sunday, August 02, 2009 16:02 To: CentOS mailing list Subject: Re: [CentOS] Split dns issues
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"
Good to know, I have just read up on it. It looks like I will still have to create a separate zone file, which means I am back to square one.
Chris
financial.com AG
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
Hi,
On Sun, Aug 2, 2009 at 15:16, Jason Pyeronjpyeron@pdinc.us wrote:
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.
Why don't you just set the MX records of pdinc.us to something inside mail.pdinc.us? Then both your outside and inside will see the same name, but you can resolve them to different IPs inside mail.pdinc.us depending on being on the inside or outside network. If you want something other than MX records, you can use CNAMEs to something in a subdomain for which you will use "views", and then on the subdomain resolve to different IPs depending on the query being internal or external... Would that work for you?
HTH, Filipe
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Filipe Brandenburger Sent: Monday, August 03, 2009 10:10 To: CentOS mailing list Subject: Re: [CentOS] Split dns issues
Hi,
On Sun, Aug 2, 2009 at 15:16, Jason Pyeronjpyeron@pdinc.us wrote:
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.
Why don't you just set the MX records of pdinc.us to something inside mail.pdinc.us? Then both your outside and inside will see the same name, but you can resolve them to different IPs inside mail.pdinc.us depending on being on the inside or outside network. If you want something other than MX records, you can use CNAMEs to something in a subdomain for which you will use "views", and then on the subdomain resolve to different IPs depending on the query being internal or external... Would that work for you?
My worry is the A record for the outsourced mail service is out of our control, if it were to change it would be catastrophic.
I like the idea about the cname. Can a cname be used as a host for a MX record? The other fear is the outsourced (showing ignorance on SMTP here) might react badly to the client making a connection to a server with a name different than they expected, as it looks like they are doing a name based virtual hosting.
I will look in to it.
Thanks,
-Jason
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
Hi,
On Mon, Aug 3, 2009 at 10:27, Jason Pyeronjpyeron@pdinc.us wrote:
My worry is the A record for the outsourced mail service is out of our control, if it were to change it would be catastrophic.
Well, if you *must* use a name like mx.google.com for your MX, you could also set up an mx.google.com domain as authoritative in your domain, and then add an "A" record with your internal mail server there... It's not beautiful, but it should work.
Another alternative is to use "includes" in BIND, that way you could have "views" for your pdinc.us zone, then on both of them you would only have the MX record (which would be different on each of them) and maybe the SOA record (but you could also decide to keep that on the included file) and then an include to a file that contains the bulk of the records for the zone. Would that solve your problem managing views for that zone?
I like the idea about the cname. Can a cname be used as a host for a MX record?
Not according to the RFCs, but in practice it does work. Beware that you might stop receiving e-mails from very old and very buggy e-mail servers though (like maybe Exchange 5 or very old Lotus Notes, but I don't think anyone still uses those.)
The other fear is the outsourced (showing ignorance on SMTP here) might react badly to the client making a connection to a server with a name different than they expected, as it looks like they are doing a name based virtual hosting.
I don't think so, since SMTP only uses the name of the MX server for the TCP connection to the server's IP, nothing in the protocol later will use that name again. Virtual hosting is usually done by having the server accept e-mails to any of those e-mail domains on the same server.
HTH, Filipe
Filipe Brandenburger wrote:
On Mon, Aug 3, 2009 at 10:27, Jason Pyeronjpyeron@pdinc.us wrote:
My worry is the A record for the outsourced mail service is out of our control, if it were to change it would be catastrophic.
Well, if you *must* use a name like mx.google.com for your MX, you could also set up an mx.google.com domain as authoritative in your domain, and then add an "A" record with your internal mail server there... It's not beautiful, but it should work.
One other possibility is that some network equipment (e.g. Cisco PIX) has the ability to apply some NAT rules to DNS responses as they go by. You'd have to track the actual IP's to alias them, but since the worst-case behavior of not translating would be to get a spam-scan it might not be too bad. I don't think this will differentiate between mx and other dns responses though, so it could cause trouble if the target IPs are the same as ones used for some other type of access.
Personally, I don't like to rely on features that are vendor-specific like that but it might be a quick fix for this problem. The real solution would be to configure your sending sendmails to use a MAIL_HUB setting - at least any that send enough local mail to matter and always have direct access to the internal server.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Monday, August 03, 2009 11:49 To: CentOS mailing list Subject: Re: [CentOS] Split dns issues
Filipe Brandenburger wrote:
On Mon, Aug 3, 2009 at 10:27, Jason Pyeronjpyeron@pdinc.us wrote:
My worry is the A record for the outsourced mail service is out of our control, if it were to change it would be catastrophic.
Well, if you *must* use a name like mx.google.com for your MX, you could also set up an mx.google.com domain as authoritative in your domain, and then add an "A" record with your internal mail server there... It's not beautiful, but it should work.
One other possibility is that some network equipment (e.g. Cisco PIX) has the ability to apply some NAT rules to DNS responses as they go by. You'd have to track the actual IP's to alias them, but since the worst-case behavior of not translating would be to get a spam-scan it might not be too bad. I don't think this will differentiate between mx and other dns responses though, so it could cause trouble if the target IPs are the same as ones used for some other type of access.
I think adding more layers to the cake would be a bad idea for us. And way to vendor specific.
Personally, I don't like to rely on features that are vendor-specific like that but it might be a quick fix for this problem. The real solution would be to configure your sending sendmails to use a MAIL_HUB setting - at least any
Not all of the systems can be configured as such (policy and/or technology).
that send enough local mail to matter and always have direct access to the internal server.
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
Jason Pyeron wrote:
Personally, I don't like to rely on features that are vendor-specific like that but it might be a quick fix for this problem. The real solution would be to configure your sending sendmails to use a MAIL_HUB setting - at least any
Not all of the systems can be configured as such (policy and/or technology).
I'd expect the most common case to be mail user agents that have to be specifically configured for the forwarding smtp server anyway. What else do you have sending a lot of internal mail? Or are these laptops that may or may not have direct access to the internal server?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Monday, August 03, 2009 12:28 To: CentOS mailing list Subject: Re: [CentOS] Split dns issues
Jason Pyeron wrote:
Personally, I don't like to rely on features that are
vendor-specific
like that but it might be a quick fix for this problem. The real solution would be to configure your sending sendmails to use a MAIL_HUB setting - at least any
Not all of the systems can be configured as such (policy
and/or technology).
I'd expect the most common case to be mail user agents that have to be specifically configured for the forwarding smtp server anyway.
In fact most are default configurations. An engineer will up an (vm) image, give it some tasks to do (temp website, software builds, experimental config, etc...) and the data/logs are emailed to him when done.
What else do you have sending a lot of internal mail?
Think about things like logwatch, cron, at, etc..., but not always on linux. This will get forwarded to support or a specific engineer.
Or are these laptops that may or may not have direct access to the internal server?
That is one of our use cases, exactly, and that is where this mail will come from.
-Jason
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
Jason Pyeron wrote:
I'd expect the most common case to be mail user agents that have to be specifically configured for the forwarding smtp server anyway.
In fact most are default configurations. An engineer will up an (vm) image, give it some tasks to do (temp website, software builds, experimental config, etc...) and the data/logs are emailed to him when done.
You might be able to handle these scenarios by providing a different internal-only DNS domain that you configure your mail server to accept in addition to the current domain. Then anyone who wants to skip the spam scan can use a target mail address with the internal name.
What else do you have sending a lot of internal mail?
Think about things like logwatch, cron, at, etc..., but not always on linux. This will get forwarded to support or a specific engineer.
Or are these laptops that may or may not have direct access to the internal server?
That is one of our use cases, exactly, and that is where this mail will come from.
This one is harder - maybe even impossible to get completely right if you count the case where you set up temporary VPN access to reach the internal target from a LAN where you also need to maintain similar private DNS mapping, for example to access a local printer.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Filipe Brandenburger Sent: Monday, August 03, 2009 10:40 To: CentOS mailing list Subject: Re: [CentOS] Split dns issues
Hi,
On Mon, Aug 3, 2009 at 10:27, Jason Pyeronjpyeron@pdinc.us wrote:
My worry is the A record for the outsourced mail service is
out of our
control, if it were to change it would be catastrophic.
Well, if you *must* use a name like mx.google.com for your MX, you could also set up an mx.google.com domain as authoritative in your domain, and then add an "A" record with your internal mail server there... It's not beautiful, but it should work.
I think this is a perfect solution as weighed against every thing else.
Another alternative is to use "includes" in BIND, that way you could have "views" for your pdinc.us zone, then on both of them you would only have the MX record (which would be different on each of them) and maybe the SOA record (but you could also decide to keep that on the included file) and then an include to a file that contains the bulk of the records for the zone. Would that solve your problem managing views for that zone?
Too messy, as there are many changing records, and some are already klobbered as described above and in previous emails.
I like the idea about the cname. Can a cname be used as a
host for a MX record?
Not according to the RFCs, but in practice it does work. Beware that you might stop receiving e-mails from very old and very buggy e-mail servers though (like maybe Exchange 5 or very old Lotus Notes, but I don't think anyone still uses those.)
Doh. We use Exchange 5.5 SP4. (don't ask)
The other fear is the outsourced (showing ignorance on SMTP here) might react badly to the client making a connection to a
server with a
name different than they expected, as it looks like they
are doing a name based virtual hosting.
I don't think so, since SMTP only uses the name of the MX server for the TCP connection to the server's IP, nothing in the protocol later will use that name again. Virtual hosting is usually done by having the server accept e-mails to any of those e-mail domains on the same server.
I guess they are doing the weird naming thing so they can shuffle servers around.
HTH, Filipe _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
Jason Pyeron wrote:
I like the idea about the cname. Can a cname be used as a host for a MX record?
CNAME's can only be used for things that only have an A record. for example, you can't use a CNAME for a domain, which needs a SOA, A, NS, MX record.
in general, CNAME's should be avoided except when absolutely neccessary.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of John R Pierce Sent: Monday, August 03, 2009 12:34 To: CentOS mailing list Subject: Re: [CentOS] Split dns issues
Jason Pyeron wrote:
I like the idea about the cname. Can a cname be used as a
host for a MX record?
CNAME's can only be used for things that only have an A record. for example, you can't use a CNAME for a domain, which needs a SOA, A, NS, MX record.
Not sure if you are ACKing or NAKing?
Pdinc.us mx 1 smtprelay.pdinc.us Smtprelay.pdinc.us cname spamscan.google.com
Spamscan.google.com does have an A record, and ought not to have a MX, etc.
in general, CNAME's should be avoided except when absolutely neccessary.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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.
Jason Pyeron wrote:
CNAME's can only be used for things that only have an A record. for example, you can't use a CNAME for a domain, which needs a SOA, A, NS, MX record.
Not sure if you are ACKing or NAKing?
Pdinc.us mx 1 smtprelay.pdinc.us Smtprelay.pdinc.us cname spamscan.google.com
Spamscan.google.com does have an A record, and ought not to have a MX, etc.
yes, thats valid. this, however is most assuredly not.
pdinc.us CNAME spamscan.google.com
-
Bill Campbell -
Christoph Maser -
Drew -
Filipe Brandenburger -
Jason Pyeron -
John R Pierce -
Les Mikesell -
Robert Spangler