RE: forwarding zone to another DNS server problem
hi tony, I 'm not familiar with'stub'. The description of 'stub' is hard to understand. What do you mean is to configure 'stub' in the registered authoritative server and to configure zone file with A records in other not registered authoritative servers. Is it all right? Thanks, Guanghua Date: Sun, 2 Nov 2014 21:23:14 + From: d...@dotat.at To: houguang...@hotmail.com CC: bind-users@lists.isc.org Subject: Re: forwarding zone to another DNS server problem houguanghua houguang...@hotmail.com wrote: Can bind support forwarding zone to another DNS server? In my testing, for loacl name servers, it can. But for authority name servers, it can't. Use stub or static-stub to forward to an authoritative server. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: forwarding zone to another DNS server problem
houguanghua houguang...@hotmail.com wrote: I 'm not familiar with'stub'. The description of 'stub' is hard to understand. Yes it's a bit weird. Think of it like the root hints but for other zones: i.e. a hint zone configuration in a recursive server tells named that instead of using a referral from the parent zone to find the name servers for this zone, use these configured name servers. However the name servers at the zone's apex can override your configuration. If you use static-stub instead, your configured name servers override all name servers for the zone that your name server might receive. The difference with forwarding zones occurs if there is a delegation point below the zone you have configured. With a fowarding zone, named expects the target name server to do recursion, so the target server will deal with following the referral and resolving the final answer. With a stub zone, named expects to get authoritative answers and referrals to child zones, and it will do its own recursion to resolve the final answer. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking, North North Utsire: Cyclonic, becoming northeasterly 6 to gale 8, occasionally severe gale 9. Moderate or rough, becoming rough or very rough. Rain or showers. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
unexpected loopback srrt
Hi everyone, I try to set up an authentic bind server in the loopback address(127.0.0.1) in our recursive server of our testbed for test reason. When I send a large number of junk queries(5000QPS), the srrt of loopback server in cash is unexpectedly large. Does anyone know the reason? The srrt is normal when I dig or ping the loopback server by the way. Here is the dump_cache.db's content: ; Address database dump ; ; 10.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::13 [srtt 212] [flags 2000] [ttl 1746] ; 8.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::11 [srtt 744] [flags 2000] [ttl 1746] ; 3.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::6 [srtt 171] [flags 2000] [ttl 1746] ; 9.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::12 [srtt 44] [flags 2000] [ttl 1746] ; 4.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::7 [srtt 64] [flags 2000] [ttl 1746] ; 13.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::16 [srtt 26] [flags 2000] [ttl 1746] ; 5.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::8 [srtt 29] [flags 2000] [ttl 1746] ; 12.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::15 [srtt 2054] [flags 2000] [ttl 1746] ; 6.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::9 [srtt 663] [flags 2000] [ttl 1746] ; 1.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::2 [srtt 550] [flags 2000] [ttl 1746] ; 11.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::14 [srtt 44] [flags 2000] [ttl 1746] ; 7.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::10 [srtt 918] [flags 2000] [ttl 1746] ; 2.root-servers.net [v4 TTL 10744] [v6 TTL 86344] [v4 nxrrset] [v6 success] ; 240c:f:1:122::5 [srtt 360] [flags 2000] [ttl 1746] ; Unassociated entries ; ; ::1 [srtt 689] [flags 2000] [ttl 1745] Best Regards Runxia Wan ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forwarding zone to another DNS server problem
In article mailman.1168.1415095867.26362.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: houguanghua houguang...@hotmail.com wrote: I 'm not familiar with'stub'. The description of 'stub' is hard to understand. Yes it's a bit weird. Think of it like the root hints but for other zones: i.e. a hint zone configuration in a recursive server tells named that instead of using a referral from the parent zone to find the name servers for this zone, use these configured name servers. However the name servers at the zone's apex can override your configuration. If you use static-stub instead, your configured name servers override all name servers for the zone that your name server might receive. The difference with forwarding zones occurs if there is a delegation point below the zone you have configured. With a fowarding zone, named expects the target name server to do recursion, so the target server will deal with following the referral and resolving the final answer. With a stub zone, named expects to get authoritative answers and referrals to child zones, and it will do its own recursion to resolve the final answer. If he wants to do forwarding rather than normal delegation, the likelihood is that the servers for the subdomain are not accessible from the public Internet. So stub won't help. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DANE record rejected by named-checkzone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 named keeps refusing my zone file in which I included a DANE record: [root]# named-checkzone offerman.com db.offerman.com db.offerman.com:59: _443._tcp.offerman.com: bad owner name (check-names) db.offerman.com:60: _443._tcp.offerman.com: bad owner name (check-names) zone offerman.com/IN: loaded serial 2014110103 OK [root]# This appears to be caused by the underscores used in the port/protocol combination. Here's what the record looks like: _443._tcp IN TLSA3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce It was created first using this: tlsa --create --output rfc offerman.com later using this: ldns-dane create offerman.com 443 both resulting in the same record, and both outputs resulting in the same error. I've upgraded the named version (on CentOS 6.6) from 9.8.2 to 9.9.6, but all to no avail :-( [root]# named-checkzone -v 9.9.6-RedHat-9.9.6-0.el6 Am I trying to do something here that is not yet supported or am I overlooking something? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUWVSwAAoJECfzYtonqXzEdIsIAIiHdjp726NW57jF6lxF7cFc oFNFx8uClGHveq6nWjzG9DhplEkFjl8UYMJyfKx3MUlgnKGerREI13WyEwmOrIvk TigcjVEwb3AnbX7RGtzeyqsSAJesx8JdYgLxpSTltfeNpYwjJ4Irl1YQKw3e6hHY y8Lcd9gOYYj+weyZv8BoaEIugit/fuxiLOyJ7mqhyHmrDlny1FLbHMOAJzU8WBxx aa3IUT91RYP5037d4k3Klk+XbieFoiAGSnvHiaqfg8SuXiosiEKAZOfxymb04sqd a4rDiLv6RkLGR8UIWuNfiXNTyGvcZZeW9micMIHVXk/EeEJ1Y7W6vdbwBDJ8M2s= =CVi6 -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DANE record rejected by named-checkzone
In message 545954b0.8080...@offerman.com, Adrian (Aad) Offerman writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 named keeps refusing my zone file in which I included a DANE record: [root]# named-checkzone offerman.com db.offerman.com db.offerman.com:59: _443._tcp.offerman.com: bad owner name (check-names) db.offerman.com:60: _443._tcp.offerman.com: bad owner name (check-names) zone offerman.com/IN: loaded serial 2014110103 OK [root]# This appears to be caused by the underscores used in the port/protocol combination. Here's what the record looks like: _443._tcp IN TLSA3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce Well that isn't a valid TLSA record. It has a bad hex encoding. There are 63 hex digits. TLSA records themselves are not subject to check-names processing so I suggest that you look at the reported lines in the file to find out what is actually there. In the example below it is the A record which has inherited the _443._tcp owner name. Mark [rock:~/git/bind9] marka% bin/check/named-checkzone c.db c.db c.db:1: no TTL specified; using SOA MINTTL instead dns_rdata_fromtext: c.db:3: near eol: bad hex encoding c.db:4: _443._tcp.c.db: bad owner name (check-names) zone c.db/IN: loading from master file c.db failed: bad hex encoding zone c.db/IN: not loaded due to errors. [rock:~/git/bind9] marka% @ IN SOA . . 0 0 0 0 0 @ IN NS . _443._tcp IN TLSA 3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce IN A 1.2.3.4 It was created first using this: tlsa --create --output rfc offerman.com later using this: ldns-dane create offerman.com 443 both resulting in the same record, and both outputs resulting in the same error. I've upgraded the named version (on CentOS 6.6) from 9.8.2 to 9.9.6, but all to no avail :-( [root]# named-checkzone -v 9.9.6-RedHat-9.9.6-0.el6 Am I trying to do something here that is not yet supported or am I overlooking something? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUWVSwAAoJECfzYtonqXzEdIsIAIiHdjp726NW57jF6lxF7cFc oFNFx8uClGHveq6nWjzG9DhplEkFjl8UYMJyfKx3MUlgnKGerREI13WyEwmOrIvk TigcjVEwb3AnbX7RGtzeyqsSAJesx8JdYgLxpSTltfeNpYwjJ4Irl1YQKw3e6hHY y8Lcd9gOYYj+weyZv8BoaEIugit/fuxiLOyJ7mqhyHmrDlny1FLbHMOAJzU8WBxx aa3IUT91RYP5037d4k3Klk+XbieFoiAGSnvHiaqfg8SuXiosiEKAZOfxymb04sqd a4rDiLv6RkLGR8UIWuNfiXNTyGvcZZeW9micMIHVXk/EeEJ1Y7W6vdbwBDJ8M2s= =CVi6 -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
