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