Internal roots and wildcards
Hajducko, Steven
steven.hajducko at digitalinsight.com
Fri Jan 4 17:33:27 UTC 2008
Thanks Mark,
If I do need the delegation in the root, that brings up another question
-
Should I delegate example.com or should I delegate
tier.environment.example.com? The only reason I ask is because the
nameserver itself doesn't actually load an example.com zone, it only
loads the tier.environment.example.com zone and it cannot talk to the
nameserver who actually does load example.com because of firewall
issues.
That or should we create an empty example.com and just contain a
delegation for the tier.env back to the nameserver?
So basically, I'd end up with zones like this:
zone example.com:
$TTL 3600
@ IN SOA ns1.tier.env.example.com.
datacenter.example.com. (
9 ; Serial
3h ; Refresh
1h ; Retry
1w ; Expire
1h) ; Minimum
IN NS
ns1.tier.env.example.com
tier.env.example.com IN NS
ns1.tier.env.example.com
ns1.tier.env.example.com IN A 1.2.3.4
zone tier.env.example.com:
$TTL 3600
@ IN SOA ns1.tier.env.example.com.
datacenter.example.com. (
9 ; Serial
3h ; Refresh
1h ; Retry
1w ; Expire
1h) ; Minimum
IN NS ns1.tier.env.example.com
; tier hosts go here
ns1.tier.env.example.com IN A 1.2.3.4
host1 IN A 1.2.3.5
host2 IN A 1.2.3.6
And then delegate the example.com in the root? Or can I just skip the
example.com zone and simply delegate tier.env.example.com in the root?
Thanks again.
> -----Original Message-----
> From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]
> Sent: Thursday, January 03, 2008 5:23 PM
> To: Hajducko, Steven
> Cc: bind-users at isc.org
> Subject: Re: Internal roots and wildcards
>
>
> > 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
>
More information about the bind-users
mailing list