"@" entries and "" entries not transferring

[Kevin Darcy]

Helmut Schneider wrote:
> Hi,
>
> Barry Margolin (barmar at alum.mit.edu) wrote:
>   
>> In article <ea2urn$1jd4$1 at sf1.isc.org>,
>> "Helmut Schneider" <jumper99 at gmx.de> wrote:
>>
>>     
>>> primary master:
>>>
>>> $ORIGIN .
>>> $TTL 86400      ; 1 day
>>> mydomain.tld            IN SOA  whatever. admin.whatever. (
>>> 2006072506 ; serial
>>> 28800      ; refresh (8 hours)
>>> 7200       ; retry (2 hours)
>>> 604800     ; expire (1 week)
>>> 86400      ; minimum (1 day)
>>> )
>>> NS      whatever.
>>> NS      whatever.
>>> MX      0 whatever.
>>> MX      10 whatever.
>>>
>>> $ORIGIN mydomain.tld.
>>>
>>> test                    A       192.168.0.100
>>> @                        A       192.168.0.100
>>> www                     A       192.168.0.100
>>>                              A       192.168.0.100
>>>
>>> After transferring the zone to the secondary "@" and "" is lost:
>>>       
>> There is no record for "".  That line is a second A record for "www".
>> But since the IP address is the same as the previous line, it's a
>> duplicate and ignored when loading the zone on the master.
>>     
>
> OK, but I was told that this is what to do if I want to create a record for 
> my domain. And I do not have a special webserver for www *and* mydomain. :)
>   
This is one of the dangers of taking a piece of advice such as "to 
create an A record for the zone apex (i.e. the name which is the same as 
the zone itself), just specify the A record with an owner name of 
whitespace", without understanding the context or underlying theory.

The *rule* in master files is: if the owner name is given as whitespace, 
the owner name is taken by the parser to "inherit" the last 
non-whitespace owner name. (This implies, by the way, that it's illegal 
for the owner name of the first RR in a zone file to be whitespace, 
since in that case, there is nothing to inherit). The advice you 
followed would have been fine, as long as the owner name that was being 
inherited was the name of the zone (which can, as a convenience, also be 
given as "@"). But, you took the advice without understanding its 
context-sensitive nature, and put the white-space-owning RR right after 
an RR with an owner name of "www". So it inherited "www" as its owner 
name, which isn't what you intended. Furthermore, since the A record 
resolved to the same value as the "www" RR, it was effectively a 
duplicate, and thus suppressed by the parser completely.

Possible solutions? Put the white-space-owning RR under a "@"-owning RR, 
under an RR with the name of the zone spelled out, underneath a series 
of white-space-owning RRs which are in turn under one of the things 
already mentioned, or just give up on the white-space-owner construct 
for now, until you're more comfortable with master-file syntax, and just 
spell all of the owner names out explicitly. It makes your zone file 
verbose, and arguably less readable, but at least you stay out of 
trouble that way.

>>> $ORIGIN .
>>> $TTL 86400      ; 1 day
>>> mydomain.tld            IN SOA  whatever. admin.whatever. (
>>> 2006072506 ; serial
>>> 28800      ; refresh (8 hours)
>>> 7200       ; retry (2 hours)
>>> 604800     ; expire (1 week)
>>> 86400      ; minimum (1 day)
>>> )
>>> NS      whatever.
>>> NS      whatever.
>>> MX      0 whatever.
>>> MX      10 whatever.
>>>       
>> Are you sure the A record for @ isn't included in the above batch of
>> lines?  I presume @ = mydomain.tld, so BIND would have put that above.
>>     
>
> root at mx1:/root# nslookup mydomain.org
> Server:         192.168.0.80
> Address:        192.168.0.80#53
>
> Non-authoritative answer:
> *** Can't find mydomain.org: No answer
>
> root at mx1:/root# nslookup mydomain.org ns1
> Server:         ns1
> Address:        192.168.0.90#53
>
> Name:   mydomain.org
> Address: 192.168.0.100
>
> root at mx1:/root#
>
>   
>> I suspect you left it out when doing all the editing to hide your domain.
>>     
>
> Nope! What should I do now, report a bug?
>   
No, you should post the *unedited* versions of the files for comparison 
so we can see where you made your editing mistake.

                                                                         
                              - Kevin