Re: Akadns and Bind

2011-02-04 Thread Kalman Feher



On 4/02/11 3:07 AM, Tory M Blue tmb...@gmail.com wrote:

 On Thu, Feb 3, 2011 at 5:23 PM, Barry Margolin bar...@alum.mit.edu wrote:
 In article mailman.1636.1296781581.555.bind-
 SNIPPED
 www.yahoo.com.    300   IN CNAME fp.wg1.b.yahoo.com.
 
 And even when they did, it didn't get involved until you followed the
 CNAME returned for www.yahoo.com.  Your log message above indicates an
 issue just with the yahoo.com domain, not resolution of the CNAME target.
 
 --
 Thanks Barry so maybe I need some further education
 
 
 [tblue@mx3 ~]$ dig @problemserver.net  www.yahoo.com
 
 ;  DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12  @problemserver.net
 www.yahoo.com
 ; (1 server found)
 ;; global options: +cmd
 ;; connection timed out; no servers could be reached
 
What does the log entry say for the above query? Do you reach the
problemserver from your client?
 So let's add the trace option (Same servers)
 
 [tblue@mx3 ~]$ dig @problemserver.net  www.yahoo.com  +trace
IIRC +trace will ignore @nameserver target and look queries up directly to
the root on down. So you may have been mislead with the test below.
 
 ;  DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12  @problemserver.net
 www.yahoo.com +trace
 ; (1 server found)
 ;; global options: +cmd
 .   514246 IN NS f.root-servers.net.
 .   514246 IN NS b.root-servers.net.
 .   514246 IN NS e.root-servers.net.
 .   514246 IN NS a.root-servers.net.
 .   514246 IN NS l.root-servers.net.
 .   514246 IN NS k.root-servers.net.
 .   514246 IN NS i.root-servers.net.
 .   514246 IN NS d.root-servers.net.
 .   514246 IN NS c.root-servers.net.
 .   514246 IN NS m.root-servers.net.
 .   514246 IN NS j.root-servers.net.
 .   514246 IN NS h.root-servers.net.
 .   514246 IN NS g.root-servers.net.
 ;; Received 336 bytes from 10.13.255.101#53(10.13.255.101) in 1 ms
 
 com.   172800 IN NS a.gtld-servers.net.
 com.   172800 IN NS b.gtld-servers.net.
 com.   172800 IN NS c.gtld-servers.net.
 com.   172800 IN NS d.gtld-servers.net.
 com.   172800 IN NS e.gtld-servers.net.
 com.   172800 IN NS f.gtld-servers.net.
 com.   172800 IN NS g.gtld-servers.net.
 com.   172800 IN NS h.gtld-servers.net.
 com.   172800 IN NS i.gtld-servers.net.
 com.   172800 IN NS j.gtld-servers.net.
 com.   172800 IN NS k.gtld-servers.net.
 com.   172800 IN NS l.gtld-servers.net.
 com.   172800 IN NS m.gtld-servers.net.
 ;; Received 494 bytes from 199.7.83.42#53(l.root-servers.net) in 11 ms
 
 yahoo.com.  172800 IN NS ns1.yahoo.com.
 yahoo.com.  172800 IN NS ns5.yahoo.com.
 yahoo.com.  172800 IN NS ns2.yahoo.com.
 yahoo.com.  172800 IN NS ns3.yahoo.com.
 yahoo.com.  172800 IN NS ns4.yahoo.com.
 ;; Received 201 bytes from 192.31.80.30#53(d.gtld-servers.net) in 55 ms
 
 www.yahoo.com.  300 IN CNAME fp.wg1.b.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf2.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf4.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf8.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf3.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf6.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf5.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf1.yahoo.com.
 wg1.b.yahoo.com. 300 IN NS yf7.yahoo.com.
 ;; Received 326 bytes from 68.180.131.16#53(ns1.yahoo.com) in 2 ms
 
 
 So what am I missing? No servers available and the trace shows that
 it's finding the CNAME record, but doesn't appear to be going far
 enough,
 
 
 Here is the second server who can resolve this. Identical
 configuration as the problem server, same network segment, behind same
 SNAT, the same..
 
 [tblue@mx3 ~]$ dig @functioningserver.net  www.yahoo.com
 
 ;  DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12  @functioningserver.net
 www.yahoo.com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 30158
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.yahoo.com.   IN A
 
 ;; ANSWER SECTION:
 www.yahoo.com.  300 IN CNAME fp.wg1.b.yahoo.com.
 fp.wg1.b.yahoo.com. 3238 IN CNAME any-fp.wa1.b.yahoo.com.
 any-fp.wa1.b.yahoo.com. 60 IN A 98.137.149.56
 any-fp.wa1.b.yahoo.com. 60 IN A 72.30.2.43
 
 ;; AUTHORITY SECTION:
 wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com.
 wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com.
 
 ;; Query time: 1759 msec
 ;; SERVER: 10.13.255.102#53(10.13.255.102)
 ;; WHEN: Thu Feb  3 18:03:55 2011
 ;; MSG SIZE  rcvd: 147
That's a small message size so the EDNS entry in your earlier email may be a
red herring, but just to be sure why not try the following on the server
that fails the lookup?
dig +tcp www.yahoo.com @yf2.yahoo.com.

I'd also recommend a sanity check on your loadbalancing set up. Are both
active in the pool? Have you set up NAT out bound as well as in bound on the
VIP? Remembering that UDP can be handled differently through load balancers
than TCP.
 
 I'm missing something I'm sure, but it's under my skin now!
 
 Thanks again
 Tory
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 


Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-26 Thread Kalman Feher



On 25/01/11 11:20 PM, Mark Andrews ma...@isc.org wrote:

 
 In message c964b3cd.13a61%kalman.fe...@melbourneit.com.au, Kalman Feher
 write
 s:
 
 
 
 On 25/01/11 4:10 PM, Alan Clegg acl...@isc.org wrote:
 
 On 1/25/2011 9:51 AM, Kalman Feher wrote:
 
 If the nsec3param has been removed, the automated signing will be weird if
 you are using nsec3 keys. I havent tested this scenario, since it isnt
 really a working scenario.
 
 There is no such thing as an nsec3 key.
 Sorry, I was a little sloppy with my vernacular.
 I meant the algorithm used to create the keys in question. ie using -3 in
 dnssec-keygen. 
 
 And *all* keys that support NSEC3 are also NSEC capable.  There
 isn't such a thing as a NSEC3 key.  There are NSEC3 capable keys
 and keys that are not NSEC3 capable.  All keys are NSEC capable.
I don't think this was in question. But it is always useful to have it
explicitly stated. Though hopefully this wont muddy the waters, since it is
the complete opposite of what OP was trying to do.


 
 As for the NSEC3PARAM going away it is only supposed to exist in a
 *signed* zone and you are attempting to add it to a unsigned zone.
Good point. However I note that it definitely _does_ work when added to an
unsigned zone, which following an rndc sign, (with caveats of appropriately
created keys ) will result in an nsec3 signed zone. This is also the
workflow documented in Alan's nanog presentation (the slide titled Create 
Sign (NSEC3)). 

If that isn't ideal, it would be useful to know why. And also why it does
work for now. Does it only work when done in rapid succession?

 
 The key timing are there for managing keys in a already signed zone.
 You are attempting to use them to start signing the zone which
 requires as whole different set of steps to be done.
 
 To get named to convert a unsigned zone to a signed zone with NSEC3
 use nsupdate to add the DNSKEYs and NSEC3PARAM record in the same
 UPDATE request.

 
 If you auto-sign a zone that does not contain an NSEC3PARAM record, the
 zone will be signed using NSEC.
 That was the observed behaviour of the OP, which wasn't their preference.
 Hence the need to add and retain said nsec3param in this instance.
 
 
 [note that I'm leaving the rest of that mail to be responded to by
 someone with more intimate knowledge of the auto-signing mechanism]
I believe this was the original issue with OP. There seemed to be a
misunderstanding of the purpose of the activate value. Specifically,
expecting that the zone would automatically sign updates (the DS in this
case) prior to the activate time.
 
 AlanC
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
 
 -- 
 Kal Feher 
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-25 Thread Kalman Feher



On 25/01/11 2:34 PM, Zbigniew Jasiński szo...@nask.pl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 W dniu 2011-01-24 17:47, Kalman Feher pisze:
 This appears to be the problem.
 I copied your NSEC3PARAM (opt out clear, 12 iterations) details but could
 not replicate it. Try turning up the logging to get more information about
 why the nsec3param is removed. Make sure also that your keys are nsec3
 compatible and you don't have any old non nsec3 keys in the directory that
 could be used to sign.
 
 
 I was trying to reproduce your scheme:
 
 FWIW I use a script to add all my test zones from a zone template
 file. That
 script automatically adds the nsec3param as soon as the zone is
 loaded, but
 before it signs. That way I keep things simple and never forget to update
 that zone before signing.
 
 but without success. did you use keys with future Prepublish and
 Activate or it's set to NOW?
 
 I made few tests:
 
 - -- first scenario (desirable):
 
 1. get unsigned zone
 2. generate nsec3 compatible keys (Prepublish and Activate in the future)
 3. send 'rndc sign' to named
 4. send NSEC3PARAM via dynamic update
If you swap steps 3 and 4 you'll be ok. That is assuming your sign is issued
at the point in future after your activate date (activate saying that the
key should now be used to sign rather than just be present for caching).
Done in that order, my test worked fine, including DS signing whenever a DS
was added (along with any other new record).
 
 result:
 
 after waiting until key Activate event:
 
 1. SOA and DNSKEY records are signed and have RRSIG records
 2. NSEC3PARAM and DS records are still unsigned
This is symptomatic of the broken automatic signing. I suspect any new
record would not be signed. Give it a try just in case.
 
 which is not proper signed zone.
 
 - -- second scenario:
 
 1. get unsigned zone with NSEC3PARAM record
 2. generate nsec3 compatible keys (Prepublish and Activate in the future)
 3. send 'rndc sign' to named
 
 result:
 
 1. NSEC3PARAM is immediately removed from zone
If you issue sign before the key is active, you're not going to be able to
sign properly. I'm not sure why nsec3param is removed, but it probably is
due to the aborted automated signing.
 
 after waiting until key Activate event:
 
 1. SOA and DNSKEY records are signed and have RRSIG records but in zone
 file. can't get RRSIG records with dns response. only if I send query
 for RRSIG records
If the nsec3param has been removed, the automated signing will be weird if
you are using nsec3 keys. I havent tested this scenario, since it isnt
really a working scenario.
 
 - -- third scenario:
 
 1. get unsigned zone
 2. generate nsec3 compatible keys (Prepublish and Activate = NOW)
 3. send NSEC3PARAM via dynamic update
 4. send 'rndc sign' to named
 
 result:
 
 everything is ok.
 
 one conclusion: you need to have at least one key in Activate state. as
 for me this is wrong assumption. first scenario should be ok but strange
 things happened after Activate event or I made a mistake.
Yes this is the correct scenario. Activate is when you plan on using that
key to sign. Issuing sign without an active key doesn't really make sense.
Noting of course that the meta data is only used by the automated signing
logic within BIND. So you can always use any key to sign manually. However I
think this may have mislead you regarding the purpose of the meta data.

The best way to think of keys in DNSSEC is in groups of threes.
Keys in the past, keys in the future and keys in the present.

Keys in the past don't matter for your first signing.

Keys in the present are used for signing _right now_. That means they need
to be active and published.

Keys in the future will be used to sign, so they should ideally be published
before hand. You may also need to apply some parent publishing logic (has my
registry accepted my DS, has it published in the parent zone) for the exact
time difference between publish and activate. Most organisations simply
leave a large gap (a month or two) between publish and activate for KSKs as
a result. 

With that in mind, your first time signing should be:
1.Create nsec3 compatible keys. Ideally a pair for now and a pair for the
future (the future pair can wait however).
-Personally my now keys are actually set as active and publish in the
past. 
-My future keys are created on a set schedule with publish dates a few days
before their active dates (this is the test system, production systems need
longer times).
2.If zone is not already locally dynamically managed, do so now.

3.NSEC3PARAM is added

4.Sign is issued for the first and last time (if you are using maintain).
-The active keys are used to sign and will continue to be used until they
are no longer active.
-Key directory will be checked as key events approach and keys will be
published and made active according to their meta data. For the exact timing
around this check the BIND ARM for 9.7 which has an explanation

Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-25 Thread Kalman Feher



On 25/01/11 4:10 PM, Alan Clegg acl...@isc.org wrote:

 On 1/25/2011 9:51 AM, Kalman Feher wrote:
 
 If the nsec3param has been removed, the automated signing will be weird if
 you are using nsec3 keys. I havent tested this scenario, since it isnt
 really a working scenario.
 
 There is no such thing as an nsec3 key.
Sorry, I was a little sloppy with my vernacular.
I meant the algorithm used to create the keys in question. ie using -3 in
dnssec-keygen. 



 
 If you auto-sign a zone that does not contain an NSEC3PARAM record, the
 zone will be signed using NSEC.
That was the observed behaviour of the OP, which wasn't their preference.
Hence the need to add and retain said nsec3param in this instance.

 
 [note that I'm leaving the rest of that mail to be responded to by
 someone with more intimate knowledge of the auto-signing mechanism]
 
 AlanC
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-24 Thread Kalman Feher



On 24/01/11 10:53 AM, Zbigniew Jasiński szo...@nask.pl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 W dniu 2011-01-21 15:17, Kalman Feher pisze:
 Perhaps we are getting close to the problem then.
 Can you show the content of the key files? Specifically the metadata which
 the maintain option wants.
 
 Since allow works I'm assuming that key file permissions (and directory
 permissions) are ok, but it couldn't hurt to check them.
 
 I've made new instalation without SoftHSM support to be sure that this
 is not an issue, and of course 'allow' works and 'maintain' the same odd
 things.
 
 permissions are ok, double-checked, and with 'allow' it works.
 
 key metadata, same for ZSK and KSK:
 
 ; Created: 20110121145849 (Fri Jan 21 15:58:49 2011)
 ; Publish: 20110121145937 (Fri Jan 21 15:59:37 2011)
 ; Activate: 20110121170117 (Fri Jan 21 18:01:17 2011)
 ; Inactive: 20110121220937 (Fri Jan 21 23:09:37 2011)
 ; Delete: 20110122001117 (Sat Jan 22 01:11:17 2011)
 
 and of course I'm waiting until Activate key event to be sure I will get
 RRSIG in response but there's now signatures.
 
 strange thing, that after signing zone with 'maintain' and after named
 dumps zone into plain file, file differs from this dumped with 'allow'
 option, much. for example don't have NSEC3PARAM in file from 'maintain'
 and DS record (authoritative) doesn't have even it's signature!
I assume you did add the nsec3param record via nsupdate after adding the
zone? I note that there is an NSEC entry there, which is not right.


 
 zone with 'maintain' option:
 
 $ORIGIN .
 $TTL 3600   ; 1 hour
 example  IN SOA  ns1.example. bugs.x.w.example. (
 1292481918 ; serial
 7200   ; refresh (2 hours)
 3600   ; retry (1 hour)
 734400 ; expire (1 week 1 day 12 hours)
 600; minimum (10 minutes)
 )
 RRSIG   SOA 10 1 3600 20110223093216 (
 20110124083216 41870 example.
   SbFalU9K5yroRNtENT7nQHovxOXhl8ROOi90D77qFEXc
 CUT
 NS  ns1.example.
 NS  ns2.example.
 TXT dnssec test
 $TTL 600; 10 minutes
 NSECa.example. NS SOA TXT RRSIG NSEC DNSKEY
 TYPE65534
 $TTL 3600   ; 1 hour
 DNSKEY  256 3 10 (
 AwEAAdByffBxPaxGFxfnf10TKUIwUKvq79vfMJ9wGW6s
 CUT) ; key id = 41870
 DNSKEY  257 3 10 (
 AwEAAdFituIkCms1lVbht+ykmwRUoBQJjHW9qep2GS1O
 CUT ) ; key id = 996
 RRSIG   DNSKEY 10 1 3600 20110223093216 (
 20110124083216 996 example.
 LXfYVMI7BuQEEvYKpiadeboBHlv1RYv1vaaUoZLwnhC6
 RRSIG   DNSKEY 10 1 3600 20110223093216 (
 20110124083216 41870 example.
 $TTL 0  ; 0 seconds
 TYPE65534 \# 5 ( 0A03E40001 )
 TYPE65534 \# 5 ( 0AA38E0001 )
 $ORIGIN example.
 $TTL 3600   ; 1 hour
 a   NS  ns1.a
 NS  ns2.a
 DS  23344 5 1 (
 CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56 )
 $ORIGIN a.example.
 ns1 A   127.0.0.1
 ns2 A   127.0.0.1
 $ORIGIN example.
 ai  A   127.0.0.1
 ::1
 c   NS  ns1.c
 NS  ns2.c
 $ORIGIN c.example.
 ns1 A   127.0.0.5
 ns2 A   127.0.0.6
 $ORIGIN example.
 ns1 A   127.0.0.3
 ns2 A   127.0.0.4
 w   A   127.0.0.1
 $ORIGIN w.example.
 *   MX  10 ai.example.
 x   MX  10 xx.example.
 x.y MX  10 xx.example.
 $ORIGIN example.
 xx  A   127.0.0.1
 ::1
 - -- 
I cut and paste the zone (except for DS) and loaded it, added nsec3param,
then signed and it went perfectly.
I then added an a.example zone and did the same thing.
I took the resulting dsset and added it into example using nsupdate and it
was signed within moments.

Are you following this same workflow?
FWIW I use a script to add all my test zones from a zone template file. That
script automatically adds the nsec3param as soon as the zone is loaded, but
before it signs. That way I keep things simple and never forget to update
that zone before signing.

 regards

Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-24 Thread Kalman Feher



On 24/01/11 4:08 PM, Zbigniew Jasiński szo...@nask.pl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 W dniu 2011-01-24 14:34, Kalman Feher pisze:
 I assume you did add the nsec3param record via nsupdate after adding the
 zone? I note that there is an NSEC entry there, which is not right.
 
 
 Yes, with nsupdate. and lack of NSEC3PARAM was very odd.
 
 Are you following this same workflow?
 FWIW I use a script to add all my test zones from a zone template file. That
 script automatically adds the nsec3param as soon as the zone is loaded, but
 before it signs. That way I keep things simple and never forget to update
 that zone before signing.
 
 I made few more tests and what I've understand you have to have at least
 one key in 'Activate' state.
 
 for example:
 
 the same example zone, generated keys with future Prepublish and
 Activate event, adding NSEC3PARAM via nsupdate:
 
 Jan 24 15:28:36 named[15837]: update: client 127.0.0.1#8917: updating
 zone 'example/IN': adding an RR at 'example' NSEC3PARAM
 Jan 24 15:28:36 named[15837]: general: zone example/IN:
 dns_zone_addnsec3chain(hash=1, iterations=12, salt=19CC44675CFB020065B1)
 Jan 24 15:28:36 named[15837]: general: zone example/IN:
 zone_addnsec3chain(1,CREATE,12,19CC44675CFB020065B1)
 
 now I want named to read the key timings from key files so I make 'rndc
 sign example':
 
 Jan 24 15:28:37 named[15837]: general: received control channel command
 'sign example'
 Jan 24 15:28:37 named[15837]: general: zone example/IN: reconfiguring
 zone keys
 Jan 24 15:28:37 named[15837]: general: zone example/IN:
 zone_addnsec3chain(1,REMOVE|NONSEC,12,19CC44675CFB020065B1)
This appears to be the problem.
I copied your NSEC3PARAM (opt out clear, 12 iterations) details but could
not replicate it. Try turning up the logging to get more information about
why the nsec3param is removed. Make sure also that your keys are nsec3
compatible and you don't have any old non nsec3 keys in the directory that
could be used to sign.

 Jan 24 15:28:37 named[15837]: general: zone example/IN: next key event:
 24-Jan-2011 15:29:36.860
 Jan 24 15:29:36 named[15837]: general: zone example/IN: reconfiguring
 zone keys
 Jan 24 15:29:36 named[15837]: general: zone example/IN: next key event:
 24-Jan-2011 16:29:36.886
 
 and my NSEC3PARAM record is removed! and my question is why? why can't I
 have NSEC3PARAM record in my zone before signing it??
 
 If I wait until 'Activate' event (16:29:36.886 - for this particular
 test) I will get strangely looking signed zone (which I attached in my
 previous emails) without my NSEC3PARAM record.
 
 - -- 
 regards
 
 zbigniew jasinski
 [SYStem OPerator]
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJNPZXVAAoJEH26UYiRhe/gPDwP/2kxlk5ct9hpffP94tAUgx/F
 R61tr9IA1mSAkHkN6zJh7GYRgNSxllI4s+h41FXYBhlknpARdcobfm2ybdkReojm
 llaTIQtqcgh+7vRq/MK9zH3MwWglhatuQFENUwTpy38zccRwSAQhtN+XDUi2TpVq
 VS0tjpAqZb0/hpz9pb4Bxu1uNzpRUehiRcjhg0l2ocsBg/32FQ4xSDr3ViMNHgeA
 0a+xIRkp9gK5DsUUCPlpkQBBr7ICyvl/M4t3RPUOr3zf7tzUX81TrNLF1PeHC/kh
 gR8Hz+94MceVdgVIaRNWUpj5wvYVRuz9DEdp9li124kk4hyATh+Qo1Bk1ZrreoNa
 AxqO/qVqtRz7xpRSdjvOcsNrJ7/5dJltfp/Mv7wC0xXgz/DR84xiFvpy21JAEJIa
 W0D7lCSixF3B8WV90vKevJGSCWSi0ipLANuckO4oHzhTyVk0RQmV/iGZjneWwJpV
 KJWuTSa1sffk2QXI3ikwH5WKLyKaXmOCG5ZkEmLc8OO70WSkuWlsbt2oGGRAgGVd
 b8uYtr6NrJdJBhAU5KgcEHiOY6g9Wv6ffC63XS1LMC9b/Tnp5DXHnK8VG5og6NwO
 vjgJu5SwyuijAl+VIWlnnenxNBy4vB4OSrht0sC+JvzN360/sSSLE3fzHpFwMTGq
 D1zWmxkyD645F6od2RJ/
 =iWfG
 -END PGP SIGNATURE-
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-21 Thread Kalman Feher
The only way I can replicate the behaviour is with dnssec-enable no or with
an unsigned version of the zone in another view. Assuming you've not
overlapped your views in such a way (it was a very contrived test), I think
you'll need to provide a bit more information on your configuration.

-options
-relevant view statement
-The zone statement (from the hashed file if you are using the new dynamic
zones feature).
-The zone itself
-Query logs. 

Without the full dig output it is hard to see what is actually happening.
I'd suggest including that as well.

If you dig axfr or dig rrsig are the signatures present?



On 21/01/11 9:13 AM, Zbigniew Jasiński szo...@nask.pl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 W dniu 2011-01-19 18:38, Hauke Lampe pisze:
 
 Another thing you might check:
 
 With dnssec-enable no; in named.conf, BIND still does its automatic
 DNSSEC signing but won't add RRSIG to responses.
 
 I ran across such a configuration lately. Your problem sounds similar.
 
 
 Hauke.
 
 that was first thing which I've checked:
 
 dnssec-enable yes;
 
 and it's of course enabled.
 
 I see in journal file:
 
 ./sbin/named-journalprint var/zone/example.jnl
 
 add example. 3600IN  RRSIG   DNSKEY 10 1 3600
 20110218225336 20110119215336 57635 example.
 Xo9o137Q4BmELA0wumTLujJkHq0b/tDbYvuFCfZDfcbp8cuutDJUxCPy
 CUT
 add example. 3600IN  RRSIG   DNSKEY 10 1 3600
 20110218225336 20110119215336 57636 example.
 SfFa5xjRtb/VBm3Zv1j31VRlqJORM0laX1PuZ+Asi6IFutH4q5TeknYN
 CUT
 add example. 3600IN  RRSIG   SOA 10 1 3600
 20110218225336 20110119215336 57635 example.
 wYZ/nZbnN6HGrWTDLkfbyW4dQGMVs1ZVY+r8zc9t92ykxu7ipycxnITW
 CUT
 
 also RRSIG for SOA record and for DNSKEY records are present in plain
 zone file but still named isn't responding with correct signatures.
 
 - -- 
 regards
 
 zbigniew jasinski
 [SYStem OPerator]
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJNOUAtAAoJEH26UYiRhe/goMcP/i5MLxBFh8+Fl2R2oqIKdRR1
 ntBcfXBK1niJmlDpFzGu97gXNxoofk/bWVEhb+eo/e4+ln8bSuOiKVV5PQJ8zq1t
 ke5jCIw7iRdBQgMcZNHQCWcI1lCWnPc0SxcCtw6u2ZItfFxqwANwFJw0oXwX/C8i
 iVGflBdSUI9G/MGIaCsiwBdNBZnVhgrVz5F3KHXKC6aH49HI9kieXqz8v9pczcGR
 xoy/RRrgObvb8N4jz2GA+fq8thFoKzZkoWLWG/5eE9uYd8oY3wLHIoAt0jBfGXOR
 UXrFQ1QDqjUdotb3ovUGH2NH1NpWnITYm9gDWqEo3egaLpQU6itc2z57BNkuIkPS
 qn3m2rgnEKy+p6flLYNxwyYnrXWVIpti73r+aPpkWQpWptEBcyCIl2su6yLZPv1y
 R7ioFCualJLOWWqio9w5hQeRUvgrF6w7XBc97PMWgwLSrjHF0XADOWn9IqB4/XgA
 agPSo7p8D6mmfpnv9c+q1JVIUEhEqihNs5/c1/dhRRn4SRIucvvzuVlXB/gqVQep
 i+Ft2Tq3zgepBOxLGtZQ22o7VoBSWj8tHT6qRDG9qChsOXE054eN+r8xNbJ4rRzu
 oASw1n11vm0JAqceMeadCc0Zz2y4WbIJO7jEsPTp9KUHPNwbDmNnMH7pWyHvxS4v
 oZD7PbxPnyDpwRerG7zh
 =Sp+3
 -END PGP SIGNATURE-
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-21 Thread Kalman Feher



On 21/01/11 2:05 PM, Zbigniew Jasiński szo...@nask.pl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 W dniu 2011-01-21 11:23, Kalman Feher pisze:
 The only way I can replicate the behaviour is with dnssec-enable no or with
 an unsigned version of the zone in another view. Assuming you've not
 overlapped your views in such a way (it was a very contrived test), I think
 you'll need to provide a bit more information on your configuration.
 
 -options
 -relevant view statement
 -The zone statement (from the hashed file if you are using the new dynamic
 zones feature).
 -The zone itself
 -Query logs. 
 
 Without the full dig output it is hard to see what is actually happening.
 I'd suggest including that as well.
 
 If you dig axfr or dig rrsig are the signatures present?
 
 
 I've conducted test with 'auto-dnssec allow' and that works without any
 single problem, than I just change this options to 'auto-dnssec
 maintain' and odd things happen.
 
Perhaps we are getting close to the problem then.
Can you show the content of the key files? Specifically the metadata which
the maintain option wants.

Since allow works I'm assuming that key file permissions (and directory
permissions) are ok, but it couldn't hurt to check them.
 Didn't mentioned before but this named is working with SoftHSM. But like
 I said no problems with 'auto-dnssec allow'.
 
 this is zone conf:
 
 zone example {
 type master;
 file var/zone/example;
 allow-update { loopback; };
 allow-transfer { trusted; loopback; };
 auto-dnssec maintain;
 key-directory var/keys/example;
 };
 
 named.conf:
 
 controls {
 inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
 inet ::1 port 953 allow { ::1; } keys { rndc-key; };
 };
 
 acl trusted {
 127.0.0.1;
 172.16.7.5;
 };
 
 acl loopback {
 127.0.0.1;
 };
 
 acl eth0 {
 172.16.7.5;
 };
 
 options {
 directory /;
 query-source address 172.16.7.5;
 notify-source 172.16.7.5;
 transfer-source 172.16.7.5;
 port 53;
 pid-file var/run/named/named.pid;
 session-keyfile var/run/named/session.key;
 listen-on {
 loopback;
 eth0;
 };
 listen-on-v6 { none; };
 recursion no;
 notify explicit;
 allow-query { trusted; };
 
 dnssec-enable yes;
 dnssec-validation yes;
 max-journal-size 100k;
 random-device /dev/urandom;
 };
 
 this is zone file:
 
 $TTL3600
 example.SOA ns1.example. bugs.x.w.example. (
 1292481908
 7200
 3600
 734400
 600
 )
 TXT dnssec test
 NS ns1.example.
 NS ns2.example.
 $ORIGIN example.
 ns1 A   127.0.0.3
 ns2 A   127.0.0.4
 
 a   NS  ns1.a
 NS  ns2.a
 DS 23344 5 1 CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56
 
 ns1.a   IN  A   127.0.0.1
 ns2.a   IN  A   127.0.0.1
 
 c   NS  ns1.c
 c   NS  ns2.c
 ns1.c   IN  A   127.0.0.5
 ns2.c   IN  A   127.0.0.6
 
 ai  IN  A   127.0.0.1
 IN  0:0:0:0:0:0:0:1
 xx  IN  A   127.0.0.1
 IN  0:0:0:0:0:0:0:1
 
 w   IN  A   127.0.0.1
 *.w MX 10   ai
 x.w MX 10   xx
 x.y.w   MX 10   xx
 
 If I make query for RRSIG records, named is returning proper signatures.
 for example for SOA record:
 
 $ dig @127.0.0.1 example rrsig +short
 SOA 10 1 3600 20110220123506 20110121113506 51587 example.
 cVzWYkeTASPUiHv0DxFXpTsK4G1QkpS3sZ1jXmDCDv+EaYUs2C/kRlD9
 CUT
 
 same with AXFR, and same for zone file.
 
 - -- 
 regards
 
 zbigniew jasinski
 [SYStem OPerator]
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJNOYSaAAoJEH26UYiRhe/gNmcQALSiNOVoKWBpA/GV1WiarmDt
 b+G6NZPBOtXXW4U90XDqL211TUaeXgLfwesRfIERraDxOTtCPjTx9npIoMQMLrWk
 F91slmf8thgLpPzFqwe2FxMoagL/HdQ8fXrzHmdMU5Lsg8gBalJyVKL56Hozlp9R
 n5LZy8+QBSJHuJKXFIZcBPPCdUW8dEJcONve01ik09gHbwcQzCuqwY7S5vYrDW2s
 fZhYQUCvjdBpmf3uKH1yXiqdtUtUerZN3fCB6r4cGIkzYk98iEj5M6fngsBl49vt
 SijzWbQftd0ThSxHPcEiuSom4pAuFlxN1O7Al8laIRwgme5wvtUeN+PA8sxr7FWl
 cnUC///yLnYJNTJBnbIY0wiWsSTU9H4LU42tnesAKJaIBmaOR9w6QgxLs+E+pyKM
 M3pnC//ZqxGirnV9YetV6mqfch23Y08yWcmjTNI8QytEoXPMMaGXyh4IYJFAiMaz
 SxV5B9Be1KP1DxO2wyHwDEwrZzIkS5sl1iiaoyb+G0d9dWjuvlSmkDSZA43nYXGS
 cn91vMLqUHpYCYVIy3p8w62y7+jOPrIM94vsgONjPijqlB0DZY2JsMP4q2StHUui
 cYEqw5NDoCGpxPbnlMJF8FmFmv9R7r+yTPI/O5oR7I4sbhxti3eP0/oDLTlpZDfx
 qF6n+qmGBcLll7mn4pUy
 =dt7w
 -END PGP SIGNATURE-
 
 ___
 bind-users

Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-19 Thread Kalman Feher
Try without +short ;)
I also have the habit of using that and can get caught out. Remember that
+short only includes the answer, which is not the RRSIG you are hoping to
see.




On 19/01/11 12:49 PM, Zbigniew Jasiński szo...@nask.pl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 W dniu 2011-01-17 15:39, Kalman Feher pisze:
 Have you tried more sane times?
 
 Those don't look like sensible times even for a test, which is probably why
 BIND isn't signing. I think you are below the sensitivity level for BIND to
 sign automatically.
 
 If you want to test, try using hours or days as values. When initially
 testing I used lifetimes of a week, then increased to 1 month for ZSKs and 3
 months for KSKs. That allowed me to test things quickly, but without
 compromising the validity of the test.
 
 
 maybe it was little to short for keys, but ok, new keys with new timings:
 
 ; Created: 20110119091030 (Wed Jan 19 10:10:30 2011)
 ; Publish: 20110119091124 (Wed Jan 19 10:11:24 2011)
 ; Activate: 20110119091224 (Wed Jan 19 10:12:24 2011)
 ; Inactive: 20110218091224 (Fri Feb 18 10:12:24 2011)
 ; Delete: 20110218091724 (Fri Feb 18 10:17:24 2011)
 
 and what I've seen in logs:
 
 NSEC3PARAM via dynamic update, and 'rndc sign' command:
 
 Jan 19 10:10:24 named[32664]: update: client 127.0.0.1#65349: updating
 zone 'example/IN': adding an RR at 'example' NSEC3PARAM
 Jan 19 10:10:24 named[32664]: general: zone example/IN:
 dns_zone_addnsec3chain(hash=1, iterations=12, salt=1BDF09CE56C674D422EB)
 Jan 19 10:10:24 named[32664]: general: zone example/IN:
 zone_addnsec3chain(1,CREATE,12,1BDF09CE56C674D422EB)
 Jan 19 10:10:30 named[32664]: general: received control channel command
 'sign example'
 Jan 19 10:10:30 named[32664]: general: zone example/IN: reconfiguring
 zone keys
 Jan 19 10:10:30 named[32664]: general: zone example/IN:
 zone_addnsec3chain(1,REMOVE|NONSEC,12,1BDF09CE56C674D422EB)
 Jan 19 10:10:30 named[32664]: general: zone example/IN: next key event:
 19-Jan-2011 10:11:24.765
 
 first key event is Publish:
 
 Jan 19 10:11:24 named[32664]: general: zone example/IN: reconfiguring
 zone keys
 Jan 19 10:11:24 named[32664]: general: zone example/IN: next key event:
 19-Jan-2011 11:11:24.807
 
 second one is Activate which should occur on (Wed Jan 19 10:12:24 2011),
 but in log is one hour later, why is that?
 
 but ok, signing zone is most important, so after Activate key event:
 
 Jan 19 11:11:24 named[32664]: general: zone example/IN: reconfiguring
 zone keys
 Jan 19 11:11:25 named[32664]: general: zone example/IN: next key event:
 18-Feb-2011 10:12:24.274
 
 so now I should have a signed zone with KSK/ZSK of one month lifetime.
 using dig:
 
 $ dig @127.0.0.1 example dnskey +dnssec +short
 257 3 10 AwEAAa7r9QSelP34TYFVWWLhDVU+RU+LI7Fr9N0Hy2xnJ/8TK8sRo+OC
 CUT
 256 3 10 AwEAAa/sFWJDcylO33IQWnpKEve661t0S/K8+AWPy+PSq69xo27WUGRN
 CUT
 
 so I have both keys in my zone, but without signatures.
 
 I've checked the journal file and there are updates with RRSIG records
 but still named is returning answers without signatures.
 
 Any hint?
 
 - -- 
 regards
 
 zbigniew jasinski
 [SYStem OPerator]
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJNNs+3AAoJEH26UYiRhe/gfRsP/3m2zDBhKPpICiUroC+CUgpw
 OKlwGRcwWZFrmea4j7J/zUdS6OPpwh8lsHCftUS17WPhr654guAF7ftf/y8m6dLb
 2aYOU1boYv4uDrlu74/bvyt1FngA8LMzNIO2lIP/x53QBqMMuPRTMsC4SpMi4VVc
 G04jeVjE7R6RG1kDZspEaaRtbxtQpJobW2seKP90U99FMhwAgqyDFwYdx1zF0vAt
 kcDmN+fwGOJUQO1CO8/2jX6AgpMXDGOoG75qCVHB5QzXysW47rzLuewvVB9h/2lU
 WNDtmCUIZ50JtfyuOKrz8U6hdbfvRI4iJFdweckniCJ85gyx7fHMP3sgZModRKgW
 PdxLjHQ3xOqsBmfGlAaeYSrAx7hryNaUqLE1xGDLkCaX7dywz5sH4kElqpRwGOvf
 CvLBJ8df7qGLgX+B5VuAXOzGZxOCOhwBuMiSYwY8F/12tBhzW8nhaRGBuBBj6cAp
 7AkFFa/DsqVvCo+sYWt1+ekAt2LQWnE+cDaV2Ar84lG/fMYtvHDfNhdqLa1P6N7S
 PG9rdfkv+jh5zlczIoNFVRVhVoPEs2ui28PVw8ArvOnUeeJrl60fdputvcXThUY/
 uea6/mDrRCLSUYpV9oyMxDdtR3pz0buD80Gk20HBgI/BHopD6H77DNpDAvy+Q3fF
 wgluCpVvogYlj88l1uXZ
 =jGrN
 -END PGP SIGNATURE-
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: DNSSEC - mismatch between algorithm and type of NSEC

2010-12-29 Thread Kalman Feher
What was the observed behaviour in your test system?

From a sanity point of view and if you are checking the zone prior to
accepting the DNSKEY, then I see nothing wrong in rejecting it. There are
already other restrictions on domains in .EU that establish a precedent for
being more demanding on DNSSEC signed zones.




On 29/12/10 9:37 AM, Marc Lampo marc.la...@eurid.eu wrote:

 Hello,
 
 And my best whishes for the new year 2011 !
 May we have lots of interesting questions, where we all can learn from ;-)
 
 (hope my question is also in that category ...)
 
 As .eu top level domain we try to avoid inserting DS records in our zone
 where corresponding DNSKEY information is missing from the customers' zone
 file,
 thus avoiding to activated DNSSEC with an already broken chain-of-trust.
 
 However, we now found the following case :
 1) registrar offers us DNSKEY information with algorithm 7 :
 RSASHA1-NSEC3-SHA1
 2) in the zone file, there are NSEC (and not NSEC3) records
 
 Public DNSSEC verification tools (dnsviz, verisignlabs)
 don't seem to make a problem out of this
 (they do signal an insecure delegation, obviously : we don't publish a DS
 record).
 ((there must be a wildcard in the zone file,
   So I can enter a domain name where the verification tools get NSEC
 records))
 
 
 I can simulate the case in a test environment, of course,
 But then I only see the behaviour of a specific name server
 implementation.
 But what is the list's interpretation of this situation : erronous or not
 ?
 Does any DNSSEC RFC mention this case and prescribe a reaction to this ?
  (I didn't find any -
   RFC5155 states the new algorithms - 6 and 7 - *must* be used when NSEC3
 is used,
   But not a word - unless I overlooked it - about using algorithm 7 and
 yet, NSEC ...)
 
 
 Looking forward to your comments.
 
 Kind regards,
 
 
 Marc Lampo
 Security Officer
  
     EURid
     Woluwelaan 150
     1831 Diegem - Belgium
     TEL.: +32 (0) 2 401 3030
     MOB.:+32 (0)476 984 391
     marc.la...@eurid.eu
     http://www.eurid.eu
    
 
 
 Want a .eu web address in your own language? Find out how so you don¹t
 miss out!
 
 
 Register your .eu domain name and win an iPod touch this X-Mas
 http://www.winwith.eu
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: Troubleshooting slow DNS lookup

2010-11-26 Thread Kalman Feher



On 26/11/10 5:58 AM, Mark Andrews ma...@isc.org wrote:

 
 In message aanlktimzmc4pgne7n72hnb7gnjuat9r2oktigaazv...@mail.gmail.com,
 Rian
 to Wahyudi writes:
 Hi Mark,
 
 Thanks for the pointers , your are spot on!
 
 Doing dig +trace +dnssec www.paypal.com always fail.
 After some investigation with the network guys, it appear that our upstream
 firewall are dropping DNS UDP packet larger than 512.
 Cisco FWSM have this configuration enabled by default :
 
 http://www.cisco.com/en/US/docs/security/fwsm/fwsm31/command/reference/i2.htm
 l#wp1565355
 
 So the default is inspect dns maximum-length 512 if I read that
 page correctly.  inspect dns or as a minimum inspect dns
 maximum-length 4096 will allow reply traffic through for named.
 
 I thought I had heard that Cisco had code which looked for the EDNS
 UDP size option and adjusted the maximum length based on that on a
 per transaction basis and enforced 512 if there wasn't a EDNS option.
Yes, but I think its a recent addition to their code.

The Cisco ASA supports:

message-length maximum client auto

This will use the OPT value as the maximum. I know its supported on version
8.3 of ASA software. It might not be supported by the switch modules of the
OP.

 
 Mark

-- 
Kal Feher 

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


Re: Bind and blacklist IP file

2010-10-13 Thread Kalman Feher



On 13/10/10 12:13 PM, Andrey G. Sergeev and...@aernet.ru wrote:

 Hello Alans,
 
 
 Tue, 12 Oct 2010 16:52:15 +0300 Alans wrote:
 
 On 10/12/2010 03:44 PM, Andrey G. Sergeev (AKA Andris) wrote:
 Hello Ian,
 
 
 Tue, 12 Oct 2010 10:54:19 +0100 Ian Tait wrote:
 
 Ok, but you can always browse by IP address and in this case
 there is no DNS server than can stop you from browsing what you
 want.
 
 Vaguely related, are host headers - a lot of webservers share an
 IP address/many IP addresses and use host headers to 'display' the
 correct website.
 
 You wouldn't be able to browse a particular website hosted in this
 fashion, by IP address.
 
 If you know the website domain and the corresponding IP address and
 if your ISP prevents you from accessing this website by timing out
 or tampering DNS query results you can always put the entry like
 
 192.168.10.20   www.domain.tld.
 
 to your hosts file and access the site.
 
 This technique is also in use when someone needs to access the site
 which is on a not delegated domains.
 
 Even this way, you should know all the IP of subdomains to work
 properly. Try it for facebook, open homepage fine but once you login
 it will fail.
 
 If you can query at least one of the authoritative NS for the domain in
 question then you would have no problems determining the IP addresses
 you might need.
 
The straight forward answer to the original question is that BIND RPZ
features will allow you to isolate domains as requested. Noting that this is
_just_ DNS and as others have mentioned, that's hardly a solid wall of
unavailability for your blacklisted sites.


 Another thing, we are talking about a technical person, for other
 users they don't know about hosts file or they don't have access to
 change it even it they know about it.
 
 Sure but please don't forget about the average level of computer skills
 of the audience the most underground sites have.


 

-- 
Kal Feher 

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


Re: Bind and blacklist IP file

2010-10-11 Thread Kalman Feher



On 11/10/10 1:02 PM, Alans alans...@gmail.com wrote:

 
   Hello,
 
 Is it possible for bind dns to check the queries, if the returned answer
 is existed in a file that contains blacklisted IPs then block it?
 
DNS RPZ may do what you want.

There is a patch on the isc.org website for 9.4,9.6 and 9.7.1-P2
Described in further detail here:
ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt
and here:
http://www.isc.org/community/blog/201007/taking-back-dns-0

 One more thing, from where we can get/buy updated lists of categorized
 IPs/websites,
 like Gaming, Porn, Social...?
 
 Thanks,
 Alans
 
 
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: per-zone-recursion?

2010-10-01 Thread Kalman Feher



On 1/10/10 9:15 AM, Joerg Dorchain jo...@dorchain.net wrote:

 On Thu, Sep 30, 2010 at 07:13:11PM -0400, Kevin Darcy wrote:
 Per-zone recursion control doesn't exist in BIND, because frankly it
 doesn't make sense.
 
 I used to think that, too, until I came to my specific problem.
 
 Either a zone type is meaningless *without* recursion (type forward,
 type stub), or recursion is *unnecessary* because the nameserver
 answers from authoritative data (type master, type slave).
 
 Exactly. Up to here I completely agree.
 
 Put another way, have you thought through exactly what you want to
 happen if a client queries something not specifically carved out for
 recursion, e.g. isc.org?
 
 Yes. To explain my setup further, there is a view based on
 src-IPs for some clients, where recursion is turned on.
 The rest of the world gets non-recursive answers, e.g. with
 authoritative data, or refused.
 
 In case of that specfic forward zone, bind answers in the
 non-recursive case with a referal to itself (there is only one
 public IP), which is causing a loop, as there is no way to
 specify a different port in the DNS protocol (AFAIK)
This is the problem and the reason I agree with Kevin.  The referral is
correct behaviour. Your DNS set up is wrong. You have 2 choices and a third
less palatable option:

1. Make the other DNS software available on another IP. So normal DNS
behaviour works.

2. Add the zone as a slave within your authoritative view. (this option may
be the easiest for your situation).

3. recursive view with forwards to both your authoritative view and the
dynamic subdomain. I think this solution is silly and will be problematic to
maintain, but its likely to suite your needs exactly.


 
 The response from a BIND instance, when recursion is denied or not
 requested, is always either (as per Section 4.3.1 of RFC 1034):
 a) an answer from authoritative data,
 b) an answer from cache
 c) a negative-caching response,
 d) a (0 answers) referral, or
 e) some sort of non-response, like an error (SERVFAIL) or an
 administrative rejection of the query (REFUSED)
 
 If (a) doesn't apply (because not authoritative) and neither does
 (b) (because how can answers be cached in the first place if
 recursion is being denied?), that leaves (c) through (e), none of
 which are particularly useful to the client. So you might as well
 REFUSE queries outside of zones for which recursion is not
 explicitly enabled. Configure allow-query { none; }; as the
 default followed by specific exceptions for the zones you want to
 open up, e.g., dynsup.example.net.
 
 You have summarized my thoughts very well. At this point I found
 out that the current grammar for bind does not allow to combine
 type forward; with an allow-query (or allow-recursion).
 
 A quick look at the sources also showed that forward zones are
 implemented differently than real zones like master or slave.
 
 This way I came to the point where I am wondering if it is
 possible to configure bind either
 - do recursion on a per-zone base for forward zones, as the
   currently implemented criteria (src-ip, dst-ip, recursion flag)
   do not cover my case in an obvious way
 - forward queries to a specific destination and the answers back,
   acting as a reverse-proxy without too much intelligence.
 
 Bye,
 
 Joerg
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: When does BIND send queries with DO flag enabled?

2010-09-29 Thread Kalman Feher



On 29/09/10 10:30 PM, Kevin Oberman ober...@es.net wrote:

 Date: Wed, 29 Sep 2010 15:51:55 -0400
 From: Taylor, Gord gord.tay...@rbc.com
 Sender: bind-users-bounces+oberman=es@lists.isc.org
 
 
 We recently ran into an intermittent problem sending queries to a
 business partner. Turns out they had CheckPoint firewalls with
 SmartDefense turned of for DNS traffic. This was blocking traffic going
 to them with DO flag enabled. I could duplicate the problem from a
 command line by issuing dig @partner hostname +DNSSEC and this failed
 everytime. When querying through the DNS server though using NSLOOKUP on
 WinXP, the resolution was hit-and-miss. Watching a sniffer trace,
 sometimes BIND 9.4.1-P1 would send with DO flag enabled, and other times
 without.
 
 I know this is an older version of BIND, and lots of bugs fixed in newer
 versions. However, looking at sniffer traces from 9.7.0-P2 shows the
 same behavior = sometimes DO is set and sometimes not set.
 
 Can someone explain when BIND sets DO flag and when it won't? Most of my
 client workstations are XPSP3, and NONE of the queries coming from those
 clients have DO flag set.
 
 Any help is appreciated...
 
 Gord Taylor (CISSP, GCIH, GEEK)
 
 Gee, an annoying and stupid legal notices at the end of a mail message
 is even more annoying when it is in several languages. (Yes, I
 understand that some totally clueless lawyer earning a LOT more for not
 thinking than you do for thinking is not your fault, but it's still
 REALLY ANNOYING!)
 
 The DO bit is set by default for the simple reason that your server is
 DNSSEC capable. The DO bit says DNSSEC OK and is simply declaring that
 the server is capable of handing (though not necessarily validating)
 responses containing DNSSEC RRs. See RFC3225.
 
 I assume that setting dnssec-enable to no will turn this bit off, but
 please get the broken firewall fixed!
This is actually not the case, although it is understandable you would think
it is the way things _should_ work. DO is set when the resolver has EDNS0
enabled. So that is the only way to turn it off (disable EDNS0). Turning off
EDNS0 is likely to effect a lot more than DNSSEC. I wouldn't recommend it.

A discussion on this topic was held within this mailing list (June 2010
IIRC) with Jinmei and Evan from ISC providing the insight regarding BIND's
behaviour. There was further discussion behind the reasoning for this choice
as well.

Nevertheless your point is valid, fixing the firewall is the only
alternative in my opinion. EDNS0 is not a new technology (10 years I think).
Would you use a security product still basing its policies on a time when
windows 98 was cutting edge?

 
 As to not always sending DO, I believe that is dependent on the query
 from the client. It would depend on the source of the query. If it was
 from the server to get data that would not be sent back to the client, I
 imagine the DO bit would be set. (NS lookups during recursion would be
 an example), while queries for return to the client will probably
 follow the state of the DO bit seen in the query from the client. I'd
 guess WINXP is not setting DO. I suspect WIN7 would.
 
 This last section is largely an educated guess. I don't have time now to
 read up on those details in the RFCs.
 
 Again, get the @#$% firewall fixed! As time goes on, more and more
 queries will be blocked by it as DNSSEC moves to the mainstream.

-- 
Kal Feher 

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


Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?

2010-09-22 Thread Kalman Feher



On 22/09/10 4:14 AM, Doug Barton do...@dougbarton.us wrote:

 On 9/21/2010 7:46 AM, Kalman Feher wrote:
 It may well be analogous to that (though I disagree), but the quote does not
 substantiate why knowing public information is bad. In the example above,
 you've simply saved your switchboard and the caller some time. If you don't
 want someone to know it, don't make it public (at the very least).
 
 You'll have to accept that no matter what steps you take, your public
 information will be available to those who wish to find it. Taking steps to
 prevent that is likely to waste more of your time than it will of those
 looking.
 
 When this topic first came up 12+ years ago I (and others) said that
 DNSSEC would never see wide deployment unless the ability to walk the
 zone was eliminated. We were all poo-pooed at the time with lots of
 security through obscurity, LOL type arguments. Development of DNSSEC
 specs continued to ignore the need to eliminate zone-walking for almost
 a decade until finally a consortium of folks more influential than I put
 their foot down and hammered out the NSEC3 spec (abridging the history
 here for the sake of a good story).
 
 My point being, it really doesn't matter if you agree with the reasoning
 or not, whether you understand the use case(s) or not, or whether you
 ever deploy NSEC3 or not. The fact is that there are a non-trivial
 number of organizations who will not deploy DNSSEC without it, so
 attempting to convince people not to use it is pointless.
Not surprising that you've missed the point given the long thread, but I'll
reiterate here.

The concern was that a zone could be walked even _with_ NSEC3. Use whichever
NSEC floats your (leaky) boat. It isn't going to stop public information
from falling into an evil persons hands.

I'd recommend being a little more sensible and only making public that which
you want to be public. Then protecting all systems addressed within the zone
as if bad people knew about them, regardless of the these are not the RRs
you're looking for magical powers of NSEC3.

 
 
 Doug (... and it annoys the pig)

-- 
Kal Feher 

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


Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?

2010-09-22 Thread Kalman Feher



On 22/09/10 11:29 AM, Matus UHLAR - fantomas uh...@fantomas.sk wrote:

 I'll reply with a quote from the BIND  DNS book:

 It¹s the difference
 between letting random folks call your company¹s

 switchboard and ask
 for John Q. Cubicle¹s phone number [versus] sending

 them a copy of 
 your corporate phone directory.


 That is a poor analogy.


imho it's perfect.
Analogies to specific issues are a poor idea. They abstract details that
should be considered and by trying to visualise the new example you
associate properties that don't exist within the original problem.

I could list differences but it would pander to the belief that somewhere
out there is the perfect non DNS example to a DNS problem.

Zone walking and its perceived risks should only be considered in light of
DNS knowledge, not boats, not phone switchboards or any other non DNS item.

Its fine to convey simple concepts using an analogy. But by using one for a
specific issue (on bind-users), you betray ignorance of the problem at hand
by relying on unrelated behaviours and properties to fill in the blanks for
you.

It is a poor analogy because so many of the properties of the original
problem (DNS software, zone walking software, publically available RRs)
simply do not behave in ways even vaguely similar to a human answering a
phone. 

If you think zone walking prevention (such as it is) makes you more secure.
I say prove it. Show me something measureable. Show me how you can protect a
publically available resource by preventing zone walking (which isn't
preventable by the way). After that, feel free to tell me how a phone
switchboard would implement the same solution.


-- 
Kal Feher 

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


Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?

2010-09-21 Thread Kalman Feher



On 21/09/10 8:43 AM, Niobos nio...@dest-unreach.be wrote:

 Thank you for the excellent advice!
 
 On 2010-09-20 18:09, Kevin Oberman wrote:
 I recommend anyone attempting to secure their DNS read the NIST Computer
 Security Resource Center document SP800-81 Rev.1, Secure Domain Naming
 System (DNS) Guide at:
 http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf
 It recommends rolling th KSK every 12 to 24 months and the ZSK every 1
 to 3 months. These values are unchanged from the original SP800-81
 issues back at least two years ago and probably three. Everyone I have
 spoken with who works with crypto feels that, barring a math
 breakthough, these numbers are VERY conservative.
 Very interesting read.
 
 However, for my original question, the NIST document says:
 If the zone is signed using NSEC3 RRs, the salt value should be changed
 every time the zone is completely resigned
 Since my zone is only updated dynamically, I'll never *completely*
 resign my zone...
During ZSK roll over.
 Also, they do mention that [the salt] should be
 changed on a regular basis to maintain protection against zone enumeration.
I personally find protection against zone enumeration to be a false sense of
security. If it's public people will find it. Ask your self what it is that
you want publically accessible yet you don't want others to be aware of.


 However, I don't see how it protects the zone from that if I use Daniel
 Bernstein's method (i.e. guess a name  hash it. If it's outside a known
 hash-range, request the server. Either it's a hit, or it's a new
 hash-range.) If the hash changes halfway through the procedure, I just
 rehash all my hits and go on. This is hardly a slowdown at all.
 
 
 Online/offline keys
 Sometimes this may be a choice, other times legislative or standards
 compliance will require certain behaviour. I've seen some documents require
 that even ZSKs remain offline (government agencies mostly), but generally
 its not considered much benefit if it rolls over reasonably often. KSKs are
 more commonly recommended to remain offline, but that definition can vary as
 well. A genuine HSM (Hardware Security Module), is not likely to be found in
 the bulk of DNSSEC deployments, due to cost, complexity and operational
 staff skills. Thus most operations will find it easier to generate keys
 either on the master server (perhaps the only server with key generating
 software) or close by (another server that is nevertheless online). If you
 don't use an offline HSM, then your alternatives will require you to have
 shorter roll over times in my opinion.
 
 HSMs are the way to go...if you can afford them. Prices vary a LOT from
 expensive to WOW! (So does functionality, and DNSSEC will typically take
 very little.) Because of dynamic DNS requirements, keeping the private
 ZSK on-line is allowed, even for government sites, though ONLY in cases
 where dynamic DNS is used or the back-end DNS management system requires
 it. Government sites may not keep the KSK on-line. See SP800-81r1
 Section 9.4 for details.
 
 It's a private zone; HSM's are waay too expensive for that purpose!
 I use DDNS daily, so that requires the ZSK to be online. The KSK can
 remain offline if I manually resign the new DNSKEY RRset every Lzsk
 (i.e. every month). I'm not sure I'll have the courage to do this...
A small scale offline key management process may be something like:

1. install key creation tools on dedicated laptop or other non permanently
connected host. (bind dnssec tools or opendnssec or tools of your choice)
2. script up the creation including lifetimes.
3. script up a transfer from the offline node to master server. Place keys
in key-directory on master server.
4. master server rolls over based on lifetime values (assuming BIND 9.7+)
5. remove ksk
6. rinse and repeat next month

Security depends on how well you protect your key-generating system, on
whether your master server is a hidden master or publically accessible (for
any service) and how tightly you script the process. On a small scale, this
should certainly provide acceptable security. On a large scale, manual
intervention would make me very concerned with the likelihood of human based
outages. 

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

-- 
Kal Feher 

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


Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?

2010-09-20 Thread Kalman Feher



On 20/09/10 6:09 PM, Kevin Oberman ober...@es.net wrote:

 Date: Mon, 20 Sep 2010 11:03:31 +0200
 From: Kalman Feher kalman.fe...@melbourneit.com.au
 Sender: bind-users-bounces+oberman=es@lists.isc.org
 
 Apologies in advance for the longer than intended reply.
 
 I've spent a lot of time reviewing documents regarding timing values and
 they vary quite widely. One observation I've made is that many
 recommendations, especially those that are a little older, are predicated on
 the assumption that the process of signing is difficult and complicated. So
 last year I saw recommendations of ZSKs for a year and KSKs for 2 or more.
 As signing became easier and TLDs made their submission policies for DS (or
 pub key) clearer these numbers have dropped.
 
 I'm now seeing recommendations of 1-3 months for ZSKs and 6-12 months for
 KSKs.
 
 The advice on this has always been all over the map, but the most common
 recommendation I have seen, and I have been seeing it for years, is to
 roll ZSKs about once a month and KSKs annually.
 
 I recommend anyone attempting to secure their DNS read the NIST Computer
 Security Resource Center document SP800-81 Rev.1, Secure Domain Naming
 System (DNS) Guide at:
 http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf
 It recommends rolling th KSK every 12 to 24 months and the ZSK every 1
 to 3 months. These values are unchanged from the original SP800-81
 issues back at least two years ago and probably three. Everyone I have
 spoken with who works with crypto feels that, barring a math
 breakthough, these numbers are VERY conservative.
 
 I might also mention that US government system are required to follow
 the recommendations of SP800-81r1.
 
 If you automate it, which is relatively easy today, then having shorter
 times makes sense on a number of levels.
 
 -It allows potentially lower bit sizes, due to the time/size trade off.
 -It ingrains the process within your operational procedures. Really large
 gaps between events can lead to a loss of skills or capability. (has anyone
 seen that HSM we bought 2 years ago?). That may or may not happen of course,
 but its good to exercise procedures.
 -You can use roll over times as natural change windows for new algorithms or
 new procedures. And the likelihood of changes in the next 2 years is very
 high since registries are still adapting and learning.
 
 I can see no point in the use of lower bit size keys. Current systems
 are able to deal with the sizes now in use. Shortening keys simply
 weakens the system.
That depends on what one assumes to be the base size. It also depends on
what one intends to use the keys for. The bulk of the advice within 800-81r1
assumes the target is a single or small number of production domains. The
operational recommendations would become unwieldy very fast at large scales.
The .GOV registry also has different policies around keys than other
registries. Key groups (or lack thereof) being an obvious difference, and
one that may impact how you feel about life times and bit sizes.

The other item of concern not directly addressed by 800-81r1 (since its
target audience wouldn't care that much), is the impact of signing many
(hundreds or thousands) domains. Bit sizes, life times, signing jitter and
overall domain size become of far more concern when your server will be
signing effectively all the time. Even allowing for dedicated signing
systems, you'll care a lot more about these issues.

Another report that may be more appropriate if you have a large number of
domains is the Shinkuro Setting the parameters report.
http://www.dnssec-deployment.org/documents/SettingtheParameters.pdf. It is
aimed at larger collections of domains and thus the advice is focused at
issues of load and signing capacity.

This isn't a matter of which report is better. Rather, which recommendation
is applicable to my organisation?. The NIST suggestions (if you are not a
government body) are entirely reasonable if your domain count is low. As the
domain count enters triple digits, other advice and research may be more
appropriate.

 
 I agree with your concern with long intervals between signing. Blowing a
 key roll is a really unpleasant things and will get more so as more and
 more servers start doing validation.
 
 The value of the above benefits will vary depending on how many domains you
 have across how many different TLDs. The more of either, the greater the
 benefit of an automated and reasonably regular roll over.
 
 Good advice!
 
 Online/offline keys
 Sometimes this may be a choice, other times legislative or standards
 compliance will require certain behaviour. I've seen some documents require
 that even ZSKs remain offline (government agencies mostly), but generally
 its not considered much benefit if it rolls over reasonably often. KSKs are
 more commonly recommended to remain offline, but that definition can vary as
 well. A genuine HSM (Hardware Security Module), is not likely to be found

Re: Second dig lookup not the same as the first

2010-09-16 Thread Kalman Feher
For the TCP issues check your network.

I'm not familiar with DLZ, but it may be worth understanding how it is
effected by the addition-from-[auth|cache] options. Since you get the full
response once, I presume you do not have minimal responses enabled.

My ignorance of DLZ is showing, but consider if there is any caching that is
going on that is returning just the ANSWER after the first query.


On 15/09/10 11:59 PM, Scott Haneda talkli...@newgeo.com wrote:

 Hi, 
 
 No, I am not running any firewall on the client side at all.  I can perform
 lookups elsewhere that behave as I would expect. I also performed these tests
 on another machine that has a more current and non Apple dig as well.
 
 The server is RHEL, not Mac OS X.  I have deployed many named servers on Mac
 OS X, but I do not use the Apple supplied version, and always either go to the
 source for a more current version, or lately, I have been using MacPorts to
 aid in that installation process.
 
 I don't think this question is as much of a platform issue as it is one of my
 lack of understanding in what causes the additional and authority sections to
 change on a subsequent request.
 -- 
 Scott (* For off-list contact, replace talklists@ with scott@ *)
 
 On Sep 15, 2010, at 1:45 PM, wllarso wrote:
 
 From the output of your dig command you show that you are running a MacOSX
 system. Are you running the firewall on this system also? That may be
 dropping the TCP communication.
 
 Be aware that Apple's DNS server configrration throws every bell and whistle
 into the config. If you really are serious about running a DNS server under
 MacOSX, then make a post on the MacOSX-server list and step back for all of
 the reasons this isn't a good idea, at least not using what Apple give you.
 
 Bill Larson
 
 and sorry about the top posting, but this was ...
 Sent from Garminfone by T-Mobile.
 
 Scott Haneda talkli...@newgeo.com wrote:
 
 Hello, I have set up a new BIND/named server, being backed by DLZ in this
 case, though I don't think that will have any bearing on my question.
 
 This NS is not publicly known or listed as an NS anywhere as of yet, so it
 is only my own testing that has hit the machine.  If I perform a dig
 request, the first request returns additional data, any subsequent lookups
 return no additional data.  Does anyone know why this is?
 
 I also seem to have issues when forcing tcp, does anyone have any ideas what
 that could be caused by?  Is there a setting in named.conf that controls
 udp/tcp or should I be talking to the network admin about this?
 
 I have to obfuscate this data, I apologize for that...
 
 == First dig request, never been looked up before
   ;  DiG 9.6.0-APPLE-P2  @63.251.yyy.yy example.com
   ; (1 server found)
   ;; global options: +cmd
   ;; Got answer:
   ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41088
   ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
   ;; WARNING: recursion requested but not available
 
   ;; QUESTION SECTION:
   ;example.com.  IN A
 
   ;; ANSWER SECTION:
   example.com. 3600 IN A 208.122.xxx.xx
 
   ;; AUTHORITY SECTION:
   example.com. 86400 IN NS ns2.some-nameserver.com.
   example.com. 86400 IN NS ns1.some-nameserver.com.
 
   ;; ADDITIONAL SECTION:
   ns1.some-nameserver.com. 86400 IN A 208.122.xxx.xx
   ns2.some-nameserver.com. 86400 IN A 208.122.226.214
 
 == Second dig request, moments after the first
   ;; Query time: 41 msec
   ;; SERVER: 63.251.yyy.yy#53(63.251.yyy.yy)
   ;; WHEN: Wed Sep 15 12:15:48 2010
   ;; MSG SIZE  rcvd: 136
 
 
   ;  DiG 9.6.0-APPLE-P2  @63.251.yyy.yy example.com
   ; (1 server found)
   ;; global options: +cmd
   ;; Got answer:
   ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20029
   ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
   ;; WARNING: recursion requested but not available
 
   ;; QUESTION SECTION:
   ;example.com.  IN A
 
   ;; ANSWER SECTION:
   example.com. 3600 IN A 208.122.xxx.xx
 
   ;; Query time: 37 msec
   ;; SERVER: 63.251.yyy.yy#53(63.251.yyy.yy)
   ;; WHEN: Wed Sep 15 12:15:50 2010
   ;; MSG SIZE  rcvd: 55
 
 And trying to see what is going on with tcp or udp...
 
 $dig @63.251.yyy.yy example.com +tcp
 ;; Connection to 63.251.yyy.yy#53(63.251.yyy.yy) for example.com failed:
 connection refused.
 
 If I do the same thing with +notcp, I get the result in example #2 above,
 where there is no additional section.
 
 Thank you for any assistance, I appreciate it.
 
 -- 
 Scott (* For off-list contact, replace talklists@ with scott@ *)
 
 ___
 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

-- 
Kal Feher 

___
bind-users mailing list
bind-users@lists.isc.org

Re: Timeouts and retries on high speed Lans

2010-09-14 Thread Kalman Feher
So the cache servers are HA behind something (F5 LTM, Cisco local director,
something else). Are the authoritative servers? It would seem sensible to do
the same with them. That way a timeout only occurs if the whole HA cluster
is unavailable.
You can alleviate even that situation by seeding the cache servers every
(TTL-some value) minutes. Or slaving the domain on the cache servers.


On 14/09/10 11:34 AM, Howard Wilkinson how...@cohtech.com wrote:

 I have been working on building out a couple of large data centres and
 have been struggling with how to set up the systems so that we get a high
 resilience, highly responsive DNS service in the presence of failing
 equipment.
 
 The configuration we have adopted includes a layer of BIND 9.6.x servers
 that act as pure name server caches. We have six of these servers in each
 data centre paired to provide service on VIPs so that if one of the pair
 fails the other cache takes over.
 
 Our resolv.conf is of the following form.
 
 search xxx.com yyy.com
 nameserver 10.1.1.1
 nameserver 10.1.2.1
 nameserver 10.1.3.1
 options timeout:1 attempts:15 no-check-names rotate
 
 The name servers are thus on different networks within the DCs.
 
 Our first problem arises because the timeouts seem to be taken serially on
 each server rather than the rotate applying between each name server
 request. Is this what I should have expected i.e. a 15 second timeout
 before the next server is tried in sequence.
 
 The second problem we face is that even if we could get a one second
 timeout this orders of magnitude too slow for names that should be
 resolved within our local name space. In other words for lookups within
 the xxx.com and yyy.com domains I would like to see timeouts in the
 micro-second range.
 
 Thinking further about this problem I have been considering whether the
 resolver should be multi-threaded or parallelised in some way so that it
 tries all fo the servers at once and accepts the first to respond. I have
 come to the conclusion that this would be too difficult to make resilient
 in the general use of the resolver code, but would make sense if the
 lwresd layer is added to the equation.
 
 Which brings me on to the use of lwresd, this would reduce the incidence
 of problems with non-responsive servers in that it would detect and switch
 to an alternative server on the first failed attempt. However, this still
 means that if lwresd has not detected the down server then we get a stall
 in response within the data centre.
 
 So my questions are:
 
 1. Does anybody have any experience in building such systems and
 suggestions on how we should tune the clients and servers to make the
 system less fragile in the presence of hardware, software and network
 failures.
 
 2. Is is possible with lwresd as it is written today to get the effect of
 precognition - i.e. can I get lwresd to notice that a server has gone down
 or has come back up without it needing to be triggered by a resolv
 request.
 
 3. Does anybody know if I can configure lwresd to expect particular zones
 to be resolved within very small windows and use this to fail over to the
 next server.
 
 And for discussion I wonder if there would be room to add to the resolver
 code and or lwresd additional options of the form
 
 options zone-timeout: xxx.com:1usec
 
 or something similar, whereby the resolver could be told that if the cache
 does not respond within this time about that particular zone then it can
 be assumed that the server is misbehaving.
 
 Thank you for your attention
 
 Regards, Howard.
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: BIND 9.7.1 + DLZ + DNSSEC: Possible?

2010-09-14 Thread Kalman Feher
Sign them offline or out of band using a database trigger to initiate the
signing. Your schema might need to change a little though.

For a ccTLD, your private key should probably be secure and offline anyway.
Zone updates should be reasonably automatable using either the BIND dnssec
tools or any of the other toolsets out there.. OpenDNSSEC is the another I¹m
familiar with, but there are more.

Getting that signed zone back into your database is the trick. I¹m not that
familiar with the DLZ backend, but if it can slave a zone from any DNS
server, then you set it up as a secondary to whatever is signing your zones.
If that can¹t be done, you¹ll need to parse the zone file to insert the
records into your live domain table.


On 14/09/10 9:46 PM, Kevin Mai k...@mrecic.gov.ar wrote:

 We have an average of around 11 QPS but we update zones daily (our servers
 store NS delegations mostly and government sites) so it's a daily task to
 approve new domains and update/reload zones.
 
 We have a good DB infrastructure built in and the fact of having a MySQL
 server that can replicate is a good reason to have DLZ as the backend.
 
 The other issue we face is signing the zone files, as we are looking forward
 to harden security and sign the .ar ccTLD and the other TLDs (.com.ar,
 .mil.ar, .gov.ar, net.ar, etc). We can sign zone files, but how do we sign
 database entries?
 
 
 De: Scott Haneda talkli...@newgeo.com
 Para: Kevin Mai k...@mrecic.gov.ar
 CC: bind-users@lists.isc.org
 Enviados: Martes, 14 de Septiembre 2010 16:40:05
 Asunto: Re: BIND 9.7.1 + DLZ + DNSSEC: Possible?
 
 On Sep 14, 2010, at 12:15 PM, Kevin Mai k...@mrecic.gov.ar wrote:
 
 My name is Kevin and I'm working with the Argentina ccTLD team to upgrade our
 local NS systems and our goal is to load the .ar, .com.ar and subsequent
 zones using DLZ. Our other task was to deploy DNSSEC here and start signing
 our TLDs, but according to the e-mails I've read (dated 2006 mostly) it's not
 very clear if it's already been possible (it's been 4 years since those
 e-mails were written).
 
 For that reason, I'd need to know if anyone has deployed DNSSEC and signed
 zones and then stored those RRSIG, NSEC and DNSKEY records on a MySQL backend
 using DLZ as a way to get those entries dinamically.
 
 I'd really appreciate your replies :)
 
 I've been dealing with DLZ systems for the better part of a few years now.
 Unless something has changed I am not aware of in the last 12 months, I can
 offer a few suggestions.
 
 Make sure you test load. Find the fastest reading DB backend you are
 comfortable with. Then performance test it. The load of a medium to heavy
 system on the database is significant.
 
 Doing 1000's of DNS lookups per second on a non DLZ system is generally not
 too hard to build out. Doing 1000's of selects on a database, DLZ or not, is
 significantly more challenging.
 
 Keep in mind, 1 lookup generally is not 1 database lookup in DLZ, but will
 take a few to get the final answer.
 
 I find DLZ really shines when you are adding and removing domains often and
 need instant access to those changes. If you are not making many changes to
 your records, the performance hit is not worth the ease of records management
 you gained. 
 
 If reloading named starts to take too long, DLZ will come into play. You will
 more than likely want to look at ways of distributing multiple DLZ systems.
 
 There is a competing product for which I have no experience with. I'm sure you
 can find it in google. I would explore the pros and cons of any alternative
 system as well as BIND/named standalone, and of course a DLZ backed method.
 
 I have never had to implement signed zones before. If that data is within the
 zone, I see no reason why DLZ would not be able to return the correct
 response. 

-- 
Kal Feher 

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

Re: AW: Limitation on concurrently handled queries

2010-08-11 Thread Kalman Feher
Perhaps you could explain the reasoning behind the request? If you are
trying to preserve resources there are better ways.

If you are trying to restrict access to master/slave zones then you should
use access lists, either at zone or view level.


On 11/08/10 3:42 PM, Dangl, Thomas thomas.t.da...@siemens.com wrote:

 First of all thanks for the fast response.
 
 Maybe I misunderstood the Bind9 manual.
 Bind9 ARM says:
 
 recursive-clients The maximum number of simultaneous recursive lookups the
 server will perform on
 behalf of clients
 
 I understand that as recursive lookups that are issued to other name servers.
 The statement in the documentation and the parameter name doesn't say anything
 on iterative queries. And I read that statement - maybe I need new glasses -
 as a limitation applicable to forwarded lookups not resolved by the DNS master
 / slave zones locally available. So in my understanding it doesn't cover what
 I want.
 
 Best Regards
 
 Thomas Dangl
  
 
 -Ursprüngliche Nachricht-
 Von: bind-users-bounces+thomas.t.dangl=siemens@lists.isc.org
 [mailto:bind-users-bounces+thomas.t.dangl=siemens@lists.isc.org] Im
 Auftrag von Matus UHLAR - fantomas
 Gesendet: Mittwoch, 11. August 2010 15:28
 An: bind-users@lists.isc.org
 Betreff: Re: Limitation on concurrently handled queries
 
 On 11.08.10 15:01, Dangl, Thomas wrote:
 is there a means to limit the number of concurrently handled queries?
 In the Bind9 documentation there are some parameters like
 clients-per-query and max-clients-per-query as well as tcp-clients.
 What I didnt see is some limitation on the overall number of queries
 that may be handled concurrently.
 
 what's the point?
 
 there's also recursive-clients option, maybe it's what you want?
 
 --
 Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
 Warning: I wish NOT to receive e-mail advertising to this address.
 Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
 The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
 ___
 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

-- 
Kal Feher 

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


Re: BIND integration with windows DNS

2010-07-27 Thread Kalman Feher



On 27/07/10 8:10 AM, Arnoud Tijssen atijs...@ram.nl wrote:

 I`m facing kind of a challenge. At the moment we have BIND and windows DNS
 within our corporate network.
 
 I would like to get rid of windows DNS and switch completely over to BIND, but
 since DNS is so intertwined with AD this is not an option since it probably
 introduces more problems then it solves
 
 So my next option was to delegate all the windows specific subdomains (i.e.
 _tcp.example.com, _udp.example.com, _sites.example.com, _msdcs.example.com
 etc.) to windows DNS for dynamic updates and let the main domain,
 .example.com, reside on BIND. After setting up BIND and windows DNS and
 removing the main domain entry from the windows DNS servers, leaving only the
 windows specific subdomains, and pointing the dns resolvers of windows to the
 BIND servers the windows clients were unable to register themselves within DNS
 and AD properly. It seems the clients register themselves in the main zone
 file of the domain, which resides on BIND.
 
 Since I don`t want all dynamic updates from windows clients polluting my main
 zone file, but still want one primary DNS serving the main domain instead of
 two, BIND and windows, what it is the best option if there is one.
 
Create a subdomain for your clients and delegate it to the Windows servers,
who will then receive the updates.

 Any advise would greatly be appreciated.
 
 Cheers,
 Arnoud
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: How do I get from IANA's root-anchors.xml to managed-keys{}?

2010-07-17 Thread Kalman Feher
My earlier post described altering the format and included the file  
that anchors2keys would work with.




Kal Feher

On 17/07/2010, at 23:46, Stephane Bortzmeyer bortzme...@nic.fr  
wrote:



On Fri, Jul 16, 2010 at 01:57:05PM +,
ALAIN AINA aal...@trstech.net wrote
a message of 20 lines which said:


https://itar.iana.org/instructions/


It does not work, it was only for ITAR and the published Trust Anchor
uses a different format:

% ./anchors2keys -v root-anchors.xml
No DNSKEYs found, quitting

That's because the XML elements in the file have different names.

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


Re: How do I get from IANA's root-anchors.xml to managed-keys{}?

2010-07-16 Thread Kalman Feher
As a once off I did the following last night. (yes I know the DNSKEY would
have been fine too). anchors2keys worked fine so long as the format was
correct so...
I just cut and pasted the content of :
https://data.iana.org/root-anchors/root-anchors.xml

Zone to delegation, algorithm, digest type and keytag to their corresponding
fields. And digest between the delegation/delegation tags. The serial
was last night's root serial, but it has no effect on the conversion

Here was my file contents:
 cat root-anchor.xml
?xml version=1.0?zone name=. serial=2010071500delegation
name=.ds algorithm=8 digesttype=2
keytag=1903649AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8
FB5/ds/delegation/zone

anchors2keys  root-anchor.xml  root-anchor
 
Which became:
cat root-anchor 

trusted-keys {
.. 257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI
0
EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/Q
Zxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hO
A2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8
ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;
};

Yes the script appends the zone to the delegation. I was too lazy to fix
it in the script. I just changed the resulting trust anchor entry to this:

managed-keys {
. initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI
0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/
QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5h
OA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub
8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;
}; 
include it in named.conf.
Done. 

I'll now check Stephane's tool. Which might be more sensible.

On 16/07/10 10:56 AM, Hauke Lampe la...@hauke-lampe.de wrote:

 
 Greetings, everyone.
 
 Now that the signed root is finally in production, how do I initialize BIND's
 RFC5011 key management from the XML file published by IANA?
 
 I downloaded the files and checked the PGP signature:
 
 http://data.iana.org/root-anchors/root-anchors.xml
 http://data.iana.org/root-anchors/root-anchors.asc
 
 The XML file contains a DS hash of the root KSK, but BIND needs a public key
 in the managed-keys clause.
 
 Are there any tools to retrieve the DNSKEY and validate it with the hash? Or
 even process the XML directly?
 
 So far I used unbound to bootstrap the key but I am looking for a simpler way.
 
 
 
 Hauke.
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: ad flag for RRSIG queries

2010-07-14 Thread Kalman Feher
Using bind 9.7.1. w/ IANA test bed and not DLV:
dig +dnssec rrsig www.iis.se

;  DiG 9.7.1  +dnssec rrsig www.iis.se
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 49621
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;www.iis.se.IN  RRSIG

;; ANSWER SECTION:
www.iis.se. 60  IN  RRSIG   NSEC 5 3 14400
20100723102502 20100713102502 3932 iis.se.
n+0mfgfl9Ov76DZlF6BZoyGNJSc3GX/RFTaWOVStNIqPPGW13b/zuvBr
ml3g556jt6GibbVp5apJ3FuQeqI9v6U4SOA36AqjhE5zMhbx2w+gAyez
5DDPyr1NOCC6E0f0cPGYj48O/aNIEXJKjyTJ0vwuwwLYiDt7jI8CNxcD Zec=
www.iis.se. 60  IN  RRSIG    5 3 3600 20100723102502
20100713102502 3932 iis.se.
EOM2vHFm1XrQYe3xyiT+CCLU49XljlFpZzFUKZZWZb2l6hRjh9OnrTYJ
bP817UA2OgKEs4Pdp6ZugQIiYhAViRd6EMlMPSyb+9YHCMioQ7JLrxfY
D9K4BJOAmtBFpzL4laG5SltCx9FEesIWAYOySApVmM+uTBoRDXBHK23Z 9aw=
www.iis.se. 60  IN  RRSIG   A 5 3 60 20100723102502
20100713102502 3932 iis.se.
MF5Qq5yBzQ+ZvDvcfGBoVn6ym3EzCOVVqQY2ghVxBoSCQ9Hrh1/0nOj9
39Mr5incAefjg0mXSSvDo9WqFUm1cqUcQ4UJuOoT7VzDiC2OilAxr2xe
fo6pivkNlHGIPzbXjSrq65292YIKgQnPXleTtH4HepUmn6bESQI/ioaB 9xk=
 
and the other domain

 dig +dnssec -t RRSIG www.forfunsec.org

;  DiG 9.7.1  +dnssec -t RRSIG www.forfunsec.org
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 8864
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;www.forfunsec.org. IN  RRSIG

;; ANSWER SECTION:
www.forfunsec.org.  3291IN  RRSIG    7 3 36000
20100813101841 20100714101841 50402 forfunsec.org.
ixahCFi//d5CBf0ScxkwcYSCZv+RhfckdVscoVLxov6BGQ8F+skuy/AS
WB69Dt9Q5uKjFGPNLmAnBbLL+f5ShQ/0VXAoyHCKRtiBofNFDK19VfvI
y03pKjRYhAewZq5ztNzmMWH6pI014l4t6FX+Axj0dRWown6Ep0+MRYJF pGg=
www.forfunsec.org.  3291IN  RRSIG   SSHFP 7 3 86400
20100813101841 20100714101841 50402 forfunsec.org.
diOATJqAlbwIljg6ZcFxpsMPObTo8wmXyMORzZxErWxnFbpcks+ePx1t
cmxKvmTKTGJ15yVab6aV+BLbxKwpIHeXLttBvWVH49twAeQrurnHmOfE
UPSUzxu7bpG2czbNXk2bKuG8MyRC6Oep50sY1/ZdzAv0PN6BUokEAyJG PvQ=
www.forfunsec.org.  3291IN  RRSIG   A 7 3 3600 20100813101841
20100714101841 50402 forfunsec.org.
Gkk25aX2wRSwwEqAvazUqmdWXW9P7iW/j2LcRbuUnJnEleQYr2OWuLNf
60spJ2xFI7zD10DQcgXBnjU4lf4qozOd9w9iNzzAqFOyZ5EftSv0j2Go
BZZQWAztx/JLoFyLC8EkygySl4APxWTxbb5J4FWyMuSRlG392DBDL/GS 4FI=


So it looks ok from my box.

On 14/07/10 10:49 AM, Marco Davids (SIDN) marco.dav...@sidn.nl wrote:

 On 07/14/10 00:43, Doug Barton wrote:
 
 Can anyone explain to me why the 'ad'-flag is set for this query?
 
 dig +dnssec -t RRSIG www.forfunsec.org
 
 I use BIND 9.7.0rc1, configured to work with the IANA testbed.
 
 I'd be interested to see what happens if you upgrade to the latest
 versions in each branch (the 9.7.x server above
 What you're seeing sounds like a bug, hopefully one that's been fixed
 (as it seems to be in 9.7.1-P1).
 
 I just upgraded one machine to 9.7.1-P1 (configured to use DLV).
 
 Same result...
 
 ;  DiG 9.7.1-P1  +dnssec rrsig www.iis.se @localhost
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48545
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;www.iis.se.   IN RRSIG
 
 ;; ANSWER SECTION:
 www.iis.se.  6 IN RRSIG A 5 3 60 20100723102502 20100713102502 3932
 iis.se. MF5Qq5yBzQ+ZvDvcfGBoVn6ym3EzCOVVqQY2ghVxBoSCQ9Hrh1/0nOj9
 39Mr5incAefjg0mXSSvDo9WqFUm1cqUcQ4UJuOoT7VzDiC2OilAxr2xe
 fo6pivkNlHGIPzbXjSrq65292YIKgQnPXleTtH4HepUmn6bESQI/ioaB 9xk=
 
 ;; AUTHORITY SECTION:
 iis.se.   3545 IN NS ns2.nic.se.
 iis.se.   3545 IN NS ns.nic.se.
 iis.se.   3545 IN NS ns3.nic.se.
 iis.se.   3545 IN RRSIG NS 5 2 3600 20100723102502 20100713102502 3932
 iis.se. JRJ11qCnEFgVFY0ZDfevfd7Colywb7tlgFXWXOjq0ikqCX8lvcIBKbik
 RQ+NqwBsHE4aa4E9QLVaruFTg+5tYIKWdonDjk8Kon+8f4oAf9cy9Yjs
 Ldg0N6wa2HsTlHAq+EdlvXKgZvs8qCkY87iwkVLqn0bp704yacQhVKIQ yXA=
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Wed Jul 14 04:46:41 2010
 ;; MSG SIZE  rcvd: 428
 
 
 dig +short chaos txt version.bind @localhost
 9.7.1-P1
 
 --
 Marco
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: ad flag for RRSIG queries

2010-07-14 Thread Kalman Feher
Using the ORG trust anchor from the ITAR yields the following result on
9.7.1 (no P1 patch). No initial time out.

 # dig +dnssec -t RRSIG www.forfunsec.org

;  DiG 9.7.1  +dnssec -t RRSIG www.forfunsec.org
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 1280
;www.forfunsec.org. IN  RRSIG

www.forfunsec.org.  3599IN  RRSIG   A 7 3 3600 20100813101841
20100714101841 50402 forfunsec.org.
Gkk25aX2wRSwwEqAvazUqmdWXW9P7iW/j2LcRbuUnJnEleQYr2OWuLNf
60spJ2xFI7zD10DQcgXBnjU4lf4qozOd9w9iNzzAqFOyZ5EftSv0j2Go
BZZQWAztx/JLoFyLC8EkygySl4APxWTxbb5J4FWyMuSRlG392DBDL/GS 4FI=
www.forfunsec.org.  3599IN  RRSIG    7 3 36000
20100813101841 20100714101841 50402 forfunsec.org.
ixahCFi//d5CBf0ScxkwcYSCZv+RhfckdVscoVLxov6BGQ8F+skuy/AS
WB69Dt9Q5uKjFGPNLmAnBbLL+f5ShQ/0VXAoyHCKRtiBofNFDK19VfvI
y03pKjRYhAewZq5ztNzmMWH6pI014l4t6FX+Axj0dRWown6Ep0+MRYJF pGg=
www.forfunsec.org.  3599IN  RRSIG   SSHFP 7 3 86400
20100813101841 20100714101841 50402 forfunsec.org.
diOATJqAlbwIljg6ZcFxpsMPObTo8wmXyMORzZxErWxnFbpcks+ePx1t
cmxKvmTKTGJ15yVab6aV+BLbxKwpIHeXLttBvWVH49twAeQrurnHmOfE
UPSUzxu7bpG2czbNXk2bKuG8MyRC6Oep50sY1/ZdzAv0PN6BUokEAyJG PvQ=


On 14/07/10 3:34 PM, Tony Finch d...@dotat.at wrote:

 On Wed, 14 Jul 2010, Chris Thompson wrote:
 
 With 9.7.1-P1 (and a trust anchor for dlv.isc.org) on a local workstation
 
  dig +dnssec -t RRSIG www.forfunsec.org @127.0.0.1
 
 initially times out. But after doing
 
  dig +dnssec -t ANY www.forfunsec.org @127.0.0.1
 
 the same command reports the three RRSIG records (for A,  and SSHFP
 types) that got into its cache, and it does set the ad bit in that
 response.
 
 I see the same for bind-9.7.1.
 
 Was a release announcement sent out for 9.7.1-P1? We didn't receive one here.
 
 Tony.

-- 
Kal Feher 

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


Re: reason for expected covering NSEC3, got an exact match ?

2010-07-13 Thread Kalman Feher
It looks like normal NSEC to me, unless you are referring to an isolated
copy of the domain not accessible to the public:

;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 22416
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.lu. IN  TXT

;; AUTHORITY SECTION:
dnssec.lu.  300 IN  SOA ns1.restena.lu.
hostmaster.restena.lu. 2008110708 3600 300 1209600 300
dnssec.lu.  300 IN  RRSIG   SOA 5 2 3600 20081207145334
20081107145334 23997 dnssec.lu.
kH1rP6S1AIBEe5LoZN+b4f+IfRB48LcMMbfHUAsAP6Pp+7gLIiJwNWfK
u5GEgjMlsiO6irarcAfugWd3hkjbThPXpN7mgCxQa35FIluxCkmW7bRr
WD78Tg4RMGmKJyFzzNA/m6Vxi9O04fjgk0tlxhoE0MTTsvWP++3ungVO KsU=
dnssec.lu.  300 IN  NSEC*.dnssec.lu. NS SOA RRSIG
NSEC DNSKEY
dnssec.lu.  300 IN  RRSIG   NSEC 5 2 300 20081207145334
20081107145334 23997 dnssec.lu.
HVMxwETY/E1EiVfAHcA/zqiCnntg1Eh9CCQzgPLjbqC32Heu9eASgUjT
hQcpImO2ehXWNFMKGOPobMqY8AQIKQP0AZ3QLNsYHtyD+tDcJhIQ7HHJ
ihAXe5Tg6cFqXWE1ACD3KEekWsAxCvZtBNY8FC+a0oVLiZQlxb7Sufdy o6s=



On 13/07/10 2:28 PM, Gilles Massen gilles.mas...@restena.lu wrote:

 Hello,
 
 I have a signed zone (dnssec.lu) with NSEC3 / no optout, signed through
 OpenDNSSEC. The zone contains a wildcard with a TXT and A record.
 
 Each time the server is queried for something where the QNAME is matched
 by the wildcard, but the QTYPE is not, named logs a warning: expected
 covering NSEC3, got an exact match.
 
 This behaviour exists only if a wildcard is present in the zone. The
 zone doesn't contain any stale or unnecessary NSEC3 records.
 
 Is there an explanation for the warning? Apart from complaining, bind
 seems to do everything correctly. (Bind 9.7.1 P1)
 
 best,
 Gilles

-- 
Kal Feher | Melbourne IT | Malmö, Sweden | ph: +46 406 919185 | mob: +46 734
224407

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


Re: reason for expected covering NSEC3, got an exact match ?

2010-07-13 Thread Kalman Feher
Ok now I see it.
The response appears ok, but the log entry is odd. I see the same on my test
box (9.7.1 not patched to P1 yet). A brief thread on this occurred earlier
in the year (archived here):
http://newsgroups.derkeiler.com/Archive/Comp/comp.protocols.dns.bind/2010-03
/msg00282.html
 


On 13/07/10 3:10 PM, Gilles Massen gilles.mas...@restena.lu wrote:

 
 Kalman Feher wrote:
 It looks like normal NSEC to me, unless you are referring to an isolated
 copy of the domain not accessible to the public:
 
 Yes, indeed, sorry about that. I should keep my playgrounds tidier. The
 actual zone is located on nssec.restena.lu, and is publicly queriable
 (even with AXFR).
 
 
 Gilles
 

-- 
Kal Feher | Melbourne IT 

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


Re: R: Does bind send email?

2010-07-09 Thread Kalman Feher
Since you now know that BIND doesn't send email and its possible to name a
virus whatever the virus writer wishes, it might be prudent to compare the
file with a known good version from here (check signatures):
ftp://ftp.isc.org/isc/bind9/

While off topic for this forum, you should also try netstat -o to identify
the process sending on port 25.


On 9/07/10 3:09 PM, Chiesa Stefano stefano.chi...@wki.it wrote:

 A couple of details:
 
 * bind is working fine and on the server the Task Manager shows just one
 named.exe process (show processes from all users checked)
 * I don't' think McAfee is triggering on MX lookups because he's blocking
 connection on port 25  (look at the end of log line:  187.58.17.194:25)
 
 08/06/2010 23.31.19 1094 C:\bind\bin\named.exe Protezione antivirus
 standard:Impedisci a worm distribuiti tramite mass-mailing di inviare
 messaggi 187.58.17.194:25
 
 Regards.
 Stefano.
 
 -Messaggio originale-
 Da: bind-users-bounces+stefano.chiesa=wki...@lists.isc.org
 [mailto:bind-users-bounces+stefano.chiesa=wki...@lists.isc.org] Per conto di
 Phil Mayers
 Inviato: venerdì 9 luglio 2010 14.23
 A: bind-users@lists.isc.org
 Oggetto: Re: Does bind send email?
 
 On 09/07/10 12:18, tomasz dereszynski wrote:
 
 
 check below link
 apparently viruses (some) hide themselves behind that name/process.
 http://www.file.net/process/named.exe.html
 
 mind you, it might be something else ...
 
 
 Maybe McAfee is triggering on MX lookups?
 ___
 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

-- 
Kal Feher

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


Re: bind says 'clocks are unsynchronized' but they are not

2010-07-07 Thread Kalman Feher

If you really do have such a small pipe (with your email address I assume
Sweden. I didn't think Swedes even knew there were link types other than
fibre ;) )then perhaps you're throttling it to the point where your NTP sync
drops off. 
Options:
Perhaps try some traffic shaping on the link. IXFR or any other bandwidth
friendly alternative as suggested below or perhaps an internal NTP server.

On 7/07/10 4:17 PM, Sven Eschenberg s...@whgl.uni-frankfurt.de wrote:

 Hi,
 
 The size of the zone should not be that much of a matter if you use
 IFXR. Aside from that, did you ever consider using another mechanism for
 synchronization, like rsync or lzmaing the zone and transferring it via
 your protocol of choice?
 Then again, why would one have a TLD coloc on a 256kbps line, that seems
 very unreasonable.
 
 Regards
 
 -Sven
 
 
 On Wed, 2010-07-07 at 14:58 +0200, Niklas Jakobsson wrote:
 Hello,
 
 On ons, 2010-07-07 at 14:41 +0200, Tom Schmitt wrote:
  Original-Nachricht 
 Datum: Wed, 07 Jul 2010 13:13:45 +0200
 Von: Niklas Jakobsson n...@autonomica.se
 An: bind-us...@isc.org
 Betreff: bind says \'clocks are unsynchronized\' but they are not
 
 Hello,
 
 I have some problems with our bind servers complaining that 'clocks are
 unsynchronized' when doing zone transfers with TSIG. The problem is the
 clocks are correct, synced with ntp and everything.
 
 Maybe one of the two servers doing the zone transfer is running in a chroot
 where it has another time setting than the server itself?
 
 
 Not running any chroot.
 
 
 
 The problems seems to occur mostly on zone transfers that take a long
 time (ie. hours).
 
 
 HOURS??
 There is defnitly something wrong. I cannot imagine a zone so big or a
 connection so slow that a zonetransfer could take hours. Or do you make a
 axfr of the tld com. over a serial connection?  ;-)
 
 
 Tom.
 
 
 Size of a tld that should not be named: 256947194 bytes
 Speed of connection to a site very far away: 256 kbit/s
 
 256947194/(256*1000/8)/60/60 = 2.23 ~ little over 2 hours...
 
  /Nico
 
 
 ___
 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

-- 
Kal Feher 

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


Re: Nsupdate -l not using session.key

2010-07-01 Thread Kalman Feher

I was obviously especially tired yesterday when I tested this.

Anyway BIND was chroot'd and user wasn't.

(slaps forehead)

Problem solved.


On 30/06/10 6:07 PM, Kal Feher kalman.fe...@melbourneit.com.au wrote:

 
 
 
 On 30/06/10 5:25 PM, Alan Clegg acl...@isc.org wrote:
 
 On 6/30/2010 11:13 AM, Kalman Feher wrote:
 While testing bind 9.7.1 features including automated signing and
 update-policy local. I encountered some strange behaviour using nsupdate -l.
 
 When using nsupdate -l I was not able to update the zone in question and the
 following error was generated:
 update-security: error: client 127.0.0.1#9292: view internal: update
 'star/IN' denied
 
 Any suggestions?
 
 Send your named.conf
 Named.conf:
 
 acl xfer {
 
 none;
 };
 acl trusted {
 127.0.0.0/8;
 ::1/128;
 10.115.160.0/22;
 };
 options {
 directory /var/bind;
 pid-file /var/run/named/named.pid;
 bindkeys-file /etc/bind/bind.keys;
 listen-on-v6 { none; };
 listen-on port 53 { any; };
 allow-query {
 trusted;
 };
 allow-query-cache {
 trusted;
 };
 allow-transfer {
 xfer;
 };
 dnssec-enable yes;
 
 };
 logging {
 channel default_log {
 file /var/log/named/named.log versions 5 size 50M;
 print-time yes;
 print-severity yes;
 print-category yes;
 };
 channel query_log {
 file /var/log/named/query.log versions 5 size 100M;
 print-time yes;
 print-severity yes;
 print-category yes;
 };
 channel dnssec_log {
 file /var/log/named/dnssec.log versions 5 size 100M;
 print-time yes;
 print-severity yes;
 print-category yes;
 };
 channel resolver_log {
 file /var/log/named/resolver.log versions 5 size 50M;
 print-time yes;
 print-severity yes;
 print-category yes;
 };
 category default { default_log; };
 category general { default_log; default_syslog; };
 category queries { query_log; };
 category dnssec  { dnssec_log; };
 category resolver { resolver_log; };
 };
 include /etc/bind/rndc.key;
 controls {
 inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys {
 rndc-key; };
 };
 view internal in {
 match-clients { trusted; };
 recursion yes;
 additional-from-auth yes;
 additional-from-cache yes;
 
 zone . in {
 type hint;
 file /var/bind/root.cache;
 };
 zone localhost IN {
 type master;
 file pri/localhost.zone;
 allow-update { none; };
 notify no;
 allow-query { any; };
 allow-transfer { none; };
 };
 
 zone 127.in-addr.arpa IN {
 type master;
 file pri/127.zone;
 allow-update { none; };
 notify no;
 allow-query { any; };
 allow-transfer { none; };
 };
 
 zone star IN {
 type master;
 auto-dnssec maintain;
 update-policy local;
 dnssec-secure-to-insecure no;
 file pri/star/star.zone.signed;
 key-directory pri/star;
 notify no;
 allow-query { any; };
 allow-transfer { none; };
 };
 zone COM { type delegation-only; };
 zone NET { type delegation-only; };
 };
 
 view public in {
 
 match-clients { any; };
 recursion no;
 additional-from-auth no;
 additional-from-cache no;
 
 zone . in {
 type hint;
 file /var/bind/root.cache;
 };
 
 };
 view chaos chaos {
 match-clients { any; };
 allow-query { none; };
 zone . {
 type hint;
 file /dev/null; };
 };
 
 
 AlanC
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Nsupdate -l not using session.key

2010-06-30 Thread Kalman Feher
While testing bind 9.7.1 features including automated signing and
update-policy local. I encountered some strange behaviour using nsupdate -l.

When using nsupdate -l I was not able to update the zone in question and the
following error was generated:
update-security: error: client 127.0.0.1#9292: view internal: update
'star/IN' denied

However: 
nsupdate -k var/run/named/session.key
 server 127.0.0.1
Worked fine.

Note that the session.key is at the default location. Reading the 97ARM it
doesn't appear that I need to specify the location of this file, since its
created automatically where I and more importantly nsupdate expect it to be.

Any suggestions?
-- 
Kal Feher 

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


Re: Nsupdate -l not using session.key

2010-06-30 Thread Kalman Feher



On 30/06/10 5:25 PM, Alan Clegg acl...@isc.org wrote:

 On 6/30/2010 11:13 AM, Kalman Feher wrote:
 While testing bind 9.7.1 features including automated signing and
 update-policy local. I encountered some strange behaviour using nsupdate -l.
 
 When using nsupdate -l I was not able to update the zone in question and the
 following error was generated:
 update-security: error: client 127.0.0.1#9292: view internal: update
 'star/IN' denied
 
 Any suggestions?
 
 Send your named.conf
Named.conf:

acl xfer {

none;
};
acl trusted {
127.0.0.0/8;
::1/128;
10.115.160.0/22;
};
options {
directory /var/bind;
pid-file /var/run/named/named.pid;
bindkeys-file /etc/bind/bind.keys;
listen-on-v6 { none; };
listen-on port 53 { any; };
allow-query {
trusted;
};
allow-query-cache {
trusted;
};
allow-transfer {
xfer;
};
dnssec-enable yes;

};
logging {
channel default_log {
file /var/log/named/named.log versions 5 size 50M;
print-time yes;
print-severity yes;
print-category yes;
};
channel query_log {
file /var/log/named/query.log versions 5 size 100M;
print-time yes;
print-severity yes;
print-category yes;
};
channel dnssec_log {
file /var/log/named/dnssec.log versions 5 size 100M;
print-time yes;
print-severity yes;
print-category yes;
};
channel resolver_log {
file /var/log/named/resolver.log versions 5 size 50M;
print-time yes;
print-severity yes;
print-category yes;
};
category default { default_log; };
category general { default_log; default_syslog; };
category queries { query_log; };
category dnssec  { dnssec_log; };
category resolver { resolver_log; };
};
include /etc/bind/rndc.key;
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys {
rndc-key; };
};
view internal in {
match-clients { trusted; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;

zone . in {
type hint;
file /var/bind/root.cache;
};
zone localhost IN {
type master;
file pri/localhost.zone;
allow-update { none; };
notify no;
allow-query { any; };
allow-transfer { none; };
};

zone 127.in-addr.arpa IN {
type master;
file pri/127.zone;
allow-update { none; };
notify no;
allow-query { any; };
allow-transfer { none; };
};

zone star IN {
type master;
auto-dnssec maintain;
update-policy local;
dnssec-secure-to-insecure no;
file pri/star/star.zone.signed;
key-directory pri/star;
notify no;
allow-query { any; };
allow-transfer { none; };
};
zone COM { type delegation-only; };
zone NET { type delegation-only; };
};

view public in {

match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;

zone . in {
type hint;
file /var/bind/root.cache;
};

};
view chaos chaos {
match-clients { any; };
allow-query { none; };
zone . {
type hint;
file /dev/null; };
};

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

-- 
Kal Feher 

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


Re: Preparing for upcoming DNSSEC changes on 5/5

2010-05-03 Thread Kalman Feher



On 1/05/10 7:10 PM, Server Administrator server53a...@gmail.com wrote:

 I tried OARC's DNS Reply Size Test on two of my name servers, both on
 the same network, behind the same firewall  router.
 
 Both came back and reported DNS reply size limit is at least 3843
 (results below).
 
 Is 3843 close enough to 4096 to keep me safe next Wednesday (May 5th)?
  If not, do the required remedies need to be applied in named.conf, or
 the router  firewall?  And if the latter, what, specifically, needs
 to be configured?
 
It really depends on what those remedies are...

First, consider the fact that a low UDP response will result in a TCP
attempt occasionally (when the response is greater that your effective
limit). So you should ensure that you can resolve queries using TCP. On the
occasions when TCP is not possible, it is regularly caused by intervening
network devices. So check firewalls and routers for filters that do not
allow DNS over TCP.

Also check for devices that inspect DNS queries. They can have some out of
date assumptions regarding sizes.

Second, make sure the tested effective size appears in your named.conf in
the options statement edns-udp-size on your resolver.

In your case:
 edns-udp-size 3843;

Finally, note that UDP is preferable for DNS so ensuring the largest
possible size will reduce the occurrence of TCP. Take a look at your
firewall settings for connection timeouts and consider what would happen if
all the short lived DNS UDP connections were suddenly replaced by longer
lived TCP connections.

 Other than OARC's page are there any sites that describe everything
 that needs to be done and checked to make sure we're good to go on
 5/5?
 

It appears you are good to go.



-- 
Kal Feher 

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


Re: Preparing for upcoming DNSSEC changes on 5/5

2010-05-03 Thread Kalman Feher

On 3/05/10 7:34 PM, Lightner, Jeff jlight...@water.com wrote:


 There is no EDNS entry in my named.conf.  Do I need one, given that
 above worked?
You probably should. Your resolver is saying its capable of handling 4096,
but apparently your network path may not support that. The changes on the
5/5 will not require it however.
 
 The article (apparently he got it from our common manager) is one I've
 not seen but I'm assuming it was The Register article or something
 referring to it.   Most of my reading since I sent the email suggests as
 you did that I don't need to do anything and that the original article
 was written in an overly alarmist fashion.

Yes. We've had several customers contact us in a panic after reading that
article. Most people will be fine. But there's nothing wrong with learning
about the upcoming changes. Unfortunately articles like that do not assist
in spreading accurate information.

 
 Is there other testing I need to do?
No.
 
 
 -Original Message-
 From: bind-users-bounces+jlightner=water@lists.isc.org
 [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
 Of Alan Clegg
 Sent: Monday, May 03, 2010 12:23 PM
 To: bind-users@lists.isc.org
 Subject: Re: Preparing for upcoming DNSSEC changes on 5/5
 
 On 5/3/2010 4:36 PM, Lightner, Jeff wrote:
 
 It sounds as if he read an article saying we have to implement DNSSEC
 on
 our DNS servers or we'll quit working on 5/5?  Is that the case?
 
 Also what is the drop dead date/time if so?  5/5 Midnight UTC?  Some
 other time?
 
 You don't need to do anything more than be sure that you have a clean
 network path.  There is nothing to do by 5/5 as long as the tests that
 you say worked actually did work.
 
 If you have additional information on the article that he read
 implying that more needs to be done, please provide a link.
 
 Thanks,
 AlanC
  
 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

-- 
Kal Feher 

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


Re: Preparing for upcoming DNSSEC changes on 5/5

2010-05-03 Thread Kalman Feher



On 3/05/10 9:54 PM, Lightner, Jeff jlight...@water.com wrote:

 On doing that however, I now see the advertised value is 3839 but the
 at least value is 3828 on one and 3827 on the other as shown below.
 Based on that it appears one should NOT set the edns-udp-size as it
 doesn't fix the problem.
This appears to be due to the nature of the testing tool.

Refer to the How it works section here:
https://www.dns-oarc.net/oarc/services/replysizetest

You probably won't get an exact match due to its search method.

This may also place doubt on the maximum UDP size you are capable of. The
best way to find out for certain, is to try querying something that is
exactly 4096 and seeing if you get a truncated response (thus switching to
TCP).

Note that this is further investigation is not required for 5/5. But its
always good to understand your network's limits. And may become more useful
in the coming months and years as DNSSEC pushes average query sizes up.


-- 
Kal Feher | Melbourne IT | Malmö, Sweden | ph: +46 406 919185 | mob: +46 734
224407

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


Re: Strange behaviour with DNSSec

2010-03-08 Thread Kalman Feher
Can you provide the domain name and an example of the problem?
That will help in identifying the issue.

On 8/03/10 11:21 AM, bsd b...@todoo.biz wrote:

 Hello, 
 
 
 I am running an important subzone of .museum zone (which implements both
 DNSSec and IDN) and I have a strange behavior going onŠ
 
 Some requests seems not to be resolved correctly with certain operatorsŠ
 One out of six requests are not resolved correctly.
 
 Instead of giving the answer of the request, It returns the SOA recordŠ
 
 
 I use to run the latest bind 9.5.x branch.
 I have moved this morning to 9.7.x branchŠ hopping this might help solving my
 problem. 
 
 
 Any idea how to test / investigate that furtherŠ
 
 
 Sincerely yours. 
 
 
 Gregober --- PGP ID -- 0x1BA3C2FD
 bsd @at@ todoo.biz
 
 
 P Please consider your environmental responsibility before printing this
 e-mail
 
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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