Questions regarding global MX and NS records

[Kevin Darcy]

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.

                                                                         
                                                                         
                                                 - Kevin