Re: how to hidden the salve
Dan, Yes, also-notify can hide the slave name server. But local dns server can't know where is 'stealth' slave too. Thanks, Guanghua Date: Fri, 21 Feb 2014 07:50:05 -0600 From: Daniel McDonald dan.mcdon...@austinenergy.com To: Untitled bind-users@lists.isc.org Subject: Re: bind-users Digest, Vol 1769, Issue 1 Message-ID: cf2cb5ad.6ae8e%dan.mcdon...@austinenergy.com Content-Type: text/plain; charset=US-ASCII On 2/21/14 3:39 AM, houguanghua houguang...@hotmail.com wrote: kevin, How does the local name server learn where is the 'stealth' slave? For the 'stealth' slave isn't in the NS records. Also-notify directive. Either in an options stanza or a zone stanza. thanks, Guanghua -- Daniel J McDonald, CISSP # 78281 Date: Thu, 20 Feb 2014 10:48:36 -0500 From: Kevin Darcy k...@chrysler.com To: bind-users@lists.isc.org Subject: Re: how to hidden the salve Message-ID: 530623d4.3000...@chrysler.com Content-Type: text/plain; charset=iso-8859-1; Format=flowed A stealth slave has a full copy of the zone, is not published in the NS records, and can resolve names in the latest copy of the zone that it transferred, even if all of the published NSes are down due to a DDoS attack. So, does that not meet the requirements? - Kevin On 2/20/2014 1:28 AM, houguanghua wrote: Stealth slave doesn't fully meet the requirement. It's just part of the requirement to not publish the slave name server in the NS records. Further more, the 'stealth' slave is quired by local DNS server only when all name servers in the NS records are out of service ( maybe in case of ddos attack). Guanghua -- On 2/19/2014 11:54 AM, Kevin wrote: Date: Wed, 19 Feb 2014 11:54:44 -0500 From: Kevin Darcy k...@chrysler.com To: bind-users@lists.isc.org Subject: Re: how to modify the cache Message-ID: 5304e1d4.5000...@chrysler.com mailto:5304e1d4.5000...@chrysler.com Not a good solution. Even under normal circumstances, there will be temporary bottlenecks, dropped packets, etc.. that will trigger failover and users will get different answers at different times. Not good for support, maintainability, user experience/satisfaction, etc. If all you want is resilience, and you own/control the domain in question, why not just slave it (stealth slave, i.e. you don't need to publish it in the NS records)? If you *don't* own/control the domain in question, what business do you have standing up a fake version of it in your own infrastructure? Not a best practice. - Kevin On 2/19/2014 4:51 AM, houguanghua wrote: Steven, Your solution is very good. It can forward the queries to the specified name servers first. But if the specified name server is enabled only when normal dns query process is down. How to configure the local DNS server? The detailed scenario is descibed in below figure: -- | Root| | nameServer | / - (2)/ / -- --- - | Client | __(1)\ | Local | ___(3)_\ | Authority| | Resolver | / | DNS Server | X / | DNS Server | -- - \ \(4) \ \ | Hidden | | DNS Server | Normally, 1) A internet user wants to access www.abc.com http://www.abc.com http://www.abc.com/, a DNS request is sent to local DNS server 2) Local DNS server queries the root name server, the .com name server to get the Authority Name Server of abc.com 3) local DNS server queries the Authority name server, and gets the IP But when the Authority name server is down, the internet user won't get the IP address. My solution is as follows: a) A hidden name server with low performance is deployed. When authority name server can't be accessed, local dns server will access the hidden server. b)The hidden server is never used in normal situation. It act as a cold backup for authority name server. c) The zone file in the hidden server is the same as that configuration in the authority name server d) The hidden name server doesn't appear in the NS records of authority name server Btw, all above doesn't consider the cache in the local dns server. Best Regards, Guanghua Date: Mon, 17 Feb 2014 09:09:13 + Subject: Re: how to modify the cache From: sjc...@gmail.com To: houguang...@hotmail.com CC: bind-users@lists.isc.org On 17 February 2014
Re: dig +sigchase looping
I have verified that this also happens intermittently with dig in BIND 9.9.5 built/configured with: STD_CDEFINES=-DDIG_SIGCHASE=1 export STD_CDEFINES ./configure --enable-threads --enable-largefile — Raymond Walker Software Systems Engineer StSp. ITS - Northern Arizona University From: Ray Walker ray.wal...@nau.edumailto:ray.wal...@nau.edu Date: Friday, February 21, 2014 at 4:28 PM To: bind-users@lists.isc.orgmailto:bind-users@lists.isc.org bind-users@lists.isc.orgmailto:bind-users@lists.isc.org Subject: dig +sigchase looping I’m experiencing an interesting issue where sometimes when performing a sigchase on a valid signed zone the command loops indefinitely when an expired RRSIG exists: Live example: dig +sigchase +trusted-key=./trusted.keys aa.nau.edu A Notes: There is currently a valid RRSIG for this zone. dig compiled with -DDIG_SIGCHASE=1 BIND 9.9.4 Roughly %50 of the time it returns as expected, while other times looping in such a fashion: ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expired ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expired ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expired ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expired ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expired ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expired Any particular reason this should be expected or is it bug worthy (or fixed in 9.9.5, as I didn’t see anything in the change log referring to it)? — Raymond Walker Software Systems Engineer StSp. ITS - Northern Arizona University ___ 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: how to hidden the salve
I guess I'm still not understanding your requirements. In my thinking, the local DNS server would *be* a stealth slave. Why are you considering these as 2 separate instances? - Kevin On 2/24/2014 9:56 AM, houguanghua wrote: Dan, Yes, also-notify can hide the slave name server. But local dns server can't know where is 'stealth' slave too. Thanks, Guanghua Date: Fri, 21 Feb 2014 07:50:05 -0600 From: Daniel McDonald dan.mcdon...@austinenergy.com To: Untitled bind-users@lists.isc.org Subject: Re: bind-users Digest, Vol 1769, Issue 1 Message-ID: cf2cb5ad.6ae8e%dan.mcdon...@austinenergy.com Content-Type: text/plain; charset=US-ASCII On 2/21/14 3:39 AM, houguanghua houguang...@hotmail.com wrote: kevin, How does the local name server learn where is the 'stealth' slave? For the 'stealth' slave isn't in the NS records. Also-notify directive. Either in an options stanza or a zone stanza. thanks, Guanghua -- Daniel J McDonald, CISSP # 78281 Date: Thu, 20 Feb 2014 10:48:36 -0500 From: Kevin Darcy k...@chrysler.com To: bind-users@lists.isc.org Subject: Re: how to hidden the salve Message-ID: 530623d4.3000...@chrysler.com Content-Type: text/plain; charset=iso-8859-1; Format=flowed A stealth slave has a full copy of the zone, is not published in the NS records, and can resolve names in the latest copy of the zone that it transferred, even if all of the published NSes are down due to a DDoS attack. So, does that not meet the requirements? - Kevin On 2/20/2014 1:28 AM, houguanghua wrote: Stealth slave doesn't fully meet the requirement. It's just part of the requirement to not publish the slave name server in the NS records. Further more, the 'stealth' slave is quired by local DNS server only when all name servers in the NS records are out of service ( maybe in case of ddos attack). Guanghua -- On 2/19/2014 11:54 AM, Kevin wrote: Date: Wed, 19 Feb 2014 11:54:44 -0500 From: Kevin Darcy k...@chrysler.com To: bind-users@lists.isc.org Subject: Re: how to modify the cache Message-ID: 5304e1d4.5000...@chrysler.com mailto:5304e1d4.5000...@chrysler.com Not a good solution. Even under normal circumstances, there will be temporary bottlenecks, dropped packets, etc.. that will trigger failover and users will get different answers at different times. Not good for support, maintainability, user experience/satisfaction, etc. If all you want is resilience, and you own/control the domain in question, why not just slave it (stealth slave, i.e. you don't need to publish it in the NS records)? If you *don't* own/control the domain in question, what business do you have standing up a fake version of it in your own infrastructure? Not a best practice. - Kevin On 2/19/2014 4:51 AM, houguanghua wrote: Steven, Your solution is very good. It can forward the queries to the specified name servers first. But if the specified name server is enabled only when normal dns query process is down. How to configure the local DNS server? The detailed scenario is descibed in below figure: -- | Root | | nameServer | / - (2)/ / -- --- - | Client | __(1)\ | Local | ___(3)_\ | Authority | | Resolver | / | DNS Server | X / | DNS Server | -- - \ \(4) \ \ | Hidden | | DNS Server | Normally, 1) A internet user wants to access www.abc.com http://www.abc.com http://www.abc.com/, a DNS request is sent to local DNS server 2) Local DNS server queries the root name server, the .com name server to get the Authority Name Server of abc.com 3) local DNS server queries the Authority name server, and gets the IP But when the Authority name server is down, the internet user won't get the IP address. My solution is as follows: a) A hidden name server with low performance is deployed. When authority name server can't be accessed, local dns server will access the hidden server. b)The hidden server is never used in normal situation. It act as a cold backup for authority name server. c) The zone file in the hidden server is the same as that configuration in the authority name server d) The hidden name server doesn't appear in the NS records of authority name server Btw, all above doesn't consider the cache in the local dns server. Best Regards, Guanghua Date: Mon, 17 Feb 2014 09:09:13 + Subject: Re: how to modify the cache From: sjc...@gmail.com To: houguang...@hotmail.com CC: bind-users@lists.isc.org On 17 February 2014 01:17, houguanghua houguang...@hotmail.com wrote: I want to override the IP address of NS, for I want to use other
Re: dig +sigchase looping
SIGCHASE is a external contribution that is provide as is to dig. The reason that you have to explicitly define it is that ISC hasn't fully gone through the code to find bugs like this in it and it basically needs a full re-write. That said it does mostly work and is better than nothing. This will be two loops over the same rdataset content using the same rdataset structure resulting in the inner loop affecting the outer loop. The fix will be to clone that rdataset before looping over it a second time. Finding it won't be so easy as there are a mixture of local and global references to rdatasets. The first step will probably to find and fix all the instances of code like: dns_rdataset_first(rdataset) do { } while (dns_rdataset_next(global_rdataset) == ISC_R_SUCCESS); Then to use local clones of rdataset so inner loops don't affect outer loops making sure to disassociate before returning. dns_rdataset_t myrdataset; dns_rdataset_init(myrdataset); dns_rdataset_clone(rdataset, myrdataset); rdataset = myrdataset; dns_rdataset_first(rdataset) do { if () { dns_rdataset_disassociate(rdataset); return(...); } } while (dns_rdataset_next(rdataset) == ISC_R_SUCCESS); dns_rdataset_disassociate(rdataset); Mark In message cf30c95b.14d22%ray.wal...@nau.edu, Raymond Drew Walker writes: I have verified that this also happens intermittently with dig in BIND 9.9.= 5 built/configured with: STD_CDEFINES=3D-DDIG_SIGCHASE=3D1 export STD_CDEFINES ./configure --enable-threads --enable-largefile =97 Raymond Walker Software Systems Engineer StSp. ITS - Northern Arizona University From: Ray Walker ray.wal...@nau.edumailto:ray.wal...@nau.edu Date: Friday, February 21, 2014 at 4:28 PM To: bind-users@lists.isc.orgmailto:bind-users@lists.isc.org bind-users= @lists.isc.orgmailto:bind-users@lists.isc.org Subject: dig +sigchase looping I=92m experiencing an interesting issue where sometimes when performing a s= igchase on a valid signed zone the command loops indefinitely when an expir= ed RRSIG exists: Live example: dig +sigchase +trusted-key=3D./trusted.keys aa.nau.edu A Notes: There is currently a valid RRSIG for this zone. dig compiled with -DDIG_SIGCHASE=3D1 BIND 9.9.4 Roughly %50 of the time it returns as expected, while other times looping i= n such a fashion: ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expi= red ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expi= red ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expi= red ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expi= red ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expi= red ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for aa.nau.edu. with DNSKEY:25159: RRSIG has expi= red Any particular reason this should be expected or is it bug worthy (or fixed= in 9.9.5, as I didn=92t see anything in the change log referring to it)? =97 Raymond Walker Software Systems Engineer StSp. ITS - Northern Arizona University --_000_CF30C95B14D22raywalkernauedu_ Content-Type: text/html; charset=Windows-1252 Content-ID: 3fd38cc225294d4e9f862b294dfd3...@iris.nau.edu Content-Transfer-Encoding: quoted-printable html head meta http-equiv=3DContent-Type content=3Dtext/html; charset=3DWindows-1= 252 /head body style=3Dword-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif; div div divI have verified that this also happens intermittently with dig in BIND= 9.9.5 built/configured with:/div divbr /div div divSTD_CDEFINES=3Dquot;-DDIG_SIGCHASE=3D1quot;/div divexport STD_CDEFINES/div div./configure --enable-threads --enable-largefile/div /div div div=97/div divRaymond Walker/div div divSoftware Systems Engineer StSp./div divITS - Northern Arizona University/div /div /div /div /div divbr /div span id=3DOLK_SRC_BODY_SECTION div style=3Dfont-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=