Re: stub zone and dnssec processing fails?

2009-10-01 Thread Paul Wouters

On Fri, 2 Oct 2009, Mark Andrews wrote:


zone "ca." IN {
 type stub;
 masters { 192.228.22.190; 192.228.22.189; };
};



To make the test signed ca work you need to replace the NS RRet
with the names of the nameservers that serve the signed CA zone.
At the moment you end up with those that server unsigned content
which is correctly rejected.  Stubs pre-populate the delegation,
they do not override the delegation.


It seems that using a forward type zone does work:

zone "ca." IN {
type forward;
forwarders { 66.241.135.248; 193.110.157.136; };
};

 dig +dnssec -t ds xelerance.ca. @localhost

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 12, ADDITIONAL: 1

I had tried it before and it failed. Must have been an operator error.

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


Re: stub zone and dnssec processing fails?

2009-10-01 Thread Mark Andrews

In message , Paul Wou
ters writes:
> 
> Hi,
> 
> I've been trying to configure bind to use a stub zone, for which I
> have keys configured. When I do this, I see a ServFail, with the
> logs pointing to:
> 
> 01-Oct-2009 11:00:03.053 lame-servers: info: not insecure resolving 'xeleranc
> e.ca/DNSKEY/IN': 193.110.157.135#53
> 
> 
> When I disable the trusted-keys {} for this zone, the resolving
> works, but then it seems to ignore the stub and go out via the
> regular path
> 
> Enabling/disabling DLV did not make a difference. The relevant parts of
> the named.conf:
> 
> options {
>  dnssec-enable yes;
>  dnssec-validation yes;
>  // dnssec-lookaside . trust-anchor dlv.isc.org.;
>   recursion yes;
> };
> 
> zone "ca." IN {
>  type stub;
>  masters { 192.228.22.190; 192.228.22.189; };
> };
> 
> trusted-keys {
> "ca." 257  3  7 "AwEAAbTcBX0/Z6uh4gUFmPhNMExALpP8eVy+KyHQ3IY8z/XlDoRVoe2Cv0IX
> BWp
> MFme3sQpAEGg9Ps1+lYXpn2zO0BfpcED2nVlZ9KFBwh1MuEHvaAAkYKZtT/aqOIDJftRdmU8ClFZg
> aeJ
> c8Scvf5boGczVvG/ZdbDpHVM73x6a4rQqjTDlgwSaNU+/vimOWii5d4lWBxUDQKsqkQ27UGqyGtYQ
> xNY
> giRGx80phZkmhxOnSwfXIG/RJa0Hl6CtlsG3klywJ+7NAZM/n8Y0TQqjOHudC0SedXSCmQ0C/Ds0Q
> X5M
> 7c/S7alVBYsOdHhJF05MaIA5ij0thAmuvJUW7ofqO5ec=" ; // key id = 46215
> };
> 
> Paul
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

To make the test signed ca work you need to replace the NS RRet
with the names of the nameservers that serve the signed CA zone.
At the moment you end up with those that server unsigned content
which is correctly rejected.  Stubs pre-populate the delegation,
they do not override the delegation.

The alternative is to override the addresses for ?.ca-servers.ca
with those of servers that serve the signed version of ca.  You
will also need to ensure that these servers serve the zones that
are othewise delgated to them using these names. You will still get
the odd failure due to talking to ns-ext.isc.org.

You could just override these if you can't get the content of
ca-servers.ca as ca-servers.ca is delegated to [a-f].ca-servers.ca.
You will get more failures however.

ca. 86400   IN  NS  j.ca-servers.ca.
ca. 86400   IN  NS  k.ca-servers.ca.
ca. 86400   IN  NS  l.ca-servers.ca.
ca. 86400   IN  NS  m.ca-servers.ca.

I use a similar technique to test IPv6 connectivity for the root
servers.

Mark

; <<>> DiG 9.3.6-P1 <<>> ca ns +norec @192.228.22.190
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56860
;; flags: qr aa; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ca.IN  NS

;; ANSWER SECTION:
ca. 86400   IN  NS  e.ca-servers.ca.
ca. 86400   IN  NS  d.ca-servers.ca.
ca. 86400   IN  NS  l.ca-servers.ca.
ca. 86400   IN  NS  c.ca-servers.ca.
ca. 86400   IN  NS  a.ca-servers.ca.
ca. 86400   IN  NS  b.ca-servers.ca.
ca. 86400   IN  NS  k.ca-servers.ca.
ca. 86400   IN  NS  f.ca-servers.ca.
ca. 86400   IN  NS  ns-ext.isc.org.
ca. 86400   IN  NS  m.ca-servers.ca.
ca. 86400   IN  NS  j.ca-servers.ca.

;; Query time: 251 msec
;; SERVER: 192.228.22.190#53(192.228.22.190)
;; WHEN: Fri Oct  2 10:36:50 2009
;; MSG SIZE  rcvd: 219


; <<>> DiG 9.3.6-P1 <<>> +dnssec ca @ns-ext.isc.org.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36584
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
ca. 3600IN  SOA jbq01.tor.cira.ca. 
admin-dns.cira.ca. 2009100120 1800 900 604800 3600

;; Query time: 168 msec
;; SERVER: 2001:4f8:0:2::13#53(2001:4f8:0:2::13)
;; WHEN: Fri Oct  2 10:43:20 2009
;; MSG SIZE  rcvd: 92

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


stub zone and dnssec processing fails?

2009-10-01 Thread Paul Wouters


Hi,

I've been trying to configure bind to use a stub zone, for which I
have keys configured. When I do this, I see a ServFail, with the
logs pointing to:

01-Oct-2009 11:00:03.053 lame-servers: info: not insecure resolving 
'xelerance.ca/DNSKEY/IN': 193.110.157.135#53


When I disable the trusted-keys {} for this zone, the resolving
works, but then it seems to ignore the stub and go out via the
regular path


Enabling/disabling DLV did not make a difference. The relevant parts of
the named.conf:

options {
dnssec-enable yes;
dnssec-validation yes;
// dnssec-lookaside . trust-anchor dlv.isc.org.;
recursion yes;
};

zone "ca." IN {
type stub;
masters { 192.228.22.190; 192.228.22.189; };
};

trusted-keys {
"ca." 257  3  7 "AwEAAbTcBX0/Z6uh4gUFmPhNMExALpP8eVy+KyHQ3IY8z/XlDoRVoe2Cv0IXBWp
MFme3sQpAEGg9Ps1+lYXpn2zO0BfpcED2nVlZ9KFBwh1MuEHvaAAkYKZtT/aqOIDJftRdmU8ClFZgaeJ
c8Scvf5boGczVvG/ZdbDpHVM73x6a4rQqjTDlgwSaNU+/vimOWii5d4lWBxUDQKsqkQ27UGqyGtYQxNY
giRGx80phZkmhxOnSwfXIG/RJa0Hl6CtlsG3klywJ+7NAZM/n8Y0TQqjOHudC0SedXSCmQ0C/Ds0QX5M
7c/S7alVBYsOdHhJF05MaIA5ij0thAmuvJUW7ofqO5ec=" ; // key id = 46215
};

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