default $ttl/zone file errors

[Fabiola Caceres]

I have modified my zone  files (they all look the same at the top)
and I'm getting the same errors on all.
--------------

@  86400 IN SOA ns1.infi.net. hostmaster.infi.net.
(
        2001053000      ; Serial
        10800           ; Refresh after 3 hours
        3600            ; Retry after 1 hour
        604800          ; Expire after 1 week
        86400           ; Minimum TTL of 1 day
)
        IN      NS      ns1.infi.net.
        IN      NS      ns2.infi.net.
        IN      NS      ns3.infi.net.
        IN      NS      ns4.infi.net.
;       IN      MX      50 region101.infi.net.
;       IN      MX      100 mailhost2.infi.net.
        IN      A       216.33.107.214
www     IN      CNAME   vh50003.vh5.infi.net.
web     IN      CNAME   vh50003.vh5.infi.net.
----------
However, I still get errors:

May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.warning] Customers/robbie-kiki.com.zone
: WARNING SOA refresh value is less than 2 * retry (2 < 600 * 2)
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.notice] Customers/robbie-kiki.com.zone:
49: Database error near ()
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.notice] Customers/robbie-kiki.com.zone:
50: Database error near ()
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.notice] Customers/robbie-kiki.com.zone:
51: Database error near ()
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.notice] Customers/robbie-kiki.com.zone:
52: Database error near ()
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.notice] Customers/robbie-kiki.com.zone:
53: Database error near ()
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.warning] Zone "robbie-kiki.com" (file C
ustomers/robbie-kiki.com.zone): No default TTL ($TTL <value>) set, using
SOA minimum instead
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.warning] owner name ").robbie-kiki.com"
 IN (primary) is invalid - rejecting
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.notice] Customers/robbie-kiki.com.zone:
60: owner name error
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.notice] Customers/robbie-kiki.com.zone:
60: Database error near (A)
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.warning] Zone "robbie-kiki.com" (file C
ustomers/robbie-kiki.com.zone): no NS RRs found at zone top
May 31 00:16:55 ufe201.disk.sterling.va.infi.net named[13837]: [ID 295310
daemon.warning] master zone "robbie-kiki.com"
(IN) rejected due to errors (serial 0)

----

I'm not sure what I'm doing wrong. Please advise, TIA
I just brought up this new system (it's real name is not ns1.infi.net, but
it will. ns1.infi.net is another live system right now)

Fabiola



On Wed, 30 May 2001, Joseph S D Yao wrote:

> On Thu, May 31, 2001 at 08:49:23AM +1000, Mark.Andrews at nominum.com wrote:
> > 	Actually both are legal (provided you fix the SOA records in
> > 	both examples to be legal).
> > 
> > 	The first is using RFC2308 sematics to set TTLs on records
> > 	without TTLs.  i.e. Inherited from previous $TTL.
> > 	
> > 	The second is using RFC103[45] sematics to set TTLs on records
> > 	without TTLs.  i.e. Inherited from previous record.
> > 
> > 	BIND 9 implements both starts in RFC103[45] mode and switches
> > 	to RFC2308 mode when it reads a $TTL directive.
> 
> Ack.  Missed that.  I'll remember it now.  ;-)  Thanks.
> 
> I ignored the fact that the '(' was not on the same line as the start
> of the SOA statement in the second example, and the fact that the SOA
> statement in the first example was incomplete, because that seemed
> outside the scope of the question.  But specifying that may save a
> return visit by the requestor.  ;-)
> 
> -- 
> Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
> OSIS Center Computer Support					EMT-B
> -----------------------------------------------------------------------
> This message is not an official statement of COSPO policies.
>