Re: Reasonable setup of a dnssec aware recursive resolver

2010-03-29 Thread Mark Elkins
On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote:
 I'm trying to come up with an interim solution for my ISP's DNS
 Recursive Resolver that is DNSSEC aware.
 
 My thoughts so far:-
 Use BIND 9.6.1-P3 (this is the latest version named that Gentoo Linux
 gives me).

Ouch! - bitten by the signing of ARPA
 /etc/bind/named.conf.trust:225: configuring trusted key for 'ARPA.':
algorithm is unsupported.
-and- 
* No specific action is requested of operators. This message is
* for your information only.
* The ARPA zone is about to be signed using DNSSEC. The technical
* parameters by which ARPA will be signed are as follows: 
* KSK Algorithm and Size: 2048 bit RSA

I thought unrecognised algorithms were meant to be ignored?
Time to try Bind 9.7.0-P1 ??

 In order to fetch both iTAR and DLV signatures - use a patched version
 of WGET that is dnssec aware.
 
 Once a week (is this frequent enough?) fetch the DNSSEC signatures from
 iTAR and ISC/DLV, convert the iTAR xml stuff into Signatures, append the
 DLV signature and then include this file into my named.conf
 configuration.
 (named.conf:   include named.conf.trust-anchors; )
 
 In named.conf -- options, add:
 dnssec-enable yes;
 dnssec-validation yes;
 dnssec-lookaside . trust-anchor dlv.isc.org.;
 
 This appears to be working for me.
 Questions are - how frequently should one fetch these trust-anchors? I'd
 have though once a week was enough but have read of situations where
 people using ISC's DLV have had past problems.
 
 I'm hoping that by using both iTAR and DLV - that I won't have this
 problem - have not noticed anything personally yet.
 
 I call this an interim solution - interim until the root is signed
 with live data and contains the data that ITAR is currently being used
 to store. I don't see ISC's DLV disappearing overnight just because the
 root is signed either...
 
 I'm only doing the 'wget-ting' from one location, then distributing
 internally from there - in order to reduce loads.
 
 What other suggestions do people have to achieve something similar?
 
 ps - I find the CZ DNSSEC Validator (addon) plugin to Firefox very
 inspiring! Anyone aware of something similar for IE?
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
  .  . ___. .__  Posix Systems - Sth Africa.  e.164 VOIP ready
 /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496


smime.p7s
Description: S/MIME cryptographic signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Reasonable setup of a dnssec aware recursive resolver

2010-03-29 Thread Mark Andrews

In message 1269885784.31597.68.ca...@mjenet.posix.co.za, Mark Elkins writes:
 On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote:
  I'm trying to come up with an interim solution for my ISP's DNS
  Recursive Resolver that is DNSSEC aware.
 =20
  My thoughts so far:-
  Use BIND 9.6.1-P3 (this is the latest version named that Gentoo Linux
  gives me).

You want to have newer if you are using DNSSEC.

 Ouch! - bitten by the signing of ARPA
  /etc/bind/named.conf.trust:225: configuring trusted key for 'ARPA.':
 algorithm is unsupported.
 -and-=20
 * No specific action is requested of operators. This message is
 * for your information only.
 * The ARPA zone is about to be signed using DNSSEC. The technical
 * parameters by which ARPA will be signed are as follows:=20
 * KSK Algorithm and Size: 2048 bit RSA
 
 I thought unrecognised algorithms were meant to be ignored?

Just don't blindly import trust anchors.  Zone with unknown algorithms
will be treated as insecure when you transition to them from a
secure zone by following a delegation where all the DS records are
for unknown algorithms.  However when you add a trust anchor you
are saying treat this zone as secure and here are your starting
points.

 Time to try Bind 9.7.0-P1 ??

BIND 9.6.2-P1 and BIND 9.7.0-P1 both support RSASHA256 and RSASHA512.

  In order to fetch both iTAR and DLV signatures - use a patched version
  of WGET that is dnssec aware.
 =20
  Once a week (is this frequent enough?) fetch the DNSSEC signatures from
  iTAR and ISC/DLV, convert the iTAR xml stuff into Signatures, append the
  DLV signature and then include this file into my named.conf
  configuration.
  (named.conf:   include named.conf.trust-anchors; )
 =20
  In named.conf -- options, add:
  dnssec-enable yes;
  dnssec-validation yes;
  dnssec-lookaside . trust-anchor dlv.isc.org.;
 =20
  This appears to be working for me.
  Questions are - how frequently should one fetch these trust-anchors? I'd
  have though once a week was enough but have read of situations where
  people using ISC's DLV have had past problems.
 =20
  I'm hoping that by using both iTAR and DLV - that I won't have this
  problem - have not noticed anything personally yet.

ITAR is already imported into DLV.  You really don't want to have lots
of trust anchors in named.conf.  Just more places to go wrong.  A the
root when it is signed however.

 =20
  I call this an interim solution - interim until the root is signed
  with live data and contains the data that ITAR is currently being used
  to store. I don't see ISC's DLV disappearing overnight just because the
  root is signed either...
 =20
  I'm only doing the 'wget-ting' from one location, then distributing
  internally from there - in order to reduce loads.
 =20
  What other suggestions do people have to achieve something similar?
 =20
  ps - I find the CZ DNSSEC Validator (addon) plugin to Firefox very
  inspiring! Anyone aware of something similar for IE?
 =20
  ___
  bind-users mailing list
  bind-users@lists.isc.org
  https://lists.isc.org/mailman/listinfo/bind-users
 --=20
   .  . ___. .__  Posix Systems - Sth Africa.  e.164 VOIP ready
  /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
 / |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496
 
 --=-zyQOFLsrjw8nMxXVg+CV
 Content-Type: application/x-pkcs7-signature; name=smime.p7s
 Content-Disposition: attachment; filename=smime.p7s
 Content-Transfer-Encoding: base64
 
 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWfjCCB0gw
 ggYwoAMCAQICAgLSMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
 cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
 HhcNMDkxMDMxMDAwMDAxWhcNMTExMDMxMTU0MTEwWjCBujELMAkGA1UEBhMCWkExEDAOBgNVBAgT
 B0dhdXRlbmcxETAPBgNVBAcTCFByZXRvcmlhMSEwHwYDVQQKExhQb3NpeCBTeXN0ZW1zIChQVFkp
 IEx0ZC4xLTArBgNVBAsTJFN0YXJ0Q29tIFZlcmlmaWVkIENlcnRpZmljYXRlIE1lbWJlcjEUMBIG
 A1UEAxMLTWFyayBFbGtpbnMxHjAcBgkqhkiG9w0BCQEWD21qZUBwb3NpeC5jby56YTCCASIwDQYJ
 KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6KS+4WC5M29OOVGAcVUn/z90w4aoMidneOPY16Bnuo
 6V+8C4kcZrVKoyIYRG55Uln2lKRHeSAhPNBTSMRkkQ1kGNSnmH5jCPhdL+VBN1+CAWeiPvblnsX+
 5wOoEM6v/i2FdBcsdMmssYnG7WFhn4BsyFQe0bQgDNHgbbnJbSMFCaiqAICoQljL0ha/Z3SU+Dgz
 2IKTo5fe8vN9P6z5QsETqeBgmsLET+MhwnQ8CRNYhq3vjrYqqie31COgE28Cn5+ez08MDnULB/5I
 cQFzZ5g1ORtaLrRg6VYHITnMn0EedOb9+iz/WF/nstqVwrKlJsp1hGsOeTjqCoOq6ASH3McCAwEA
 AaOCA4IwggN+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
 BgEFBQcDBDAdBgNVHQ4EFgQUFPCcDnQQWUlHl8TRFshEBYXoA6IwgagGA1UdIwSBoDCBnYAUrlWD
 b+wxyrn3HfqvazHzyB3jrLuhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
 THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE
 AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ4wGgYDVR0RBBMwEYEPbWplQHBv