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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
