Re: Multiple BIND instances
δΊ 2012-2-7 15:09, sasa sasa ει: I got a server with 16GB memory, want to install 2 BIND on CentOS, one cache only and another authoritative. Is it better to install 2 OS virtually and run BIND in them or run 2 instances of BIND on the same OS? I mean what is the best practice to take advantage of the hardware resources without risking having single DNS with cache and authoritative? One OS with two or more public IPs for different BIND instances is better IMO. ___ 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
Multiple BIND instances
Hi, I got a server with 16GB memory, want to install 2 BIND on CentOS, one cache only and another authoritative. Is it better to install 2 OS virtually and run BIND in them or run 2 instances of BIND on the same OS? I mean what is the best practice to take advantage of the hardware resources without risking having single DNS with cache and authoritative? regards, Sasa ___ 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: Unknown RR in .in domain
In message <001301cce503$0716a950$1543fbf0$@nic.in>, Gaurav kansal writes: > Thanks Alan. > I got it. > > But why I am getting two NSEC3 records for .in domain?? Shouldn't I > get one NSEC3 RR only Because that is what is required. We are sending the proof thay that a DS record does not exist at the delegation point. 7.2.4. No Data Responses, QTYPE is DS If there is an NSEC3 RR that matches QNAME, the server MUST return it in the response. The bits corresponding with DS and CNAME MUST NOT be set in the Type Bit Maps field of this NSEC3 RR. If no NSEC3 RR matches QNAME, the server MUST return a closest provable encloser proof for QNAME. The NSEC3 RR that covers the "next closer" name MUST have the Opt-Out bit set (note that this is true by definition -- if the Opt-Out bit is not set, something has gone wrong). If a server is authoritative for both sides of a zone cut at QNAME, the server MUST return the proof from the parent side of the zone cut. -- 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
RE: Unknown RR in .in domain
On Feb 6 2012, Gaurav kansal wrote: Thanks Alan. I got it. But why I am getting two NSEC3 records for .in domain?? Shouldn't I get one NSEC3 RR only Because the "in" servers are denying the existence of a signed delegation for "nknsec.in", while (because the zone uses opt-out) allowing the possibility that there is an unsigned one - which of course there is. (This makes the DNSSEC records in the authority section of the referral response look rather like those for a NXDOMAIN one.) Picking an authoritative server for "in" at random: $ dig +dnssec +norec +multi nknsec.in @c0.in.afilias-nst.info. [...] ;; QUESTION SECTION: ;nknsec.in. IN A ;; AUTHORITY SECTION: nknsec.in. 86400 IN NS ns1.nknsec.in. nknsec.in. 86400 IN NS ns3.nknsec.in. 9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN NSEC3 1 1 1 D399EAAB ( 9SJ987F06N7BLS7MRN2KR9252S6281C7 NS SOA RRSIG DNSKEY NSEC3PARAM ) 9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN RRSIG NSEC3 7 2 86400 ( 20120227205111 20120206195111 19608 in. LU3eRPCkAGVTAaSsCmg99OYtfrl6vxWu2d0p9LEp9Pw/ H9LxAGy1owSx9a0FXOjL+iNb7QOQntdAcqcscgDeBLdS 1i2XcMxOhyR5DvZ8BluYOCLEgM14yGBnmy23JB1CTtUo DAGceFp9CijygorEIZbA6EYum3IRkk38o0EMLiA= ) 9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN NSEC3 1 1 1 D399EAAB ( 9RLLTFRS0PA4VCFC17QMBM4SU59P6Q6F A RRSIG ) 9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN RRSIG NSEC3 7 2 86400 ( 20120225164542 20120204154542 19608 in. RHCtdth93BOuuTNMUOU6u/Y/EsYKo1LpZ9vfF+f8C6Vc Q+ajkr8zqi3Cg8gA2kqho6QY55FE4PeLcfo5yFPkO/S+ dK+5mRB5zenw6/HL4QllyyLcviwW1tJ+nNF4M7vTemPI LLAQvWOl1j3McdJAvgoiFfNn4JRii91RxNxLGUI= ) The first NSEC3 record validates facts about the name "in": $ nsec3hash D399EAAB 1 1 in 9SF2FOMUOR72M596CCSODG86639E6ODR (salt=D399EAAB, hash=1, iterations=1) [Note the match to the start of the NSEC3 range] The second NSEC3 record validates facts (the non-existence for DNSSEC purposes, in fact) about the name "nknsec.in": $ nsec3hash D399EAAB 1 1 nknsec.in 9QUOB43RU88DVJLS8B6SB52OQVD8BH80 (salt=D399EAAB, hash=1, iterations=1) [That hash value is in the range 9QQEME... - 9RLLTF... of the NSEC3] Read RFC 5155 section 7.2 in all its horrid detail, especially understanding the whole business of "closest encounters", if you want to know more. As Alan said, you will never, *ever* get anywhere trying to analyse DNSSEC problems with (quite seriously) out-of-date tools. Also if you see strange things in "dig +trace" output, concentrate on the specific iterative stage it was working through at the time - in your example, the response of the authoritative "in" servers. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Unknown RR in .in domain
Thanks Alan. I got it. But why I am getting two NSEC3 records for .in domain?? Shouldn't I get one NSEC3 RR only 9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN TYPE50 \# 39 0101000104D399EAAB144F26941DE035CEBAF0F6DDC54DA445170C24 05870007220290 9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN RRSIG TYPE50 7 2 86400 20120227172834 20120206162834 19608 in. UXEUDIFav8JWIzpA+Wm42o8iQQ4PE0e2kCIXJQOZ2Y6VCarzzQ3t1pZ+ Pg5IU1/knZ5QHHkAR9Uz4JIB44FSOv/FjuhPf2UrvkiODIGuQnxsIc/S zVCuGCS91irQmF1JtEHgFmA/TCycl3uidbyHCwQyowHL6y+R3ZGm+2qs 9i4= 9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN TYPE50 \# 38 0101000104D399EAAB144EEB5EBF7C06544FB1EC09F565D89CF15393 68CF00064002 9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN RRSIG TYPE50 7 2 86400 20120225164542 20120204154542 19608 in. RHCtdth93BOuuTNMUOU6u/Y/EsYKo1LpZ9vfF+f8C6VcQ+ajkr8zqi3C g8gA2kqho6QY55FE4PeLcfo5yFPkO/S+dK+5mRB5zenw6/HL4QllyyLc viwW1tJ+nNF4M7vTemPILLAQvWOl1j3McdJAvgoiFfNn4JRii91RxNxL GUI= -Original Message- From: bind-users-bounces+gaurav.kansal=nic...@lists.isc.org [mailto:bind-users-bounces+gaurav.kansal=nic...@lists.isc.org] On Behalf Of Alan Clegg Sent: Tuesday, February 07, 2012 12:10 AM To: bind-users@lists.isc.org Subject: Re: Unknown RR in .in domain On 2/6/2012 1:35 PM, Gaurav kansal wrote: > Can anyone please tell me why TYPE50 RR is showing in response coming > from .in domain Because your version of DIG does not understand NSEC3 records. http://tools.ietf.org/html/rfc5155 AlanC -- a...@clegg.com | 1.919.355.8851 ___ 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: Unknown RR in .in domain
On 2/6/2012 1:35 PM, Gaurav kansal wrote: > Can anyone please tell me why TYPE50 RR is showing in response > coming from .in domain Because your version of DIG does not understand NSEC3 records. http://tools.ietf.org/html/rfc5155 AlanC -- a...@clegg.com | 1.919.355.8851 signature.asc Description: OpenPGP digital 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: Windows 2008 R2 validating DNSSEC resolvers
> I know this is a bind list, but does anyone know any public information about > when/if Microsoft is going to release a SHA2 compatible DNS server so it can > be used as a validating DNSSEC resolver without forwarders? Since the root > trust anchor is published in SHA2, currently it can't be used (unless someone > knows a workaround). We ran into the same roadblock and are using a bind9.8.1P1 server as a forwarder. Perhaps Windows Server 8 will offer something new a year from now. I haven't heard of anything for Windows Server 2008 R2, although SP2 is supposedly due for release in mid-2012. On the other hand forwarding to a bind system as the recursive resolver for Windows may ultimately be a more secure configuration. ISC has been pretty transparent and responsive with regard to DNS security issues and functionality updates. The fact that Microsoft *still* hasn't updated their DNS service to properly handle DNSSEC tells you something about their priorities, I think. The root zone was signed 18 months ago, after all. I'm curious about your experience with the following in this context. We found that by default the Windows DNS service would forward queries to bind with the DO bit set in the OPT pseudo-resource record and the CD query flag set. In other words, Windows DNS was saying to bind "give me the DNSSEC info and I'll validate it." Of course without the root trust anchor in place, Windows could never do this. Bind would dutifully obey the request, however, so you never got the SERVFAIL response you would want with a DNSSEC validation failure. I opened a tech support case with Microsoft around this issue. It turns out that the command 'dnscmd /config /EnableEDnsProbes 0' fixes the problem by omitting the OPT pseudo-resource record and coincidentally clearing the CD query flag in all forwarded queries. See "Dnscmd" at http://technet.microsoft.com/en-us/library/cc772069(WS.10).aspx for further details. You can test for this on your systems as follows: 'dig @bind.odvr.dns-oarc.net badsign -a.test.dnssec-tools.org' with return a SERVFAIL response from this publicly accessible DNSSEC-validating recursive resolver. Now on one of your Windows systems: 'dig badsign-a.test.dnssec-tools.org' (or use nslookup if you haven't installed the ISC DNS utilities for Windows). This will work through your Windows DNS infrastructure, and if it returns the answer 75.119.216.33 instead of SERVFAIL, then you are subject to this problem. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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
Windows 2008 R2 validating DNSSEC resolvers
I know this is a bind list, but does anyone know any public information about when/if Microsoft is going to release a SHA2 compatible DNS server so it can be used as a validating DNSSEC resolver without forwarders? Since the root trust anchor is published in SHA2, currently it can't be used (unless someone knows a workaround). Thanks. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-460-4139 ___ 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: zone serial (0) unchanged. zone may fail to transfer to slaves.
>> Feb 4 15:53:46 nsb0s named[9090]: zone jspain.us/IN (signed): zone serial >> (2012013003) unchanged. zone may fail to transfer to slaves. > I suspect that is is benign. Had you just thawed the server/zone? After a review of the logs over the past several days, I see that this message occurred only once for each zone following an 'rndc reload'. The slaves had not yet been configured at the time. Now that the slaves are operational, this message does not recur with 'rndc reload'. So I guess the message was an accurate cautionary note at the time. Thanks. Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: Same Transaction ID queries
Samer Khattab wrote: > What is BIND internal logic when such a series of queries are received, and > why it would not answer to all requests. Each query in progress from a given client must have a different ID, so queries with the same ID are logically the same query which only needs one reply. The usual situations in which this occurs are timeouts and retries. Tony. -- f.anthony.n.finchhttp://dotat.at/ East Sole: Northwesterly 4 or 5, becoming variable 4. Moderate or rough. Occasional rain. Moderate 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
RE: How to validate DNSSEC signed record with dig?
Spain, Dr. Jeffry A. wrote: > > Checking your two name servers, 8.8.8.8 (google-public-dns-a.google.com) > doesn't appear to offer DNSSEC validation, and 78.46.213.227 > (rms.coozila.com) doesn't respond to my query at all. It's worse than that. Google Public DNS doesn't support DNSSEC at all, so you cannot use it to query DNSSEC records. DNSSEC requires resolvers to handle RRSIG and DS records in special ways even if they are not validating the signatures. Tony. -- f.anthony.n.finchhttp://dotat.at/ North Utsire, South Utsire: Cyclonic mainly southerly or southeasterly, 5 to 7, occasionally gale 8 in east at first. Rough. Rain or snow. Moderate or 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
Re: bind crash with max-refresh-time 0;
[ Quoting at 13:32 on Feb 6 in "Re: bind crash with ..." ] > >needed to go in production. (Sadly bind bugs aren't searchable on the > >internet). > > > >So to work around this I thought: kill the SOA timers (messing with the > >zone is not an option) and only use notifies. But then bind crashes :) > > Are you sure that only xferring when NOTIFY is received will prevent > from crashing when another NOTIFY is received during transfer > triggered by one NOTIFY? > I doubt so. In such case, better aproach should be disabling NOTIFY > and only transferring when timers expire. Yes, but that would introduce a long(er) latency we don't want. > However, the best approach should be upgrading to 9.8 and/or trying > to replicate the problem (using unstripped BIND with debug > informations and inspecting core file). I'm not going to debug this bind crash. Upgrading to BIND 9.8 is under consideration, but not likely to happen soon. Thanks. grtz Miek signature.asc Description: Digital 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: bind crash with max-refresh-time 0;
>Does this also stop a slave from checking when it receives a >notify? The documentation isn't clear on that. configure master not to send notifies then. Alternatively, you can deny notifies from master. But the first Mark's question is still important: What are you trying to achieve? On 03.02.12 11:05, Miek Gieben wrote: We were (are?) seeing a bug when using multiple masters. If during a zone transfer a notify is sent, it looks like BIND aborts the transfer and tries the second master. This second master is a spare standby and it normally turned off. When BIND hits this second master it sees it cannot do an axfr. BIND then (this is the bug) does not return to the first master to finish (or restart) the transfer. It just sits until the retry timer expires, which in this case is 15 minutes. We notified ISC of this, but replicating this bug was hard and we needed to go in production. (Sadly bind bugs aren't searchable on the internet). So to work around this I thought: kill the SOA timers (messing with the zone is not an option) and only use notifies. But then bind crashes :) Are you sure that only xferring when NOTIFY is received will prevent from crashing when another NOTIFY is received during transfer triggered by one NOTIFY? I doubt so. In such case, better aproach should be disabling NOTIFY and only transferring when timers expire. However, the best approach should be upgrading to 9.8 and/or trying to replicate the problem (using unstripped BIND with debug informations and inspecting core file). -- 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. 99 percent of lawyers give the rest a bad name. ___ 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 validate DNSSEC signed record with dig?
Hello, To be precise : bind.odvr.dns-oarc.net. validates but seems to ignore expired (but otherwise valid) signatures. unbound.odvr.dns-oarc.net. validates without ignoring expired signatures. Kind regards, Marc Lampo Security Officer EURid vzw/asbl -Original Message- From: Spain, Dr. Jeffry A. [mailto:spa...@countryday.net] Sent: 05 February 2012 09:35 PM To: Nikolay Shaplov Cc: bind-users@lists.isc.org Subject: RE: How to validate DNSSEC signed record with dig? > I am trying to validate DNSSEC signature on ns record using dig. > Domain nox.su is properly signed using DNSSEC. > I am trying to validate it as dicribed here: > http://bryars.eu/2010/08/validating-and-exploring-dnssec-with-dig/ > $ dig +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key $ dig +topdown +sigchase nox.su > but it gives me ";; DSset is missing to continue validation: FAILED" error while processing the whole hierarchy of zones. > $ cat /etc/resolv.conf > # Generated by NetworkManager > domain router > search router > nameserver 8.8.8.8 > nameserver 78.46.213.227 Checking your two name servers, 8.8.8.8 (google-public-dns-a.google.com) doesn't appear to offer DNSSEC validation, and 78.46.213.227 (rms.coozila.com) doesn't respond to my query at all. A known-good publicly accessible DNSEC-validating recursive resolver is available at bind.odvr.dns-oarc.net. If I run "dig @bind.odvr.dns-oarc.net nox.su +dnssec", I get an AD (authenticated data) flag returned for the A record with IPv4 address 50.16.193.159. This is a prima facie indication that DNSSEC is working for nox.su. The "+topdown" option isn't available to me (bind 9.9.0rc2 version of dig). Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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
