RE: about resolving on a child zone

2009-04-14 Thread Jeff Pang
> Original Message > Subject: Re: about resolving on a child zone > From: Chris Buxton > Date: Mon, April 13, 2009 10:31 am > To: Tech W. > Cc: bind-users@lists.isc.org > > In this case, the answer is that your main zone (example.com) will > have an error, because it will

Problem with Dynamic DNS Updates using TSIG

2009-04-14 Thread Erisan Nyamutenha
Hi all, Can any one help me out, I'm having a problem setting up Dynamic DNS updates using TSIG. I'm running ISC Bind 9 on SLES 10 and ISC DHCP 3.0.3 on SLES 10. I need to get my DHCP to update my DNS. Here is my DNS and DHCP config plus the error i'm getting from nsupdate. hostnames and IPs hav

Re: about resolving on a child zone

2009-04-14 Thread Tech W.
Thanks for chris, barry and all. --- On Tue, 14/4/09, Barry Margolin wrote: > > There's a special exception made for "glue" records, since > they're > needed to prevent an infinite recursion.  The parent > zone will include > this A record. Enjoy a safer web experience. Upgrade to

Re: about resolving on a child zone

2009-04-14 Thread Chris Buxton
On Apr 14, 2009, at 3:00 AM, Jeff Pang wrote: In this case, the answer is that your main zone (example.com) will have an error, because it will have an A record below the "bottom" of the zone that is not a glue record. In other words, it will recognize that www.my.example.com belongs to my.exampl

bind9: unknown RR type, unknown class/type errors

2009-04-14 Thread Frank Moeller
Hello All, I have a little problem while setting up my DNS. In my LAN I want to use the local domain go.wiki. So I make the following settings to the bind9 on my ubuntu server (hardy): named.conf: === include "/etc/bind/named.conf.options"; zone "." { type hint; file "/etc/

Re: bind9: unknown RR type, unknown class/type errors

2009-04-14 Thread Chris Buxton
On Apr 14, 2009, at 7:01 AM, Frank Moeller wrote: /etc/bind/db.go.wiki: $ORIGIN go.wiki. $TTL 1D @ IN SOA localhost. hostmaster. ( 200405191 ; serial 8H; refresh 4H; retry

RE: negative caching time and TTLs

2009-04-14 Thread Lena M
Hello, Which TTL value is supposed to be used for negative caching time? -We are running BIND 9.X as a caching server. We are seeing that NXDOMAIN replies are being cached using $TTL time of a given zone instead of its SOA min TTL time. -Is $TTL suppose to override SOA's min TTL for t

Limit allow-transfer to key + IP

2009-04-14 Thread Jonathan Petersson
Hi all, I was reading up on TSIG signed zone-transfers and gave it a try in my lab this morning, successfully. However what I noticed (which makes sense based on my config) is that any host with the appropriate key is allowed to perform a zone-transfer. Is there any way to limit the zone-transfer

Position of SOA in master file (was: Re: about resolving on a child zone)

2009-04-14 Thread Chris Thompson
On Apr 14 2009, Chris Buxton wrote: No, I didn't mean positionally within the zone file. Record order is mostly irrelevant in zone files (but the SOA record must be first). No, it need not be first. It's *conventional* to put it first. It's only *necessary* if you (a) have no $TTL directive

RE: negative caching time and TTLs

2009-04-14 Thread Chris Thompson
On Apr 14 2009, Lena M wrote: Which TTL value is supposed to be used for negative caching time? -We are running BIND 9.X That's an awful lot of versions of BIND. Can't you be more specific? as a caching server. We are seeing that NXDOMAIN replies are being cached usi

Re: Limit allow-transfer to key + IP

2009-04-14 Thread Chris Thompson
On Apr 14 2009, Jonathan Petersson wrote: I was reading up on TSIG signed zone-transfers and gave it a try in my lab this morning, successfully. However what I noticed (which makes sense based on my config) is that any host with the appropriate key is allowed to perform a zone-transfer. Is ther

Re: Limit allow-transfer to key + IP

2009-04-14 Thread Jonathan Petersson
Thanks! /Jonathan On Tue, Apr 14, 2009 at 12:28 PM, Chris Thompson wrote: > On Apr 14 2009, Jonathan Petersson wrote: > >> I was reading up on TSIG signed zone-transfers and gave it a try in my >> lab this morning, successfully. However what I noticed (which makes >> sense based on my config) is