Internal roots and wildcards

Hajducko, Steven steven.hajducko at digitalinsight.com
Fri Jan 4 00:37:13 UTC 2008


In our infrastructure, we have many segregated networks that have no
connection to the internet, at all.  They're all named in a manner of
hostname.tier.environment.example.com.  Our email addresses, however,
are all digitalinsight.com.  These networks allow mail to come out in
order for people to send debugging emails to themselves and in some
cases, external internet accounts.

Instead of having to configure every host in the network with a smart DS
host and disabling DNS lookups and all that jazz, we followed the recipe
of creating our own internal root servers with a wildcard MX record that
points at a local relay within each tier.

So we have the following:

*  IN MX relay.tier.environment.example.com.
relay.tier.environment.example.com. IN A 1.2.3.4

Now, in the DNS & Bind book, it talks about not having the internal
roots on the bastion hosts, but in our situation, we have no bastion
hosts and we are running the internal root servers on the two DNS
servers that serve that entire tier.

So in the end, our named.root file ends up looking like:

$TTL 1d
.       IN SOA  ns1.tier.env.example.com. datacenter.digitalinsight.com.
(
                5       ; Serial
                3h      ; Refresh
                1h      ; Retry
                1w      ; Expire
                1h )    ; Minimum

                                        IN NS
ns1.tier.env.example.com.
                                        IN NS
ns2.tier.env.example.com.
*                                       IN MX   10
relay.tier.env.example.com.
relay.tier.env.example.com.             IN A    1.2.3.6
ns1.tier.env.example.com.               IN A    1.2.3.4
ns2.tier.env.example.com.               IN A    1.2.3.5

My question is this -

Do I need to put actual delegation records in the named.root file for
example.com or tier.env.example.com, considering that all systems in the
tier only ever lookup hostname.tier.env.example.com?  The only time I
could possibly see the root zone being queried is when an email is sent
to an external source, ( gmail.com, for example ), which in that case,
the MX record wildcard would take care of the situation.

In reality, we have this working already ( with and without the
delegation ), but I'd like to follow the more proper route.  This also
leads to my second question - The book also describes why you need to
add a "*.edu IN MX"( *.com in our case ) in addition to the "* IN MX",
but they say they need this because there is specific information for an
edu domain already.  In our situation, we don't actually have this, so
why do we need it?  I know we DO need it, but I'm having a hard time
understanding the wildcard expansion rules.  I just know that if I don't
include a "*.com IN MX" record, then any lookup for MX records in any
.com domain fail with an NXDOMAIN, but I just don't understand why.

Oh, thought I wouldn't think this would matter too much, this is all
running on BIND 9.4.1

Thanks.

--
sh





More information about the bind-users mailing list