Questions regarding global MX and NS records
Kevin Darcy
kcd at chrysler.com
Wed Jul 21 18:45:28 UTC 2010
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:
>>
>> $ORIGIN .
>> ...
>> 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?:
>>
>> $ORIGIN blah.example.com.
>> 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 and
>> have 1,000+ records that I delegate to the devices as follows:
>>
>> $ORIGIN blah.example.com.
>> www NS gss1.example.com.
>> NS gss2.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
>> file?
> No, forwarding doesn't work here. The queries you're getting for this
> are predominantly *non-recursive*, and non-recursive queries are never
> forwarded.
>
> 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.
>
> etc.
>
> 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?)
- Kevin
More information about the bind-users
mailing list