Re: Questions regarding global MX and NS records
- From: Kevin Darcy <kcd@xxxxxxxxxxxx>
- Date: Wed, 21 Jul 2010 14:45:28 -0400
On 7/21/2010 2:01 PM, Kevin Darcy wrote:
On 7/21/2010 1:15 PM, Atkins, Brian (GD/VA-NSOC) wrote:After specifying MX records for a 2nd tier domain, is it necessary to
restate the MX records for a new $ORIGIN? For example, if I have:
IN MX 10 mx1.example.com.
IN MX 10 mx2.example.com.
IN MX 10 mx3.example.com.
IN MX 10 mx4.example.com.
Do I also need to do the following?:
MX 10 mx1.example.com.
MX 10 mx2.example.com.
MX 10 mx3.example.com.
MX 10 mx4.example.com.
Or is the first statement sufficient to cover all sub-domains as long as
the MX records are the same?
No, those MX records are owned by different names (example.com and blah.example.com).
It is possible to create wildcard MX records (*.example.com) but there are serious caveats to doing that, since some MTAs don't handle wildcard MX matching very well.
Also, if you have a wildcard in a zone, then you'll never get an NXDOMAIN for a query of any name in that part of the namespace hierarchy, because the names in such queries will be "matched" by the wildcard, even if the lookup is some type other than MX. This might have implications in terms of support/troubleshooting procedures, caching efficiency, etc.
Personally I'm a fan of using wildcards where they make sense, but you have to be *very* careful with them. Go in with your eyes open.
Also, I have a number of records that I redirect to a GSLB device andNo, forwarding doesn't work here. The queries you're getting for this are predominantly *non-recursive*, and non-recursive queries are never forwarded.
have 1,000+ records that I delegate to the devices as follows:
www NS gss1.example.com.
Is there a more efficient method of doing this, eliminating the need to
do this for every sub-domain? Perhaps a forward statement in the conf
We choose to use aliases for this, e.g.
lb.example.com. ns gss1.lb.example.com.
lb.example.com. ns gss2.lb.example.com.
www1.example.com cname www1.lb.example.com.
www2.example.com. cname www2.lb.example.com.
www3.example.com. cname www3.lb.example.com.
This means we only need 1 record (the CNAME) for each website, rather than a delegation per website.
Also, aliasing things this way allows the GSS to respond sanely with SOA/NS records for the delegated zone (lb.example.com), when the GSS is configured properly to proxy non-A queries to the servers of a "shadow" version of the zone. If you delegate each name individually to the GSS, you don't get proper SOA/NS record responses (unless you were to configure "shadow" versions for *all* 1,000+ of those zones, but that's way too much work). Why do you care whether the GSS has access to SOA records for any given zone? Because SOAs are required for proper negative caching. See RFC 2308.
(Whoops, I forgot a trailing period in one of the example lines above).
Another benefit of aliasing out each name, instead of delegating each one individually, is that you avoid a lot of "sub-delegation" ugliness if you have multiple sets of load-balancers, and you want to *nest* names, using diverse sets of load-balancers, within their own application-defined hierarchies, e.g.
; 2 distinct sets of load-balancers, production and pre-production
production-loadbalancers.example.com. ns gss1.example.com.
production-loadbalancers.example.com. ns gss2.example.com.
preprod-loadbalancers.example.com. ns gss3.example.com.
preprod-loadbalancers.example.com. ns gss4.example.com.
; Production website for customer support, using production load-balancers
support.example.com. cname support-website.production-loadbalancers.example.com.
; Pre-production website for customer support, using preprod load-balancers
preprod.support.example.com. cname support-website.preprod-loadbalancers.example.com.
(Sure, if you can convince your app people to *not* use a DNS-label-based hierarchy, e.g. by embedding *within* a label, e.g. preprod-support.example.com, then that's another way to avoid the ugliness, but oftentimes there are application dependences on DNS names, e.g. SSL certificates, and in any case why impose an unnecessary naming limitation?)
- Prev by Date: Re: Questions regarding global MX and NS records
- Next by Date: IPv6 Records on an IPv4 Network
- Previous by thread: Re: Questions regarding global MX and NS records
- Next by thread: IPv6 Records on an IPv4 Network