Internal roots and wildcards
Kevin Darcy
kcd at chrysler.com
Sat Jan 5 05:27:57 UTC 2008
If the example.com zone is unresolvable to you, then for all your
intents and purposes it doesn't exist and you should skip over it,
delegating directly to the highest point in the hierarchy that you _do_
control, whether that be environment.example.com,
tier.environment.example.com or something lower.
Unless I'm misunderstanding your environment.
For that matter, if you really wanted to you could put everything you
control into a single root zone, and not delegate anything. One has a
lot of control when one controls one's own internal root. Among others,
a big downside of doing that, however, is that you cannot then provide a
granular way for your business partners to "override" parts of their
namespace, e.g. you can't just have them stub or slave
tier.environment.example.com if it's not a separate zone.
- Kevin
Hajducko, Steven wrote:
> 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