Re: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Jan-Piet Mens 
> *except that perhaps those who enable this feature will use it as an
> excuse to avoid enabling validation, which would be a very bad result

+1 +1

A *very* bad result.

-JP

___
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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Hauke Lampe 
On 30.09.2011 03:32, 刘明星：） wrote:

> How does ISP use a proxy to filters answers and returns whatever they want to 
> the customer?

BIND can do that for you with Response Policy Zones (DNS RPZ).
See
http://jpmens.net/2011/04/26/how-to-configure-your-bind-resolvers-to-lie-using-response-policy-zones-rpz/


Hauke.



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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Hauke Lampe 
On 29.09.2011 23:06, Bill Owens wrote:

> *except that perhaps those who enable this feature will use it as an excuse 
> to avoid enabling validation, which would be a very bad result, IMO. . .

My reading of the docs says that BIND's NXDOMAIN redirections won't
break DNSSEC-signed results:

"If the client has requested DNSSEC records (DO=1) and the NXDOMAIN
response is signed then no substitution will occur."

I didn't get it to work, yet, though. After enabling the redirect zone,
BIND goes into an endless loop of zone_timer/zone_maintenance/zone_settimer.

I'll try 9.9.0a2 later today.


Hauke.




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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Jan-Piet Mens 
On Fri Sep 30 2011 at 11:50:51 CEST, Hauke Lampe wrote:

> > *except that perhaps those who enable this feature will use it as an excuse 
> > to avoid enabling validation, which would be a very bad result, IMO. . .
> 
> My reading of the docs says that BIND's NXDOMAIN redirections won't
> break DNSSEC-signed results:
> 
> "If the client has requested DNSSEC records (DO=1) and the NXDOMAIN
> response is signed then no substitution will occur."

I fixed my latest post on this after re-reading the ARM: indeed it
shouldn't break DNSSEC.

> I didn't get it to work, yet, though. After enabling the redirect zone,
> BIND goes into an endless loop of zone_timer/zone_maintenance/zone_settimer.

The redirection works, but I too noticed the CPU consumption (and
reported it to bind9-bugs).

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

inline-signing

2011-09-30 Thread Tony Finch 
I have been playing with the new inline signing feature.

Documentation bug: the inline-signing option is not mentioned in the
syntax for slave zones.

I have not been able to get master inline signing working. Firstly, it
fails to create the signed copy of the zone automatically. If I create it
manually with dnssec-signzone, it fails to update the signed zone when I
edit the master file and tell it to reload.

I have successfully got inline signing working for a slave zone.

Starting with the following configuration:

zone chiark.net {
type slave;
masters { 212.13.197.229; };
file "/zd/chiark.net/master";
};

I ran these commands:

dnssec-keygen chiark.net
dnssec-keygen -f KSK chiark.net

And add the following to the configuration:

key-directory "/zd/chiark.net";
auto-dnssec maintain;
inline-signing yes;

Note that without "auto-dnssec maintain", named creates two copies of the
zone, "master" and "master.signed", but does not actualy sign the zone :-)

Then I ran `rndc reload` and named crashed:

30-Sep-2011 14:15:52.541 general: info: received control channel command 
'reload'
30-Sep-2011 14:15:52.541 general: info: loading configuration from 
'/etc/named.conf'
30-Sep-2011 14:15:52.542 general: warning: statistics-channels specified but 
not effective due to missing XML library
30-Sep-2011 14:15:52.542 general: info: using default UDP/IPv4 port range: 
[49152, 65535]
30-Sep-2011 14:15:52.542 general: info: using default UDP/IPv6 port range: 
[49152, 65535]
30-Sep-2011 14:15:52.543 general: info: sizing zone task pool based on 69 zones
30-Sep-2011 14:15:52.543 general: critical: zone.c:1130: REQUIRE(zone->type == 
dns_zone_none || zone->type == type) failed, back trace
30-Sep-2011 14:15:52.544 general: critical: #0 0x413f1b in 
assertion_failed()+0x4b
30-Sep-2011 14:15:52.544 general: critical: #1 0x5795aa in 
isc_assertion_failed()+0xa
30-Sep-2011 14:15:52.544 general: critical: #2 0x550c4e in 
dns_zone_settype()+0x12e
30-Sep-2011 14:15:52.544 general: critical: #3 0x4432f9 in 
ns_zone_configure()+0x219
30-Sep-2011 14:15:52.544 general: critical: #4 0x4253fd in 
configure_zone()+0x84d
30-Sep-2011 14:15:52.544 general: critical: #5 0x42ae70 in 
configure_view()+0x610
30-Sep-2011 14:15:52.544 general: critical: #6 0x43232c in 
load_configuration()+0x1aac
30-Sep-2011 14:15:52.544 general: critical: #7 0x43378e in loadconfig()+0x5e
30-Sep-2011 14:15:52.544 general: critical: #8 0x433c56 in reload()+0x16
30-Sep-2011 14:15:52.544 general: critical: #9 0x433df2 in 
ns_server_reloadcommand()+0x102
30-Sep-2011 14:15:52.544 general: critical: #10 0x40d9b2 in 
ns_control_docommand()+0xf2
30-Sep-2011 14:15:52.544 general: critical: #11 0x410c71 in 
control_recvmessage()+0x3c1
30-Sep-2011 14:15:52.544 general: critical: #12 0x593f55 in run()+0x285
30-Sep-2011 14:15:52.544 general: critical: #13 0x800bfb511 in 
_fini()+0x8006542d9
30-Sep-2011 14:15:52.544 general: critical: #14 0x0 in ??
30-Sep-2011 14:15:52.544 general: critical: exiting (due to assertion failure)

After I restarted it, it fetched and signed the zone as expected.

30-Sep-2011 14:21:29.562 general: info: zone chiark.net/IN (unsigned): Transfer 
started.
30-Sep-2011 14:21:29.567 xfer-in: info: transfer of 'chiark.net/IN (unsigned)' 
from 212.13.197.229#53: connected using 131.111.11.130#26910
30-Sep-2011 14:21:29.576 general: info: zone chiark.net/IN (unsigned): 
transferred serial 11
30-Sep-2011 14:21:29.576 general: info: zone chiark.net/IN (signed): loaded 
serial 11
30-Sep-2011 14:21:29.576 general: info: zone chiark.net/IN (signed): 
reconfiguring zone keys
30-Sep-2011 14:21:29.582 xfer-in: info: transfer of 'chiark.net/IN (unsigned)' 
from 212.13.197.229#53: Transfer completed: 1 messages, 14 records, 401 bytes, 
0.015 secs (26733 bytes/sec)
30-Sep-2011 14:21:29.583 general: info: zone chiark.net/IN (signed): next key 
event: 30-Sep-2011 15:21:29.583
30-Sep-2011 14:21:29.583 notify: info: zone chiark.net/IN (signed): sending 
notifies (serial 12)
30-Sep-2011 14:21:34.577 notify: info: zone chiark.net/IN (signed): sending 
notifies (serial 15)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Faeroes, South-east Iceland: Southerly or southwesterly 5 to 7, occasionally
gale 8 in Southeast Iceland. Rough or very rough. Rain then showers. Moderate
or good, occasionally poor at first.
___
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: CNAME or A record?

2011-09-30 Thread Joseph S D Yao 
On Wed, Sep 28, 2011 at 04:19:41PM +0200, feralert wrote:
...
> The thing is that i want users redirected to 'www.domain.com' even
> when they just type the domain name 'domain.com'.
> In order to do so I am not sure if its best to have one A RR for each
> or have an A RR for the domain and a CNAME RR pointing to 'domain.com'
> for 'www.domain.com'.
> 
> 
> domain.com   A1.1.1.1
> www.domain.com   A1.1.1.1
> 
> OR
> 
> domain.com   A1.1.1.1
> www.domain.com   CNAME  domain.com
...


It's clear you need an entry for both.  Which is a matter of future
maintenance.  If you only want to change it in one place, and you'll
never need any other records for "www" different from those for the
domain itself, go ahead and use the CNAME.  (Multiply this by 1000 times
in 1000 different domains, or maybe all within the one domain, and it
may matter.  OTOH, if you are using one file for 1000 different domains,
you CAN't use the CNAME.  I don't think.)

The only downside, besides not being able to have other records for the
"www" name, is that the resolver now has to make TWO queries.  If your
name server is a PDP-11/05 running Unix V6 and BIND 4.1.2, this might
make a difference.  [And if so - may I see it?  ;~)]  However, most name
servers these days are made of sterner stuff.  And if you're truly doing
a "redirect" instead of just serving the same Web site at both names,
it'll have to make two queries anyway.

As someone tried to say but didn't [too many pronouns, not enough clear
antecedents], a "redirect" would be done by your Web server, not by DNS.
The Web server at "domain.com" would say, go away, nothing to see here,
it's all going down at "www.domain.com".  And the Web server at
"www.domain.com" would have all the goodies.  But if you're serving the
same Web content at both names, that's NOT a "redirect".  Whichever you
do, as I started out saying, you need both DNS entries.  Whatever they
may be.


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
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: inline-signing

2011-09-30 Thread Michael Graff 
I opened a ticket on Tony's behalf so we can track the crash problem and the 
other defects he mentioned.  As I told him there, the master functionality is 
still a work in progress, and the code's not there yet.  "Soon."

Thank you Tony for giving this a try as an alpha!  Your time is appreciated.

--Michael

___
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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread John Wobus 
. . . both Evan's blog post  and the announcement of next week's webinar include NXDOMAIN  
redirection as the first new feature. I'm really surprised by that  
- is this something that BIND users were clamoring for?


Yes.


I'm a BIND user who is clamoring to keep such a feature out of BIND.

John

___
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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Warren Kumari 

On Sep 30, 2011, at 1:12 PM, John Wobus wrote:

>>> . . . both Evan's blog post 
>>>  
>>> and the announcement of next week's webinar include NXDOMAIN redirection as 
>>> the first new feature. I'm really surprised by that - is this something 
>>> that BIND users were clamoring for?
>> 
>> Yes.
> 
> I'm a BIND user who is clamoring to keep such a feature out of BIND.

+1.

I understand the reasoning and justification for it being added, but it makes 
me a sad panda...
W


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

___
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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread michoski 
On 9/30/11 10:12 AM, "John Wobus"  wrote:
> I'm a BIND user who is clamoring to keep such a feature out of BIND.

In reality, there are plenty of you (us)...  However, as usual (and
particularly for anything ruled by committee), a few (often with the most
capital) will ruin it for the many.  For better or worse, that's how society
works...  I doubt we can change that in one lifetime.  ;-)

While I'd prefer to do the right thing from a technical perspective (e.g.
aligning with the protocol's inventor seems sensical), "choice" is usually
the best approach...  If some ISPs want to (ab)use this, the smart users
will change ISPs.  As others pointed out, the bad ISPs will (and have)
do(ne) it regardless of BIND support.

-- 
By nature, men are nearly alike;
by practice, they get to be wide apart.
-- Confucius

___
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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Bill Owens 
On Thu, Sep 29, 2011 at 04:52:10PM -0500, Michael Graff wrote:
> I'm happy you read it, and hope to see you at the forum/customer webinar next 
> week!  I'll be speaking, and will bring my fireproof undies.

I'm already signed up, but no worries about flaming - at least not from me ;)

> We came to the conclusion that no matter how much we wanted it to not be 
> true, people find a way to do NXDOMAIN if they want to.  The issue is not 
> ours to push, it's between the ISP and the customer ultimately, and people 
> will do it -- and more intrusively -- than BIND 9.9 will.

Good point - if it's implemented in BIND 9.9, then perhaps it can be more sane 
than if done by someone else. Might I propose a pair of changes to the behavior 
that would improve its sanity level dramatically, from my perspective? Right 
now, the ARM describes 'redirect' thusly:

"If the client has requested DNSSEC records (DO=1) and the NXDOMAIN response is 
signed then no substitution will occur."

That's a fairly obvious choice, since it isn't possible to fake an answer if 
both sides of the transaction are actively doing DNSSEC. Philosophically, 
though, I think it's more correct to decree that if *either* side is doing 
DNSSEC, no substitution should occur. That is, if the query comes in with DO=1, 
no substitution because the client is trying to use DNSSEC, and if the response 
is signed, so substitution because the server is doing likewise.

That means I can opt out of NXDOMAIN substitution either by running a local 
client (forwarder, stub or application) that sets DO=1, and on the other side 
can opt out by signing my zone. We hope that someday everyone will do those 
things anyway, at which point redirect stops working anyway. . .

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

"auto-dnssec maintain" stoped working again...

2011-09-30 Thread Michelle Konzack 
Good evening*,

I run my three NS with DNSSEC and now I have encountered,  that  it  has
stoped maintaining the Zone since  september  and  has  not  changed  to
october.  It was working for 4 month only.

I have no error messages in my logs.

Any hints, why this happen from time to time?

I use bind 9.7.3 from the Debian GNU/Linux Distribution 6.0.2 (Squeeze).

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet
Owner Michelle Konzack
Tel office: +49-176-86004575
Gewerbe Strasse 3   Tel mobil:  +49-177-9351947
77694 Kehl/Germany  Tel mobil:  +33-6-61925193  (France)




Jabber linux4miche...@jabber.ccc.de

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
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: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Shawn Bakhtiar 


"We came to the conclusion that no matter how much we wanted it to not be true, 
people find a way to do NXDOMAIN if they want to. The issue is not ours to 
push, it's between the ISP and the customer ultimately, and people will do it 
-- and more intrusively -- than BIND 9.9 will."
That is just giving in. To what WILL end up being akin (is akin) to taking away 
access. The argument that everyone is doing it so let's just facilitate it is a 
bad one. This is a cave in to bad behavior which borders on freedom of speech 
violation, since your sanctioning the ability to arbitrarily redirecting 
(without redirecting) content. Important part being the sanctioning of.
http://en.wikipedia.org/wiki/DNS_hijacking


> Date: Fri, 30 Sep 2011 17:15:01 -0400
> From: ow...@nysernet.org
> To: mgr...@isc.org
> Subject: Re: NXDOMAIN redirection in BIND 9.9
> CC: bind-users@lists.isc.org
> 
> On Thu, Sep 29, 2011 at 04:52:10PM -0500, Michael Graff wrote:
> > I'm happy you read it, and hope to see you at the forum/customer webinar 
> > next week!  I'll be speaking, and will bring my fireproof undies.
> 
> I'm already signed up, but no worries about flaming - at least not from me ;)
> 
> > We came to the conclusion that no matter how much we wanted it to not be 
> > true, people find a way to do NXDOMAIN if they want to.  The issue is not 
> > ours to push, it's between the ISP and the customer ultimately, and people 
> > will do it -- and more intrusively -- than BIND 9.9 will.
> 
> Good point - if it's implemented in BIND 9.9, then perhaps it can be more 
> sane than if done by someone else. Might I propose a pair of changes to the 
> behavior that would improve its sanity level dramatically, from my 
> perspective? Right now, the ARM describes 'redirect' thusly:
> 
> "If the client has requested DNSSEC records (DO=1) and the NXDOMAIN response 
> is signed then no substitution will occur."
> 
> That's a fairly obvious choice, since it isn't possible to fake an answer if 
> both sides of the transaction are actively doing DNSSEC. Philosophically, 
> though, I think it's more correct to decree that if *either* side is doing 
> DNSSEC, no substitution should occur. That is, if the query comes in with 
> DO=1, no substitution because the client is trying to use DNSSEC, and if the 
> response is signed, so substitution because the server is doing likewise.
> 
> That means I can opt out of NXDOMAIN substitution either by running a local 
> client (forwarder, stub or application) that sets DO=1, and on the other side 
> can opt out by signing my zone. We hope that someday everyone will do those 
> things anyway, at which point redirect stops working anyway. . .
> 
> Bill.
> ___
> 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
  ___
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

DNSSEC not populating parent zone files with DS records

2011-09-30 Thread Raymond Drew Walker 
In our initial implementation of DNSSEC, we chose to try out the "auto"
functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
all master zones.

When going live, we found that though all zones that we are acting as
master for would populate their own DS records, but there would be no
population of a child zone's DS record in the corresponding parent master
zone file. 

This means upon go-live, any DNSSEC validation of our children zones
(X.nau.edu, Y.X.nau.edu etc.) would fail, though our root master zone
(nau.edu) would validate fine.

We have since backed out DNSSEC until we can get a resolution of the issue.

After much research, I'm not sure why this is happening... Any suggestions
or ideas?

Raymond Walker
Software Systems Engineer Sr.
ITS Northern Arizona University





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread David Miller 

On 9/30/2011 6:21 PM, Shawn Bakhtiar wrote:


"We came to the conclusion that no matter how much we wanted it to not 
be true, people find a way to do NXDOMAIN if they want to. The issue 
is not ours to push, it's between the ISP and the customer ultimately, 
and people will do it -- and more intrusively -- than BIND 9.9 will."


That is just giving in. To what WILL end up being akin (is akin) to 
taking away access. The argument that everyone is doing it so let's 
just facilitate it is a bad one. This is a cave in to bad behavior 
which borders on freedom of speech violation, since your sanctioning 
the ability to arbitrarily redirecting (without redirecting) content. 
Important part being the sanctioning of.


http://en.wikipedia.org/wiki/DNS_hijacking



You get to run your network how ever you like.  This is your right.  
Turn the feature on if you like -or- make sure it is off if you don't 
like it.


You don't get to tell others how to run their networks.  Well... you can 
tell them, but they don't have to listen to you...


Many organizations want to do NXDOMAIN redirections on their resolvers 
on their own internal networks or on guest wireless networks or on 
whatever networks they control for whatever reasons they like.


Other resolvers have had the ability to do NXDOMAIN redirections for 
many years.  The pressures keeping ISPs from implementing NXDOMAIN 
redirections has never been the fact that BIND didn't support it.


You are going to have a hard time making the case that NXDOMAIN 
redirections are a "freedom of speech violation", but the place for that 
argument is in the court room.


Instead of seeing this as a "sky is falling" event, why not see it as an 
opportunity to create your own resolving DNS service that does not do 
NXDOMAIN redirections?  Then every ISP that implemented NXDOMAIN 
redirections (using BIND or any of the myriad of other software that 
will do it) would be another potential group of customers for you.


-DMM

___
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: DNSSEC not populating parent zone files with DS records

2011-09-30 Thread Bill Owens 
On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote:
> In our initial implementation of DNSSEC, we chose to try out the "auto"
> functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
> all master zones.
> 
> When going live, we found that though all zones that we are acting as
> master for would populate their own DS records, but there would be no
> population of a child zone's DS record in the corresponding parent master
> zone file. 
> 
> This means upon go-live, any DNSSEC validation of our children zones
> (X.nau.edu, Y.X.nau.edu etc.) would fail, though our root master zone
> (nau.edu) would validate fine.
> 
> We have since backed out DNSSEC until we can get a resolution of the issue.
> 
> After much research, I'm not sure why this is happening... Any suggestions
> or ideas?

I think there's something else going on here. If you have DNSKEY records in the 
child but no DS in the parent, everything should still be okay - there's no 
chain of trust, but there's also no assertion from the parent that there 
*should be* a chain of trust (that's what the DS record does).

However, in this case I believe your problem is the lack of NS records in 
nau.edu for extended.nau.edu. It's difficult to know for sure, but it appears 
that the only signature for the NS RRSET is using the ZSK for extended.nau.edu, 
not the ZSK for nau.edu. 

In the olden days you could get away with that since the same servers are 
authoritative for both zones, and they'd answer correctly. In the new world of 
DNSSEC, if you ask for extended.nau.edu, you get this:

paperboy {owens}% dig +dnssec extended.nau.edu a

; <<>> DiG 9.9.0a2 <<>> +dnssec extended.nau.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60942
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;extended.nau.edu.  IN  A

;; AUTHORITY SECTION:
ewb.nau.edu.10199   IN  RRSIG   NSEC 5 3 86400 20111019222812 
20110919220129 7485 nau.edu. 
SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U 
VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV 
00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
ewb.nau.edu.10199   IN  NSECfacdevnet.nau.edu. CNAME RRSIG 
NSEC
nau.edu.10199   IN  SOA ns3.nau.edu. 
DNS-Contact.nau.edu. 4779 1800 900 604800 86400
nau.edu.10199   IN  RRSIG   SOA 5 2 86400 20111030191258 
20110930181258 7485 nau.edu. 
xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9 
fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI 
G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
nau.edu.10199   IN  RRSIG   NSEC 5 2 86400 20111020001752 
20110919233312 7485 nau.edu. 
GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP 
/JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk 
UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
nau.edu.10199   IN  NSEC_tcp.nau.edu. A NS SOA MX TXT 
RRSIG NSEC DNSKEY TYPE65534

No records, so no delegation, so nowhere to go to get the A record (which is 
actually configured).

As for BIND automatically populating DS records, I don't even know whether 
that's a feature. Is it in the docs? I don't remember seeing it, but it's a big 
manual and I might have missed that reference. . .

Bill.
___
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: "auto-dnssec maintain" stoped working again...

2011-09-30 Thread Hauke Lampe 
On 01.10.2011 00:09, Michelle Konzack wrote:

> I run my three NS with DNSSEC and now I have encountered,  that  it  has
> stoped maintaining the Zone since  september  and  has  not  changed  to
> october.

Do you mean expired signatures or no signatures at all?
In the latter case, have you checked that the zone's keys are readable
by named and still active?

Try dnssec-settime -p all /path/to/keys/Kexample.com.+005+12345.key and
look for "Activate:" and "Inactive:"

There have been a few bugfixes to automatic signing between 9.7.3 and
9.8. Maybe you hit one of those bugs.


Hauke.



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: DNSSEC not populating parent zone files with DS records

2011-09-30 Thread Jeff Reasoner 
Hmm, I see an A record using the same query:

[foo@dns1 ~]$ dig +dnssec extended.nau.edu a

; <<>> DiG 9.8.1 <<>> +dnssec extended.nau.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13732
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;extended.nau.edu. IN A

;; ANSWER SECTION:
extended.nau.edu. 86349 IN A 134.114.104.140
extended.nau.edu. 86349 IN RRSIG A 5 3 86400 20111019233054
20110919230651 36030 extended.nau.edu.
Oa5g4Nla0O4T2yUIwsKU17VacHWDGLg1ElTKxunftZDcXhiRhH4jwoe8
IWcLdKQ/6VRE9JikTo5MOqV/PbXH+6yzBSzfzmJKP0+KAW6KnNRhETmL
B60UHJmqpWZC8VoV1FOZ2Ma54dSXsw0HKaTksJ1ubGILeWMNb5C1TTrK bzc=

;; AUTHORITY SECTION:
extended.nau.edu. 86349 IN NS ns3.nau.edu.
extended.nau.edu. 86349 IN NS ns2.nau.edu.
extended.nau.edu. 86349 IN NS ns1.nau.edu.
extended.nau.edu. 86349 IN RRSIG NS 5 3 86400 20111019233054
20110919230651 36030 extended.nau.edu.
E8Q9Db8ncNOVdw0cdlHT2iY3SYkdBtPsGP2Xmacn95Br8pxe0Y5Hq3fZ
k0b/v6D872DcmELDcVliOGbNPNLxm2rtl3CG3QjcOr4qUZjQDTqnApgZ KfJ
+V2RUEd0LqcF1PAPmHOn8c/TkBq1m9ir29N77k/x5WW8seRwyRvcD iEU=

;; Query time: 1 msec
;; SERVER: 10.241.0.10#53(10.241.0.10)
;; WHEN: Fri Sep 30 20:42:38 2011
;; MSG SIZE  rcvd: 467


On Fri, 2011-09-30 at 19:56 -0400, Bill Owens wrote: 
> On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote:
> > In our initial implementation of DNSSEC, we chose to try out the "auto"
> > functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
> > all master zones.
> > 
> > When going live, we found that though all zones that we are acting as
> > master for would populate their own DS records, but there would be no
> > population of a child zone's DS record in the corresponding parent master
> > zone file. 
> > 
> > This means upon go-live, any DNSSEC validation of our children zones
> > (X.nau.edu, Y.X.nau.edu etc.) would fail, though our root master zone
> > (nau.edu) would validate fine.
> > 
> > We have since backed out DNSSEC until we can get a resolution of the issue.
> > 
> > After much research, I'm not sure why this is happening... Any suggestions
> > or ideas?
> 
> I think there's something else going on here. If you have DNSKEY records in 
> the child but no DS in the parent, everything should still be okay - there's 
> no chain of trust, but there's also no assertion from the parent that there 
> *should be* a chain of trust (that's what the DS record does).
> 
> However, in this case I believe your problem is the lack of NS records in 
> nau.edu for extended.nau.edu. It's difficult to know for sure, but it appears 
> that the only signature for the NS RRSET is using the ZSK for 
> extended.nau.edu, not the ZSK for nau.edu. 
> 
> In the olden days you could get away with that since the same servers are 
> authoritative for both zones, and they'd answer correctly. In the new world 
> of DNSSEC, if you ask for extended.nau.edu, you get this:
> 
> paperboy {owens}% dig +dnssec extended.nau.edu a
> 
> ; <<>> DiG 9.9.0a2 <<>> +dnssec extended.nau.edu a
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60942
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;extended.nau.edu.IN  A
> 
> ;; AUTHORITY SECTION:
> ewb.nau.edu.  10199   IN  RRSIG   NSEC 5 3 86400 20111019222812 
> 20110919220129 7485 nau.edu. 
> SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U 
> VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV 
> 00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
> ewb.nau.edu.  10199   IN  NSECfacdevnet.nau.edu. CNAME RRSIG 
> NSEC
> nau.edu.  10199   IN  SOA ns3.nau.edu. 
> DNS-Contact.nau.edu. 4779 1800 900 604800 86400
> nau.edu.  10199   IN  RRSIG   SOA 5 2 86400 20111030191258 
> 20110930181258 7485 nau.edu. 
> xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9 
> fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI 
> G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
> nau.edu.  10199   IN  RRSIG   NSEC 5 2 86400 20111020001752 
> 20110919233312 7485 nau.edu. 
> GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP 
> /JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk 
> UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
> nau.edu.  10199   IN  NSEC_tcp.nau.edu. A NS SOA MX TXT 
> RRSIG NSEC DNSKEY TYPE65534
> 
> No records, so no delegation, so nowhere to go to get the A record (which is 
> actually configured).
> 
> As for BIND automatically populating DS records, I don't even know whether 
> that's a feature. Is it in the docs? I don't remember seeing it, but it's a 
> big manual and I might have missed that reference. . .
> 
> Bill.
>

Re: DNSSEC not populating parent zone files with DS records

2011-09-30 Thread Bill Owens 
On Fri, Sep 30, 2011 at 08:48:56PM -0400, Jeff Reasoner wrote:
> Hmm, I see an A record using the same query:

Interesting. . . my validating resolver (also 9.8.1) will only give me an A if 
I ask with +cd. And if I follow that query with another, without the +cd, I get 
SERVFAIL; then re-querying with +cd gives NXDOMAIN. Do you have validation 
enabled as well?

Bill.
___
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: DNSSEC not populating parent zone files with DS records

2011-09-30 Thread Hauke Lampe 
On 01.10.2011 02:48, Jeff Reasoner wrote:
> Hmm, I see an A record using the same query:
> [foo@dns1 ~]$ dig +dnssec extended.nau.edu a

I get a SERVFAIL response for the first query and NXDOMAIN for
subsequent request:

named: client 127.0.0.1#54707: query: extended.nau.edu IN A +ED (127.0.0.1)
named: createfetch: extended.nau.edu A
named: createfetch: extended.nau.edu DNSKEY
named: createfetch: extended.nau.edu DS
named: createfetch: nau.edu DNSKEY
named: createfetch: nau.edu DS
named: createfetch: edu DNSKEY
named: createfetch: nau.edu.dlv.isc.org DLV
named:   validating @0x7f36f7f17680: nau.edu SOA: no valid signature found
named:   validating @0x7f36f7eed410: nau.edu NSEC: no valid signature found
named:   validating @0x7f36f7eed410: ewb.nau.edu NSEC: no valid
signature found
named: error (broken trust chain) resolving
'extended.nau.edu/DNSKEY/IN': 134.114.138.3#53
named: error (broken trust chain) resolving 'extended.nau.edu/A/IN':
134.114.96.4#53
named: client 127.0.0.1#54707: query failed (SERVFAIL) for
extended.nau.edu/IN/A at query.c:6302
named: client 127.0.0.1#55872: query: extended.nau.edu IN A +ED (127.0.0.1)

Unbound resolves the record on the first try.

Aside from the missing DS, I don't see why BIND complains about the
NXDOMAIN response at first and then returns that cached record set in
response to later queries for the same name. dig +sigchase validates it,
if provided with the nau.edu DNSKEY:

> nau.edu.  86400   IN  SOA ns3.nau.edu. 
> DNS-Contact.nau.edu. 4779 1800 900 604800 86400
> nau.edu.  86400   IN  RRSIG   SOA 5 2 86400 20111030191258 
> 20110930181258 7485 nau.edu. 
> xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9 
> fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI 
> G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
> nau.edu.  86400   IN  NSEC_tcp.nau.edu. A NS SOA MX TXT 
> RRSIG NSEC DNSKEY TYPE65534
> nau.edu.  86400   IN  RRSIG   NSEC 5 2 86400 20111020001752 
> 20110919233312 7485 nau.edu. 
> GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP 
> /JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk 
> UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
> ewb.nau.edu.  86400   IN  NSECfacdevnet.nau.edu. CNAME RRSIG 
> NSEC
> ewb.nau.edu.  86400   IN  RRSIG   NSEC 5 3 86400 20111019222812 
> 20110919220129 7485 nau.edu. 
> SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U 
> VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV 
> 00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
> ;; Received 710 bytes from 134.114.96.4#53(134.114.96.4) in 189 ms



Hauke.



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