RE: about resolving on a child zone
> 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 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
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 the new Internet Explorer 8 optimised for Yahoo!7. Get it now. ___ 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
Position of SOA in master file (was: Re: about resolving on a child zone)
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 (b) have no explicit TTL on the first RR in the master file. Or at least, with the various BIND backwards-compatibility features, that's the case. -- 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: 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 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
