Re: disable dnssec in bind resolver

2010-06-08 Thread Mark Andrews

In message , Warren Kumari wri
tes:
> On Jun 8, 2010, at 6:26 AM, Jan Buchholz wrote:
> 
> > Thanks @all, sorry i was out of office yesterday. I'll discuss the
> > issue this week on the german Linux Tag in Berlin.
> >
> > What your meaning off firewalls, who looks into packets and block them
> > if the filter don=B4t know a flag.
> 
> Some "high security" firewalls examine the actual payload of the 
> packets and validate that the payload follows the spec (at least as 
> they understand the spec). This sounds like a great win, because it 
> allows you to make sure that folks aren't tunneling things over other 
> ports, "protects" your backend from application level attacks (and 
> attacks on the TCP stack and such) and allows NAT fixups for things 
> like SIP -- this is often called an ALG (Application layer gateway), 
> fixups or something similar. Unfortunately they almost always cause 
> way way more issues than they solve, and cause really really 
> interesting troubleshooting problems[0]. The firewall has to maintain 
> a huge amount of state, the ALG is coded for a protocol at a specific 
> point in time and so doesn't deal with extensions (like edns 
> apparently :-P), etc.

You wonder about firewall vendors and whether they are doing their jobs
when they don't support parts of the protocol that are a decade old and
are standards track.

EDNS 1999, DO 2001
 
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

2010-06-08 Thread Warren Kumari


On Jun 8, 2010, at 6:26 AM, Jan Buchholz wrote:


Thanks @all, sorry i was out of office yesterday. I'll discuss the
issue this week on the german Linux Tag in Berlin.

What your meaning off firewalls, who looks into packets and block them
if the filter don´t know a flag.


Some "high security" firewalls examine the actual payload of the  
packets and validate that the payload follows the spec (at least as  
they understand the spec). This sounds like a great win, because it  
allows you to make sure that folks aren't tunneling things over other  
ports, "protects" your backend from application level attacks (and  
attacks on the TCP stack and such) and allows NAT fixups for things  
like SIP -- this is often called an ALG (Application layer gateway),  
fixups or something similar. Unfortunately they almost always cause  
way way more issues than they solve, and cause really really  
interesting troubleshooting problems[0]. The firewall has to maintain  
a huge amount of state, the ALG is coded for a protocol at a specific  
point in time and so doesn't deal with extensions (like edns  
apparently :-P), etc.


W

[0]: My favorite instance of this was downloading an ISO of Ubuntu  
something or other. I downloaded the ISO and ran 'md5sum' to validate  
it -- validation failed so I deleted it and tried again. Validation  
fails again. Lather, rinse, repeat.
After a few tries (all over a 1.5mbps DLS line no less) I ended up  
copying it over SCP instead of HTTP. Validates fine

I run 'diff' to see if I can figure out what the hell is going on.

I discover that (in two places in the file) the sequence 0x4772 0x26C7  
has mysteriously become 0xC0A8 0x002F. I spend a while poking at  
random things (for some reason I had decided it must be bad RAM on the  
RAID controller) and end up converting the bytes to decimal -- the  
correct one is 71 114 38 199 and then incorrect one is 192 168 0 47...  
Wait a minute, that last set of numbers looks *awfully* familiar...  
Yup, it's the address of my machine and the other address is the  
outside address of the firewall...
Suddenly I realize -- the firewall / NAT device is doing NAT "fixup"  
by blindly replacing the "outside" address with the "inside" address  
anywhere in the payload... Whee.







First i´ve fixed the problem with edns no;

Jan
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
I had no shoes and wept.  Then I met a man who had no feet.  So I  
said, "Hey man, got any shoes you're not using?"



___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: disable dnssec in bind resolver

2010-06-08 Thread Jan Buchholz
Thanks @all, sorry i was out of office yesterday. I'll discuss the
issue this week on the german Linux Tag in Berlin.

What your meaning off firewalls, who looks into packets and block them
if the filter don´t know a flag.

First i´ve fixed the problem with edns no;

Jan
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: disable dnssec in bind resolver

2010-06-05 Thread Mark Andrews

In message <201006060107.o5617ep4091...@drugs.dv.isc.org>, Mark Andrews writes:
> 
> In message <4c0aad2a.4010...@dougbarton.us>, Doug Barton writes:
> > On 06/05/10 07:22, Mark Andrews wrote:
> > > In message<4c09c562.7030...@dougbarton.us>, Doug Barton writes:
> > >
> > > The resolver works.  It figures out that it can't make the new style
> > > queries and falls back to the old style queries.  If the user is really
> > > worried they can turn off EDNS and with that DO.
> > 
> > The OP's problem was that his firewall blocked anything with DO=1.
> 
> That was the claim.  I suspect the reality is something different
> and would like to see actual proof that it is not one of the other
> firewall issues.  This is not to say that there are not firewalls
> that choke on DO (when DO was first introduced we saw lookup failures
> due to firewalls blocking it) but given named has been sending DO
> for years it is strange to get a complaint about DO now.

BIND 9.1 sent DO.   Every lookup he made would have been slow
(multiple seconds) if DO was a problem for his firewall.

% grep G_DO 9.?.x/lib/dns/*.c
9.1.x/lib/dns/resolver.c:   rdatalist->ttl = DNS_MESSAGEEXTFLAG_DO;
9.2.x/lib/dns/message.c:if ((ps->ttl & DNS_MESSAGEEXTFLAG_DO) 
!= 0)
9.2.x/lib/dns/message.c:mbz = ps->ttl & ~DNS_MESSAGEEXTFLAG_DO 
& 0x;
9.2.x/lib/dns/resolver.c:   rdatalist->ttl = DNS_MESSAGEEXTFLAG_DO;
9.3.x/lib/dns/message.c:if ((ps->ttl & DNS_MESSAGEEXTFLAG_DO) 
!= 0)
9.3.x/lib/dns/message.c:mbz = ps->ttl & ~DNS_MESSAGEEXTFLAG_DO 
& 0x;
9.3.x/lib/dns/resolver.c:   rdatalist->ttl = DNS_MESSAGEEXTFLAG_DO;
9.4.x/lib/dns/message.c:if ((ps->ttl & DNS_MESSAGEEXTFLAG_DO) 
!= 0)
9.4.x/lib/dns/message.c:mbz = ps->ttl & ~DNS_MESSAGEEXTFLAG_DO 
& 0x;
9.4.x/lib/dns/resolver.c:   rdatalist->ttl |= DNS_MESSAGEEXTFLAG_DO;
9.5.x/lib/dns/message.c:if ((ps->ttl & DNS_MESSAGEEXTFLAG_DO) 
!= 0)
9.5.x/lib/dns/message.c:mbz &= ~DNS_MESSAGEEXTFLAG_DO; 
/* Known Flags. */
9.5.x/lib/dns/resolver.c:   rdatalist->ttl |= DNS_MESSAGEEXTFLAG_DO;
9.6.x/lib/dns/message.c:if ((ps->ttl & DNS_MESSAGEEXTFLAG_DO) 
!= 0)
9.6.x/lib/dns/message.c:mbz &= ~DNS_MESSAGEEXTFLAG_DO; 
/* Known Flags. */
9.6.x/lib/dns/resolver.c:   rdatalist->ttl |= DNS_MESSAGEEXTFLAG_DO;
9.7.x/lib/dns/message.c:if ((ps->ttl & DNS_MESSAGEEXTFLAG_DO) 
!= 0)
9.7.x/lib/dns/message.c:mbz &= ~DNS_MESSAGEEXTFLAG_DO; 
/* Known Flags. */
9.7.x/lib/dns/resolver.c:   rdatalist->ttl |= DNS_MESSAGEEXTFLAG_DO;
% 

> > > It's still a handful of zones that are signed.
> > 
> > But isn't that what we're all working on changing? :)
> >
> > Doug
> -- 
> 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
-- 
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

2010-06-05 Thread Mark Andrews

In message <4c0aad2a.4010...@dougbarton.us>, Doug Barton writes:
> On 06/05/10 07:22, Mark Andrews wrote:
> > In message<4c09c562.7030...@dougbarton.us>, Doug Barton writes:
> >
> > The resolver works.  It figures out that it can't make the new style
> > queries and falls back to the old style queries.  If the user is really
> > worried they can turn off EDNS and with that DO.
> 
> The OP's problem was that his firewall blocked anything with DO=1.

That was the claim.  I suspect the reality is something different
and would like to see actual proof that it is not one of the other
firewall issues.  This is not to say that there are not firewalls
that choke on DO (when DO was first introduced we saw lookup failures
due to firewalls blocking it) but given named has been sending DO
for years it is strange to get a complaint about DO now.
 
> > It's still a handful of zones that are signed.
> 
> But isn't that what we're all working on changing? :)
>
> Doug
-- 
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

2010-06-05 Thread Doug Barton

On 06/05/10 07:22, Mark Andrews wrote:

In message<4c09c562.7030...@dougbarton.us>, Doug Barton writes:

The resolver works.  It figures out that it can't make the new style
queries and falls back to the old style queries.  If the user is really
worried they can turn off EDNS and with that DO.


The OP's problem was that his firewall blocked anything with DO=1.


It's still a handful of zones that are signed.


But isn't that what we're all working on changing? :)


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: disable dnssec in bind resolver

2010-06-05 Thread Doug Barton

On 06/04/10 21:58, Paul Vixie wrote:

Doug Barton  writes:


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 OP's problem was that the firewall between his resolving name server 
and "the cloud" blocks packets with DO=1. Now admittedly this is a 
special kind of stupidity on the firewall's part ...



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.


Right-O. OTOH discussion/thought about the problem now, before it turns 
into a crisis, (probably) can't hurt anything. :)



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: disable dnssec in bind resolver

2010-06-05 Thread Joe Baptista
On Fri, Jun 4, 2010 at 11:32 PM, Doug Barton  wrote:

>
>
> 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.
>

I understand - I do anticipate others share your concern.


> 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?!?"
>

DNSSEC support is a world wide expense. Not only for the users who deploy it
and the registries that support it. But also in bandwidth. If your saying
your DNS traffic has tripled thats sounds about right.

Everybody profits and everybody pays.

Since we have Paul's attention here my question is will he incorporate
DNScurve into BIND now or does he intend to wait until it becomes an RFC?

regards
joe baptista
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disable dnssec in bind resolver

2010-06-05 Thread Mark Andrews

In message <4c09c562.7030...@dougbarton.us>, Doug Barton writes:
> 
> 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 resolver works.  It figures out that it can't make the new style
queries and falls back to the old style queries.  If the user is really
worried they can turn off EDNS and with that DO.
 
> 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?!?"

It's still a handful of zones that are signed.  Referrals are a hundred or
so bytes bigger.  Many still fit in 512 bytes.  If your business isn't DNS
then you really won't notice.  If it is DNS then you should be using that
data to verify the answers you are receiving.
 
> 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 
-- 
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

2010-06-04 Thread Evan Hunt
> 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).

I was taken aback to read this, because I remembered seeing code in named
that clears the DO bit if "dnssec-enable" is "no":

if (!client->view->enablednssec) {
client->extflags &= ~DNS_MESSAGEEXTFLAG_DO;
[...]
}

Looking further, though, I see that Jinmei is correct.  The above code
clears the DO bit in replies sent from an authoritative name server; it
doesn't apply to queries being sent by a resolver.  Resolvers do indeed
set the DO bit unconditionally.  Sorry for any confusion caused by my
earlier statement to the contrary.

--
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

2010-06-04 Thread Paul Vixie
Doug Barton  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


Re: disable dnssec in bind resolver

2010-06-04 Thread Doug Barton

On 06/04/10 19:40, Paul Vixie wrote:

Doug Barton  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

2010-06-04 Thread Paul Vixie
Doug Barton  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

2010-06-04 Thread Doug Barton

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: disable dnssec in bind resolver

2010-06-04 Thread Evan Hunt
> 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


Re: disable dnssec in bind resolver

2010-06-04 Thread JINMEI Tatuya / 神明達哉
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

2010-06-04 Thread Alan Clegg
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

2010-06-04 Thread R. Kevin Oberman
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 
Date: Friday, Jun 4, 2010 9:20 am
Subject: Re: disable dnssec in bind resolver
To: Evan Hunt 
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

2010-06-04 Thread Evan Hunt
> >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: disable dnssec in bind resolver

2010-06-04 Thread Paul Wouters

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


Re: disable dnssec in bind resolver

2010-06-04 Thread Evan Hunt
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: disable dnssec in bind resolver

2010-06-04 Thread Lightner, Jeff
You didn't answer my question.  Telling me it is the default is simply 
regurgitating what you said before.

Is it in your named.conf?  That's a yes/no question.

-Original Message-
From: Jan Buchholz [mailto:96de...@googlemail.com] 
Sent: Friday, June 04, 2010 11:36 AM
To: Lightner, Jeff
Cc: bind-users@lists.isc.org
Subject: Re: disable dnssec in bind resolver

i mean the parameter is the default.

my problem is, if a client want to resolve a ip-address from my
bind-server, the resolver set for some domains the D0 flag for the
question. And this behaviour don´t like my firewall.

Jan

2010/6/4 Lightner, Jeff :
> 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 :
>> 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

2010-06-04 Thread Jan Buchholz
i mean the parameter is the default.

my problem is, if a client want to resolve a ip-address from my
bind-server, the resolver set for some domains the D0 flag for the
question. And this behaviour don´t like my firewall.

Jan

2010/6/4 Lightner, Jeff :
> 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 :
>> 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

2010-06-04 Thread Lightner, Jeff
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 :
> 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

2010-06-04 Thread Jan Buchholz
2010/6/4 Paul Wouters :
> 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: disable dnssec in bind resolver

2010-06-04 Thread Paul Wouters

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