Questions regarding global MX and NS records

[Kevin Darcy]

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