Confused about what $ORIGIN does in relation to @
Chris Buxton
cbuxton at menandmice.com
Wed Sep 12 18:06:51 UTC 2007
The zone is declared in named.conf (or a file included into it) thusly:
zone "dss.state.la.us." IN {
type master;
file "...";
};
Your zone statement may be missing the trailing dot on the domain
name, may omit the class (IN), and will have a real filename in place
of "...". However, the point is, this associates a domain name (the
zone's origin, or apex node) with a zone file - the default origin,
in the absence of an $ORIGIN statement, is "dss.state.la.us.".
To understand how the $ORIGIN statements you have work, you have to
follow the file in order, line by line. The first line changes the
origin to "."; this applies to the following 6 records (which
describe the zone's apex node). The line after that resets the origin
back to the default, the zone name, and this applies to the rest of
the zone (or until another $ORIGIN directive is encountered).
If you want to remove them entirely, as Mark suggested, you simply
have to express your apex node (the first 6 records) with that origin
in mind instead of ".". That means changing the owner name of the SOA
record from "dss.state.la.us" to either "@" or "dss.state.la.us.".
(Note the trailing dot on the latter version - this means, don't
apply the origin to this name.) The other 5 records of the apex node
inherit their name from the SOA record.
Optionally, you can also express the owner names of the other 5 apex
records, as Mark suggested, instead of relying on owner name
inheritance.
Chris Buxton
Men & Mice
On Sep 12, 2007, at 10:10 AM, Ryan McCain wrote:
> Mark,
>
> Could you clarify this statement?
>
> " If I was manually editing this file I would remove all the
> $ORIGIN clause and just use the implicit one from the zone
> definition. "
>
> I don't yet know what you mean by "one from the zone definition".
>
> Thanks
>
>
>
> --------------------------------------
>
> Ryan McCain
> Northrop Grumman Corporation
> Linux System Administrator 3
> email: Ryan.McCain at dss.state.la.us
> Phone: 225.505.3832
> Fax: 225.219.0540
>
> Registered Linux User #364609
>
>
>>>> Mark Andrews <Mark_Andrews at isc.org> 09/11/07 6:18 PM >>>
>
>> Gotcha.
>>
>> Why would my zone file have 2 $ORIGIN directives? And how does
>> the @ in the SOA re
>> cord relate to the $ORIGIN directive?
>>
>> Thanks..
>
> Your zone file has 2 $ORIGIN directives as you are seeing internal
> structure of the database that held the zone in memory. The master
> file for a slave zone it not produced for human consumption. It is
> produced so that named can server the zone when it starts regardless
> of whether the master server is reachable or not.
>
> @ says put the current $ORIGIN here.
>
> If I was manually editing this file I would remove all the $ORIGIN
> clause and just use the implicit one from the zone definition.
> I also like to fully qualify my rdata. All owner names would be
> relative to the implicit $ORIGIN.
>
> Mark
>
> $TTL 3600 ; 1 hour
> @ IN SOA dssns.dss.state.la.us.
> rmccain.dss.state.la.us. (
> 2007091103 ; serial
> 1200 ; refresh (20 minutes)
> 600 ; retry (10 minutes)
> 1209600 ; expire (2 weeks)
> 3600 ; minimum (1 hour)
> )
> @ NS dssns.dss.state.la.us.
> @ NS dssns2.dss.state.la.us.
> @ A 205.172.49.49
> @ MX 10 smtp-ext1.dss.state.la.us.
> @ MX 20 smtp-ext2.dss.state.la.us.
> acess A 205.172.49.23
> acess-info A 205.172.49.23
> acspoc A 205.172.49.9
>
>>>>> On Tue, Sep 11, 2007 at 1:38 PM, in message
>> <4F19260FE7477F4DA03B00B62E7F63903DA55189A9 at CHERRYPEPSI.uwec.edu>,
>> "Paine,
>> Thomas Asa" <PAINETA at uwec.edu> wrote:
>>> Ryan,
>>>
>>> The $ORIGIN directive will get appended to any owner or
>>> record data
>>> (like cnames) which are not already fully qualified.
>>>
>>> So in the case of say "acess", it does not have a trailing . so
>>> it would
>>> become acess.$ORIGIN or acess.dss.state.la.us.
>>>
>>> By commenting it out, you in essence turned acess into a toplevel
>>> acess.
>>> Since the only previous $ORIGIN statement was .
>>>
>>> In slave databases you'll see an $ORIGIN directive anytime there
>>> is a change
>>> the domain portion of the owners.
>>>
>>> i.e.
>>>
>>> $ORIGIN foobar.com.
>>> www ......
>>> $ORIGIN hr.foobar.com.
>>> www ......
>>>
>>>
>>> That help?
>>>
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Thomas Paine {paineta at uwec.edu)}
>>> University of Wisconsin - Eau Claire
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>> -----Original Message-----
>>> From: bind-users-bounce at isc.org [mailto:bind-users-
>>> bounce at isc.org] On Behalf Of
>>> Ryan McCain
>>> Sent: Tuesday, September 11, 2007 1:00 PM
>>> To: bind-users at isc.org
>>> Subject: Confused about what $ORIGIN does in relation to @
>>>
>>> This is another post in my attempt to gain knowledge of BIND.
>>> Here is the
>>> top of one of my zone files:
>>>
>>> $ORIGIN .
>>> $TTL 3600 ; 1 hour
>>> dss.state.la.us IN SOA dssns.dss.state.la.us.
>>> rmccain.dss.state.la.us (
>>> 2007091103 ; serial
>>> 1200 ; refresh (20 minutes)
>>> 600 ; retry (10 minutes)
>>> 1209600 ; expire (2 weeks)
>>> 3600 ; minimum (1 hour)
>>> )
>>> NS dssns.dss.state.la.us.
>>> NS dssns2.dss.state.la.us.
>>> A 205.172.49.49
>>> MX 10 smtp-ext1.dss.state.la.us.
>>> MX 20 smtp-ext2.dss.state.la.us.
>>> $ORIGIN dss.state.la.us.
>>> acess A 205.172.49.23
>>> acess-info A 205.172.49.23
>>> acspoc A 205.172.49.9
>>>
>>>
>>> I have the O'Reilly BIND book but it doesn't really clarify what
>>> the $ORIGIN
>>> statement is doing. This zone file was created when the server
>>> was acting as
>>> a slave to a master Microsoft DNS server.
>>>
>>> What confuses me is I have 2 $ORIGIN statements. I am assuming
>>> this is
>>> repetitive however, I'm not 100% sure.
>>>
>>> I changed the zone file to comment out the 2nd $ORIGIN statement:
>>>
>>>
>>> $ORIGIN .
>>> $TTL 3600 ; 1 hour
>>> dss.state.la.us IN SOA dssns.dss.state.la.us.
>>> rmccain.dss.state.la.us (
>>> 2007091103 ; serial
>>> 1200 ; refresh (20 minutes)
>>> 600 ; retry (10 minutes)
>>> 1209600 ; expire (2 weeks)
>>> 3600 ; minimum (1 hour)
>>> )
>>> NS dssns.dss.state.la.us.
>>> NS dssns2.dss.state.la.us.
>>> A 205.172.49.49
>>> MX 10 smtp-ext1.dss.state.la.us.
>>> MX 20 smtp-ext2.dss.state.la.us.
>>> ;$ORIGIN dss.state.la.us.
>>> acess A 205.172.49.23
>>> acess-info A 205.172.49.23
>>> acspoc A 205.172.49.9
>>>
>>>
>>> and also tried it by changing the first $ORIGIN statement:
>>>
>>> $ORIGIN dss.state.la.us.
>>> $TTL 3600 ; 1 hour
>>> dss.state.la.us IN SOA dssns.dss.state.la.us.
>>> rmccain.dss.state.la.us (
>>> 2007091103 ; serial
>>> 1200 ; refresh (20 minutes)
>>> 600 ; retry (10 minutes)
>>> 1209600 ; expire (2 weeks)
>>> 3600 ; minimum (1 hour)
>>> )
>>> NS dssns.dss.state.la.us.
>>> NS dssns2.dss.state.la.us.
>>> A 205.172.49.49
>>> MX 10 smtp-ext1.dss.state.la.us.
>>> MX 20 smtp-ext2.dss.state.la.us.
>>> ;$ORIGIN dss.state.la.us.
>>> acess A 205.172.49.23
>>> acess-info A 205.172.49.23
>>> acspoc A 205.172.49.9
>>>
>>>
>>> ..Both produced weird errors when I queried the domain via
>>> dnsstuff.com.
>>>
>>> Can someone clarify where my $ORIGIN statement should be and also
>>> can I
>>> change dss.state.la.us in the SOA record to just @?
>>>
>>> Thanks again for everyones help..
>>
>>
> --
> 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