dots in hostnames problem
Kevin Darcy
kcd at chrysler.com
Wed Mar 9 19:20:14 UTC 2011
On 3/9/2011 1:09 PM, Matt Rae wrote:
> Hi, I'm working on setting up a slave dns server. Dots have
> historically been used in the hostnames here.
What does the term "hostname" mean to you?
If "hostname" is defined as "the contents of the first label of a
dot-delimited DNS name", then "dot in hostname" does not and cannot exist.
Or, perhaps you have a different definition?
> The dots cause the
> resulting zone file from a zone transfer to have $ORIGIN automatically
> set assuming the dots are indicating a subdomain.
>
> Here's an example of what's happening:
>
> master zone file:
>
> $ORIGIN example.com.
> host1.set1 A x.x.x.x
> host2.set1 A x.x.x.x
> host3.set1 A x.x.x.x
>
> slave's zone file after axfr:
>
> $ORIGIN set1.example.com.
> host1 A x.x.x.x
> host2 A x.x.x.x
> host3 A x.x.x.x
>
> Is there a way to have it not change the ORIGIN and assume the dots
> are a subdomain?
Well, technically, that is not just an "assumption". set1.example.com
is, in reality, a subdomain of example.com.
$ORIGIN statements are just a convenience for named's zone-parsing
routine. If you intend to parse zone contents yourself, you should look
at the actual data rather than literally the zone file, which is only
one way among many to express that data. Dealing with the actual data
can be accomplished either through the DNS protocol itself (e.g. zone
transfer), or via a script that parses the $ORIGIN statements, etc. and
renders the data into a more digestible form.
- Kevin
More information about the bind-users
mailing list