Internal roots and wildcards

[Mark Andrews]

> 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.

	You do have bastion hosts.  They are called
	relay.tier.env.example.com.

	relay.tier.env.example.com has to see the real roots so
	that it can relay mail.  It will also needs to see the
	internal zones so it can relay mail the other way.

> 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?

	If you ever make the internal network more complicated you
	will need it.  It's better to do thing right at the begining
	than trying to work out why things are failing in a couple
	of years time.

> 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?

	You have a empty COM node.  If a node *exists*, regardless of whether
	there are records there or not, then that blocks the wildcard from
	matching.

>  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.

	Because that is how wildcard matching is defined to work.
 
> Oh, thought I wouldn't think this would matter too much, this is all
> running on BIND 9.4.1
> 
> Thanks.
> 
> --
> sh
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org