Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
Dear Team, I am using RSASHA1 key generation algorithm for generating the KSK and ZSK. Today, I tried to generate the algorithm using RSASHA512 and HMAC-SHA256 algorithm. Key generation through RSASHA512 algorithm run successfully but while generating the keys through HMAC-SHA512 algorithm, I am getting the following error - dnssec-keygen: fatal: a key with algorithm 'HMAC-SHA512' cannot be a zone key I googled it and find a previous discussion on BIND Mailing list that HMAC-* is used for generating keys for Host and not for Zone. I have doubt in this only. What's the difference between Zone or Host ?? Is it key generation for one client machine or what ? I also want to know which algorithm is the best one on security aspects for generating Keys for DNSSEC. Thanks and Regards, Gaurav Kansal Emp Code - 6274 Mob - 9910118448 Intercom - 7331 Have you enabled IPv6 on something today...? ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
Gaurav Kansal gaurav.kan...@nic.in wrote: I have doubt in this only. What's the difference between Zone or Host ?? Zone keys are used for DNSSEC signing zones. Host keys are used for TSIG transaction authentication, for securing zone transfers or dynamic updates. I also want to know which algorithm is the best one on security aspects for generating Keys for DNSSEC. Your security is affected more by how you store the keys than anything else. RSASHA256 is fine. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Faeroes: East or southeast 5 to 7. Rough or very rough. Rain. Moderate. ___ 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: About the conflict between named and pdnsd.
On 03.03.14 13:29, Hongyi Zhao wrote: I use debian wheezy. In order to solve the dns pollution issue for my case. I install the pdnsd (see here for detail: http://members.home.nl/p.a.rombouts/pdnsd/)on my system. dns pollution issue? At the same time, I also have the bind9 installed by default. But the issue for my case is as follows: Bothe the named from bind9 and the pdnsd installed by myself will use the local 53 port. So the will be conflict and cann't start at the same time. How should I solve this issue? only use one DNS server. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows found: (R)emove, (E)rase, (D)elete ___ 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: which Name sever is selected?
By decaying I mean they take some percent of time off of the rtt of the name servers that aren't used when there is a successful query to the fastest. Eventually the slower servers will be faster than the fastest and get queried. That query will set the rtt again for that server and will go back to being slower. On Mar 3, 2014 8:24 AM, houguanghua houguang...@hotmail.com wrote: Hi Ben, What's the meaning of bind decaying? Where can I find the detailed description? Thanks! Guanghua Date: Fri, 28 Feb 2014 11:39:54 -0500 From: Ben Croswell ben.crosw...@gmail.com To: bind-users@lists.isc.org Subject: Re: which Name sever is selected? Message-ID: cajga8zsug2nrznufuxetbpkvzqkjczzred5u2qxw+uqw0pm...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 RTT banding was removed in early versions of 9.8 due to the performance hit being larger than any security benefit. So it would depend what version of bind is being used in this case. https://www.isc.org/blogs/rtt-banding-removal-from-bind-9/ It is important to note that all ns records will take some percent of the traffic even if they are not the fastest. This is due to bind decaying the RTT on the ns records that were not used when it gets a successful query from the fastest ns. That way if there is a failure on a box it can eventually be tried again and make back into the top position. On Feb 28, 2014 11:07 AM, Barry Margolin bar...@alum.mit.edu wrote: In article mailman.2368.1393596895.20661.bind-us...@lists.isc.org, houguanghua houguang...@hotmail.com wrote: If there is a list of NS records, the local name server uses the RTT (round trip time) algorithm to find the fatest, and queries that server. But I found it's not right. In the testing, the local name server doesn't query the fastest authority name server. Some one tells me that if the local name server gets the RTT to one remote server is les than 30ms, it will not test RTT to other remote servers, even if the RTT is more less. In other words, the local server will only query the first remote server with the RTT less than 30ms. Who would tell me the truth? Thanks! Guanghua I believe the RTT values are grouped into ranges, and it prefers servers that are in a better range. 30 ms might be in the lowest range, so another server can't be better. -- 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
Re: which Name sever is selected?
houguanghua houguang...@hotmail.com wrote: What's the meaning of bind decaying? Where can I find the detailed description? Thanks! There's a summary of the SRTT algorithm in http://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Lundy, Fastnet: Northwest 5 to 7, occasionally gale 8 at first, backing south 4 or 5 later, occasionally 6 in southwest Fastnet. Very rough or high, becoming rough in north. Showers then rain. Moderate or 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: disabling stateful firewalls for DNS traffic
This is March, right? I probably should've tried this on one DNS server, instead of all of them. I removed state tracking on outbound to port 53 trafficand nothing could be resolved. And, couldn't fix without manual intervention, as cfagent (cfengine) couldn't resolve its policy server And, as soon as I fixed one systemI started getting the flood of pages from our nagios :) Hmmm, I guess in order to have no state tracking on outbound...I would need to open the inbound wide, because it can't use state tracking to decide if something coming back to a random port is supposed to be coming back I guess I was kind of hoping that this might be the answer on why two of my resolvers get inconsistent results on reply size testing. It either says somewhere around 3830+/-10 or it'll say only 1086 bytes.run a watch on the command every 61 seconds Its probably something else that causing the issue...the main obvious difference is that these two servers are behind our F5. On 03/01/14 08:30, Chuck Anderson wrote: In the following two Best Practices documents, it is recommended to disable stateful firewalls for DNS traffic (outbound on recursive servers, and inbound on authoritative servers). Can people share their Linux iptables configurations for how they have accomplished this? https://deepthought.isc.org/article/AA-00874/0/Best-Practices-for-those-running-Recursive-Servers.html Disable the use of stateful firewalls/packet filters on your servers for outbound query traffic (iterative queries made by a recursive server to authoritative Internet servers). Administrators often consider the impact of stateful firewalls and load balancers on inbound client queries, but then fail to consider their impact on resolver query traffic. https://deepthought.isc.org/article/AA-00892/0/Best-Practices-for-those-running-Authoritative-Servers.html In most instances we would not recommend the use of inbound packet filtering for authoritative nameservers, Response Rate Limiting is the recommended solution. However there are some circumstances where filtering at very high inbound packet rates can be helpful - please contact ISC if you think you might benefit from our operational experience in this area. The typical vendor defaults I've seen don't follow this advice. For example, on Red Hat-like servers, stateful rules like the following are often implemented with rules added to non-open recursive servers to allow only your internal network to connect to port 53: *filter :INPUT DROP :FORWARD DROP :OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m icmp -p icmp --icmp-type any -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -s $INTERNALNET -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -s $INTERNALNET -j ACCEPT -A INPUT -j LOG -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j LOG COMMIT and for authoritative-only servers allowing any sources to connect to port 53: *filter :INPUT DROP :FORWARD DROP :OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m icmp -p icmp --icmp-type any -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A INPUT -j LOG -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j LOG COMMIT How should these rules be changed to adhere to the Best Practices while not breaking anything and still allowing the servers to do their own DNS lookups? I know theoretically how I would do this, but I'm looking for others' experiences. Thanks. ___ 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 -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- SafeZone Ally ___ 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
