RE: about resolving on a child zone
Original Message Subject: Re: about resolving on a child zone From: Chris Buxton cbux...@menandmice.com Date: Mon, April 13, 2009 10:31 am To: Tech W. tech...@yahoo.com.cn 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 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.example.com, not to example.com. Chris, You said main zone will get an error b/c it has that an A record below the bottom of the zone. Is it correct if that A record was on the top of the zone? like: www.my.example.com. IN A 11.22.33.44 my.example.com. IN NS ns.my.example.com. ns.my.example.com. IN A 55.66.77.88 Thanks too. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Problem with Dynamic DNS Updates using TSIG
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 have been changed for
obvious reasons.
Regards
Erisan
1. DNS Configuration named.conf
key dns1-dhcp1 {
algorithm HMAC-MD5;
secret 0d07/kpYCGfnxbjkRT/QkA==;
};
zone domain-name {
type master;
file zone file location;
allow-update { key dns1-dhcp1; };
};
2. DHCP Configuration dhcpd.conf
key dns1-dhcp1 {
algorithm HMAC-MD5;
secret 0d07/kpYCGfnxbjkRT/QkA==;
};
zone domain-name. {
primary [dns1-ip-add];
key dns1-dhcp1;
}
zone 111.111.in-addr.arpa. {
primary [dns1-ip-add];
key dns1-dhcp1;
}
3. The error I get
dhcp1:~ # nsupdate -y dns1-dhcp1:0d07/kpYCGfnxbjkRT/QkA==
update add jogle-laptop.its.uct.ac.za 86400 A 137.158.156.95
send
; TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: about resolving on a child zone
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.example.com, not to example.com. Chris, You said main zone will get an error b/c it has that an A record below the bottom of the zone. Is it correct if that A record was on the top of the zone? like: www.my.example.com. IN A 11.22.33.44 my.example.com. IN NS ns.my.example.com. ns.my.example.com. IN A 55.66.77.88 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). The bottom of a zone is any delegation point to a subzone. www.my is below a delegation of my. The exception is glue records, which are address records that belong to the subzone but are present to support the delegation itself. Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind9: unknown RR type, unknown class/type errors
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/bind/db.root;
};
zone localhost {
type master;
file /etc/bind/db.local;
};
zone 127.in-addr.arpa {
type master;
file /etc/bind/db.127;
};
zone 0.in-addr.arpa {
type master;
file /etc/bind/db.0;
};
zone 255.in-addr.arpa {
type master;
file /etc/bind/db.255;
};
include /etc/bind/named.conf.local;
named.conf.options:
options {
directory /var/cache/bind;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
named.conf.local:
==
zone go.wiki IN {
type master;
file /etc/bind/db.go.wiki;
};
/etc/bind/db.go.wiki:
$ORIGIN go.wiki.
$TTL 1D
@ IN SOA localhost. hostmaster. (
200405191 ; serial
8H; refresh
4H; retry
4W; expire
1D ) ; minimum
IN NS localhost.
IN A 10.3.64.39
After restarting bind9 I receive the following message in the daemon.log:
Apr 14 15:51:34 ingobert named[14090]: /etc/bind/db.go.wiki:1: unknown RR
type 'go.wiki.'
Apr 14 15:51:34 ingobert named[14090]: zone go.wiki/IN: loading from master
file /etc/bind/db.go.wiki failed: unknown class/type
Any idea what's going wrong? Are there any limitations to zone or domain
names?
Thanks in advance.
Best regards
Frank
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind9: unknown RR type, unknown class/type errors
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 4W; expire 1D ) ; minimum IN NS localhost. IN A 10.3.64.39 After restarting bind9 I receive the following message in the daemon.log: Apr 14 15:51:34 ingobert named[14090]: /etc/bind/db.go.wiki:1: unknown RR type 'go.wiki.' Apr 14 15:51:34 ingobert named[14090]: zone go.wiki/IN: loading from master file /etc/bind/db.go.wiki failed: unknown class/type Any idea what's going wrong? Are there any limitations to zone or domain names? The message says you have an error on line 1, and that go.wiki. is being parsed as a record type. Check the file again and make sure you have a $ before ORIGIN. Or better yet, take out the $ORIGIN statement, as it's completely unnecessary. Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: negative caching time and TTLs
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 the negative caching? RFC 2308 is not clear. Thank you ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Limit allow-transfer to key + IP
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 to require both key and known IP using allow-transfer? Thanks /Jonathan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: negative caching time and TTLs
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 using $TTL time of a given zone instead of its SOA in TTL time. Post some evidence? AFAIK, even very early versions of BIND 9 had the RFC2308 negative caching algorithm. Bear in mind the max-ncache-ttl setting which defaults to 3 hours. -Is $TTL suppose to override SOA's min TTL for the negative caching? RFC 2308 is not clear. How could $TTL override the SOA's min TTL? The $TTL value doesn't exist in the compiled zone, and of course $TTL could occur many times in the input, with different arguments. Maybe you mean the TTL value of the SOA record or something like that? -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Limit allow-transfer to key + IP
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 there any way to limit the zone-transfer to require both key and
known IP using allow-transfer?
Yup. Use
allow-transfer { !{!11.22.33.44}; key secret-key; };
Now sit down with a cold, cold drink and puzzle out why that works!
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Limit allow-transfer to key + IP
Thanks!
/Jonathan
On Tue, Apr 14, 2009 at 12:28 PM, Chris Thompson c...@cam.ac.uk 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 that any host with the appropriate key is
allowed to perform a zone-transfer.
Is there any way to limit the zone-transfer to require both key and
known IP using allow-transfer?
Yup. Use
allow-transfer { !{!11.22.33.44}; key secret-key; };
Now sit down with a cold, cold drink and puzzle out why that works!
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
