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