Re: question about bind bug fixed in 9.6.2-P2
Jack Tavares wrote: From the release notes: --- 9.6.2-P2 released --- 2876. [bug] Named could return SERVFAIL for negative responses from unsigned zones. [RT #21131] Question: Does this bug only occur if dnssec is enabled? or only if dnssec validation is turned on? You're only open to experiencing this problem if an answer passes through the validator - so only if dnssec validation is enabled (meaning that you also have to have a trust anchor configured too). Per the ARM: To enable named to validate answers from other servers, the dnssec-enable and dnssec-validation options must both be set to yes (the default setting in BIND 9.5 and later), and at least one trust anchor must be configured with a trusted-keys statement in named.conf. or will it (potentially) occur regardless of whether or not either of these options are used? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
On 04/06/10 11:11, Tim Verhoeven wrote: Hi, I'm currently testing the automatic signing for DNSSEC present in Bind 9.7. I'm currently using Bind 9.7.0 and I have 2 questions. The first one, can I configure multiple key directories? The reasoning for this is that I would like to seperate the KSK's from the ZSK's. And this to be able to not have the KSK's present all the time by putting them on a removable media. For the ZSK's I have no choice since I will be doing dynamic updates. Or are there other means to do this except from adding and removing the KSK's when needed ? Symlinks to the KSK in another directory? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
On Fri, Jun 4, 2010 at 1:18 PM, Phil Mayers p.may...@imperial.ac.uk wrote: On 04/06/10 11:11, Tim Verhoeven wrote: I'm currently testing the automatic signing for DNSSEC present in Bind 9.7. I'm currently using Bind 9.7.0 and I have 2 questions. The first one, can I configure multiple key directories? The reasoning for this is that I would like to seperate the KSK's from the ZSK's. And this to be able to not have the KSK's present all the time by putting them on a removable media. For the ZSK's I have no choice since I will be doing dynamic updates. Or are there other means to do this except from adding and removing the KSK's when needed ? Symlinks to the KSK in another directory? A good one, why haven't I thought of that myself ;-) Thanks, Tim -- Tim Verhoeven - tim.verhoeven...@gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the microsoft approach to programming and should never be allowed. (Linus Torvalds) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
disable dnssec in bind resolver
hello together, how i can disable dnssec in the bind resolver ? My firewall don´t let packets with D0 flag through. I´ve tried 'dnssec-enable no;' , but this don´t fix the problem. Thanks, Jan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
On Fri, 4 Jun 2010, Jan Buchholz wrote: how i can disable dnssec in the bind resolver ? My firewall don´t let packets with D0 flag through. I´ve tried 'dnssec-enable no;' , but this don´t fix the problem. I believe that only disables *serving* DNSSEC records. I think you want 'dnssec-validation no;' Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
2010/6/4 Paul Wouters p...@xelerance.com: On Fri, 4 Jun 2010, Jan Buchholz wrote: how i can disable dnssec in the bind resolver ? My firewall don´t let packets with D0 flag through. I´ve tried 'dnssec-enable no;' , but this don´t fix the problem. I believe that only disables *serving* DNSSEC records. I think you want 'dnssec-validation no;' Paul sorry, 'dnssec-validation no;' is already configured, because that´s the default. Jan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
On Fri, Jun 4, 2010 at 3:11 AM, Tim Verhoeven tim.verhoeven...@gmail.comwrote: The second question. I've tried doing a resalt using dynamic updates but I can't get it to work. Just adding a new NSEC3PARAM RR crashes Bind and doing a delete and then a add (to replace the present RR) gives me a servfail but I see the updats in the log. What is the correct way to do a resalt when using automatic signing ? This should work: rndc freeze dnssec-signzone ... # using same keys but with new NSEC3 salt rndc reload rndc thaw Although, at least in earlier versions of BIND, if not all RRsets in the zone are resigned with the resign (i.e., within interval specified with -i), then the NSEC3 chain with the new salt is added to any existing NSEC3 chains. There shouldn't be any ill effects from this, but it does increase the size of the zone some. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: disable dnssec in bind resolver
I don't understand that. Are you saying that dnsec-validation no; is in your named.conf or are you saying you don't believe it is necessary to set it there because by default validation is off? If the latter what does it hurt to try it? Obviously something isn't working the way you expect or you wouldn't have asked. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Jan Buchholz Sent: Friday, June 04, 2010 10:50 AM To: Paul Wouters Cc: bind-users@lists.isc.org Subject: Re: disable dnssec in bind resolver 2010/6/4 Paul Wouters p...@xelerance.com: On Fri, 4 Jun 2010, Jan Buchholz wrote: how i can disable dnssec in the bind resolver ? My firewall don´t let packets with D0 flag through. I´ve tried 'dnssec-enable no;' , but this don´t fix the problem. I believe that only disables *serving* DNSSEC records. I think you want 'dnssec-validation no;' Paul sorry, 'dnssec-validation no;' is already configured, because that´s the default. Jan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
On Fri, Jun 04, 2010 at 05:36:21PM +0200, Jan Buchholz wrote: i mean the parameter is the default. Actually, since 9.5.0, the default has been dnssec-validation yes. (Note, however, that DNSSEC validation doesn't occur unless the resolver has a trust anchor configured. So you there has to be a trusted-keys statement, a managed-keys statement, or the dnssec-lookaside auto option, or your resolver won't validate.) Unfortunately, turning off validation won't help. A non-validating recursive resolver still sets the DO bit--all that bit means is go ahead and send me DNSSEC data, it won't hurt me). I'm pretty sure dnssec-enable no does suppress the DO bit. If it doesn't, that's probably a bug. If it doesn't, though, try edns no. You can't have a DO bit if you don't have a place to put one. And, fix the broken firewall as soon as possible. :) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
The first one, can I configure multiple key directories? The reasoning for this is that I would like to seperate the KSK's from the ZSK's. No, you can't... but that's an interesting idea. Right now it's a single key directory per zone. The second question. I've tried doing a resalt using dynamic updates but I can't get it to work. Just adding a new NSEC3PARAM RR crashes Bind and doing a delete and then a add (to replace the present RR) gives me a servfail but I see the updats in the log. What is the correct way to do a resalt when using automatic signing ? The way it's supposed to work is: you add the new NSEC3PARAM record, then wait for the new NSEC3 chain to be built. The newly inserted record will, at first, have its flags field set to a nonzero value; this indicates that the chain isn't complete yet. When the server is finished building the chain, it updates the newly-added NSEC3PARAM record, and zeroes the flags field. At that point, it's safe to remove the old NSEC3PARAM record, which will cause the server to remove the old NSEC3 chain. If inserting a new NSEC3PARAM RR is crashing named, please file a bug report. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
If it doesn't, though, try edns no. You can't have a DO bit if you don't have a place to put one. This seems a bit like my left leg hurts, so i stabbed my right leg. Exactly. Now you aren't lopsided. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
On Fri, Jun 4, 2010 at 9:10 AM, Evan Hunt e...@isc.org wrote: The way it's supposed to work is: you add the new NSEC3PARAM record, then wait for the new NSEC3 chain to be built. The newly inserted record will, at first, have its flags field set to a nonzero value; this indicates that the chain isn't complete yet. When the server is finished building the chain, it updates the newly-added NSEC3PARAM record, and zeroes the flags field. At that point, it's safe to remove the old NSEC3PARAM record, which will cause the server to remove the old NSEC3 chain. This is a much more elegant solution... :) Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
This thread has gotten bogged down in silliness. (Not referring to Paul's message). First, dns-validation is 'off' by default in all BIND versions. It's dnssec-enable that started defaulting to 'yes'. Second, your firewall is simply broken. You will continue to have problems with DNS until you fix/replace it. I have not seen a recent firewall broken in this manner for a while, but this was quite common a couple of years ago. For the moment, turning off dnssec-enable is probably your best hope, but it's not a fix and you are likeky to see continuing problems on a smaller scale until the firewall is fixed. Sent from my Treo: R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) E. O. Lawrence Berkeley National Laboratory (LBNL) ober...@es.net +1 510-486-8634 -Original Message- From: Paul Wouters p...@xelerance.com Date: Friday, Jun 4, 2010 9:20 am Subject: Re: disable dnssec in bind resolver To: Evan Hunt e...@isc.org CC: bind-users@lists.isc.org On Fri, 4 Jun 2010, Evan Hunt wrote: I'm pretty sure dnssec-enable no does suppress the DO bit. If it doesn't, that's probably a bug. Yeah, I thought the default changed when all those NAT routers proved buggy. If it doesn't, though, try edns no. You can't have a DO bit if you don't have a place to put one. This seems a bit like my left leg hurts, so i stabbed my right leg. And, fix the broken firewall as soon as possible. :) Now that is solid advise :) Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
On 6/4/2010 1:52 PM, R. Kevin Oberman wrote: First, dns-validation is 'off' by default in all BIND versions. It's dnssec-enable that started defaulting to 'yes'. No, it isn't. The only reason that dnssec-validation appears off is that without trust anchors, it doesn't do anything. Insert a trust anchor and you validate, even without dnssec-validation yes; in your configuration. Really. Second, your firewall is simply broken. You will continue to have problems with DNS until you fix/replace it. I have not seen a recent firewall broken in this manner for a while, but this was quite common a couple of years ago. 100% agreed. For the moment, turning off dnssec-enable is probably your best hope, but it's not a fix and you are likeky to see continuing problems on a smaller scale until the firewall is fixed. Yep. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
At Fri, 4 Jun 2010 16:50:26 +0200,
Jan Buchholz 96de...@googlemail.com wrote:
how i can disable dnssec in the bind resolver ? My firewall don´t let
packets with D0 flag through. I´ve tried 'dnssec-enable no;' , but
this don´t fix the problem.
I believe that only disables *serving* DNSSEC records.
I think you want 'dnssec-validation no;'
sorry, 'dnssec-validation no;' is already configured, because that´s
the default.
The DO bit is always set whenever the server includes an EDNS OPT RR
(I thought it was based on the specification, but don't remember which
sentence of which RFC says so).
So, your only choice is to completely disable EDNS:
server ::/0 {
edns no;
};
server 0.0.0.0/0 {
edns no;
};
As others said, however, I'd rather say the fix is to upgrade/replace
the broken firewall. Please consider it only for a short term
workaround and seriously consider fixing the real problem.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
First, dns-validation is 'off' by default in all BIND versions. It's dnssec-enable that started defaulting to 'yes'. Correct in the sense that there are no configured trust anchors, so validation doesn't happen. Incorrect in the sense that the dnssec-validation option *is* turned on by default, from BIND 9.5.0 onward. You're right that this isn't relevant to Jan's problem, though. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind security: warning
Dear list am using BIND 9.5.1-P3 recently am been have lots of issues with my cache server. at one point it was not resolving any queries. please help, this is the log that keeps showing up on my server, 04-Jun-2010 19:20:47.200 security: warning: client 41.223.214.27#8222: RFC 1918 response from Internet for 105.1.168.192.in-addr.arpa 04-Jun-2010 19:20:50.279 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 22.81.168.192.in-addr.arpa 04-Jun-2010 19:20:52.196 security: warning: client 41.223.214.25#6394: RFC 1918 response from Internet for 100.1.168.192.in-addr.arpa 04-Jun-2010 19:20:52.820 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 6.81.168.192.in-addr.arpa 04-Jun-2010 19:20:53.226 security: warning: client 196.46.239.37#49803: RFC 1918 response from Internet for 107.1.168.192.in-addr.arpa 04-Jun-2010 19:20:54.403 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 49.81.168.192.in-addr.arpa 04-Jun-2010 19:21:02.701 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 46.81.168.192.in-addr.arpa 04-Jun-2010 19:21:06.560 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 19.81.168.192.in-addr.arpa 04-Jun-2010 19:21:09.455 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 65.81.168.192.in-addr.arpa 04-Jun-2010 19:21:12.939 security: warning: client 196.46.235.46#64502: RFC 1918 response from Internet for 1.0.168.192.in-addr.arpa 04-Jun-2010 19:21:39.691 security: warning: client 41.223.214.26#17391: RFC 1918 response from Internet for 54.2.225.10.in-addr.arpa 04-Jun-2010 19:21:55.762 security: warning: client 196.46.239.37#49803: RFC 1918 response from Internet for 107.1.168.192.in-addr.arpa 04-Jun-2010 19:22:06.800 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 19.81.168.192.in-addr.arpa 04-Jun-2010 19:22:14.439 security: warning: client 41.223.214.27#8436: RFC 1918 response from Internet for 34.3.225.10.in-addr.arpa 04-Jun-2010 19:22:16.639 security: warning: client 196.46.233.8#63154: RFC 1918 response from Internet for 38.81.168.192.in-addr.arpa 04-Jun-2010 19:22:19.387 security: warning: client 41.223.214.25#6394: RFC 1918 response from Internet for 102.1.168.192.in-addr.arpa 04-Jun-2010 19:22:19.810 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 6.81.168.192.in-addr.arpa 04-Jun-2010 19:22:19.992 security: warning: client 196.46.239.7#51996: RFC 1918 response from Internet for 100.1.168.192.in-addr.arpa 04-Jun-2010 19:22:24.889 security: warning: client 41.223.214.27#8473: RFC 1918 response from Internet for 111.1.225.10.in-addr.arpa and before this was the error i was having: 04-Jun-2010 14:12:38.773 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.774 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.774 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.774 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.817 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.817 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.818 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.818 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.834 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.835 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.835 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.835 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.835 general: error: isc_socket_create: fcntl/reserved: Too many open files 04-Jun-2010 14:12:38.863 general: error: isc_socket_create: fcntl/reserved: Too many open files i ran ulimit -n 8192 and that seems to have solve that error ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
On 06/04/10 11:19, JINMEI Tatuya / 神明達哉 wrote: The DO bit is always set whenever the server includes an EDNS OPT RR (I thought it was based on the specification, but don't remember which sentence of which RFC says so). Given that concern about whether or not it's a good idea to always send DO=1 has come up in other contexts I for one would like to see chapter and verse for why doing so is a MUST/SHOULD. If it turns out that DO=1 is not required I'd like to see a BIND option to turn it off. Regarding the OP's situation, there are at least 2 problems. The first being putting a firewall in front of a name server to start with, and the second being that the firewall is broken. However I can think of other reasons to want DO=0, especially in the age where having DNSSEC records is going to be increasingly more common. I have a guess at why ISC would want to enable it by default, and even in the presence of an option to turn it off I'm still Ok with that default. But if it's not a standards requirement to have it on, giving the admin a choice would be a welcome thing. FWIW, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind security: warning
In message beaf8ee567120548d5f437e341c8da8e.squir...@www.qmail.gm, kebba.foon @qcell.gm writes: Dear list am using BIND 9.5.1-P3 recently am been have lots of issues with my cache server. at one point it was not resolving any queries. please help, this is the log that keeps showing up on my server, 04-Jun-2010 19:20:47.200 security: warning: client 41.223.214.27#8222: RFC 1918 response from Internet for 105.1.168.192.in-addr.arpa 04-Jun-2010 19:20:50.279 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 22.81.168.192.in-addr.arpa 04-Jun-2010 19:20:52.196 security: warning: client 41.223.214.25#6394: RFC 1918 response from Internet for 100.1.168.192.in-addr.arpa 04-Jun-2010 19:20:52.820 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 6.81.168.192.in-addr.arpa 04-Jun-2010 19:20:53.226 security: warning: client 196.46.239.37#49803: RFC 1918 response from Internet for 107.1.168.192.in-addr.arpa 04-Jun-2010 19:20:54.403 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 49.81.168.192.in-addr.arpa 04-Jun-2010 19:21:02.701 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 46.81.168.192.in-addr.arpa 04-Jun-2010 19:21:06.560 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 19.81.168.192.in-addr.arpa 04-Jun-2010 19:21:09.455 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 65.81.168.192.in-addr.arpa 04-Jun-2010 19:21:12.939 security: warning: client 196.46.235.46#64502: RFC 1918 response from Internet for 1.0.168.192.in-addr.arpa 04-Jun-2010 19:21:39.691 security: warning: client 41.223.214.26#17391: RFC 1918 response from Internet for 54.2.225.10.in-addr.arpa 04-Jun-2010 19:21:55.762 security: warning: client 196.46.239.37#49803: RFC 1918 response from Internet for 107.1.168.192.in-addr.arpa 04-Jun-2010 19:22:06.800 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 19.81.168.192.in-addr.arpa 04-Jun-2010 19:22:14.439 security: warning: client 41.223.214.27#8436: RFC 1918 response from Internet for 34.3.225.10.in-addr.arpa 04-Jun-2010 19:22:16.639 security: warning: client 196.46.233.8#63154: RFC 1918 response from Internet for 38.81.168.192.in-addr.arpa 04-Jun-2010 19:22:19.387 security: warning: client 41.223.214.25#6394: RFC 1918 response from Internet for 102.1.168.192.in-addr.arpa 04-Jun-2010 19:22:19.810 security: warning: client 196.46.233.8#34578: RFC 1918 response from Internet for 6.81.168.192.in-addr.arpa 04-Jun-2010 19:22:19.992 security: warning: client 196.46.239.7#51996: RFC 1918 response from Internet for 100.1.168.192.in-addr.arpa 04-Jun-2010 19:22:24.889 security: warning: client 41.223.214.27#8473: RFC 1918 response from Internet for 111.1.225.10.in-addr.arpa This is covered in the FAQ. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
Doug Barton do...@dougbarton.us writes: I have a guess at why ISC would want to enable it by default, and even in the presence of an option to turn it off I'm still Ok with that default. But if it's not a standards requirement to have it on, giving the admin a choice would be a welcome thing. this was, as you pointed out, a controversial decision. BIND implements the DO bit as this requestor will not vomit or crash if you include DNSSEC metadata in the response. we believe that this supports the eventual goal of near-universal DNSSEC deployment, in which it's foolish to treat DO as this requestor is explicitly interested in DNSSEC metadata on this answer. the earlier we face the UDP fragmentation pain, the smaller that pain will have been by the time we overcome it. same thing for validator bugs, zone signing/resigning errors/expirations, and everything else that makes always set DO seem unattractive today, to today's sysadmins, who aren't involved in any DNSSEC deployment crusade and don't appreciate being co-opted for it. unless a new IETF RFC comes along and disambiguates the meaning of DO such that it's only to be set if the requestor thinks it has a reasonable shot at validating the resulting metadata, i expect BIND to keep setting DO on all EDNS requests it generates. and i don't think you can make a _public benefit_ argument that this is wrong even though there are _private benefit_ arguments. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
On 06/04/10 19:40, Paul Vixie wrote: Doug Bartondo...@dougbarton.us writes: I have a guess at why ISC would want to enable it by default, and even in the presence of an option to turn it off I'm still Ok with that default. But if it's not a standards requirement to have it on, giving the admin a choice would be a welcome thing. this was, as you pointed out, a controversial decision. BIND implements the DO bit as this requestor will not vomit or crash if you include DNSSEC metadata in the response. we believe that this supports the eventual goal of near-universal DNSSEC deployment, in which it's foolish to treat DO as this requestor is explicitly interested in DNSSEC metadata on this answer. the earlier we face the UDP fragmentation pain, the smaller that pain will have been by the time we overcome it. same thing for validator bugs, zone signing/resigning errors/expirations, and everything else that makes always set DO seem unattractive today, to today's sysadmins, who aren't involved in any DNSSEC deployment crusade and don't appreciate being co-opted for it. unless a new IETF RFC comes along and disambiguates the meaning of DO such that it's only to be set if the requestor thinks it has a reasonable shot at validating the resulting metadata, i expect BIND to keep setting DO on all EDNS requests it generates. and i don't think you can make a _public benefit_ argument that this is wrong even though there are _private benefit_ arguments. Ok, so my guess as to ISC's motivations was pretty much on the mark, and speaking with my Guy who loves the Internet and wants to see things work better for everybody hat on, I am totally in agreement. That's why I said I would have no problem with a theoretical DO knob defaulting to On. With my business hat on though I can see at least 2 possible use cases for DO=0. The first being related to this thread, I can't/won't fix/remove the firewall today, I just want my resolver to work. The hapless user in that spot is either going to use another vendor, or go back to the old version of BIND that works. I know market share isn't a _primary_ concern for BIND, but I would argue that the go back to old version answer to this dilemma is something that we should all be concerned about. The other use case that leaps immediately to mind is We do 42 scintillion DNS queries per second and our bandwidth cost has tripled in the last 3 months! What in the name of J. Jonah Jameson is going on around here?!? In all fairness, I don't have any actual clients telling me that DO=1 is a problem for them, this is pure speculation on my part; although it's speculation with a reasonable amount of experience behind it. In the face of an actual client having actual DO=1 problems I would of course encourage them to fix the underlying issue (and of course, to enable DNSSEC). :) But if they can't/won't/etc Doug (you kids with your newfangled contraptions, get off my lawn!) -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
Doug Barton do...@dougbarton.us writes: On 06/04/10 19:40, Paul Vixie wrote: ... unless a new IETF RFC comes along and disambiguates the meaning of DO such that it's only to be set if the requestor thinks it has a reasonable shot at validating the resulting metadata, i expect BIND to keep setting DO on all EDNS requests it generates. and i don't think you can make a _public benefit_ argument that this is wrong even though there are _private benefit_ arguments. ... With my business hat on though I can see at least 2 possible use cases for DO=0. The first being related to this thread, I can't/won't fix/remove the firewall today, I just want my resolver to work. it works. it's just slower because it has to fall back. this is one of the reasons we fall back to BUFSIZE=512 before falling all the way back to DNS (that is, turning EDNS off all together.) The hapless user in that spot is either going to use another vendor, or go back to the old version of BIND that works. I know market share isn't a _primary_ concern for BIND, but I would argue that the go back to old version answer to this dilemma is something that we should all be concerned about. that's been *very* rare on this point. ISC is concerned about relevance, since we don't want to develop stuff that folks don't want to use. that's *not* happening en masse in this case. ... In all fairness, I don't have any actual clients telling me that DO=1 is a problem for them, this is pure speculation on my part; ... yes, i know that, because i'd see the other side of it if it was going on. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
