Re: Akadns and Bind
On 4/02/11 3:07 AM, "Tory M Blue" wrote: > On Thu, Feb 3, 2011 at 5:23 PM, Barry Margolin wrote: >> In article > 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 @ 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.o
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 25/01/11 11:20 PM, "Mark Andrews" wrote: > > In message , Kalman Feher > write > s: >> >> >> >> On 25/01/11 4:10 PM, "Alan Clegg" 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
On 25/01/11 4:10 PM, "Alan Clegg" 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
On 25/01/11 2:34 PM, "Zbigniew Jasiński" 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.NSEC
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 24/01/11 4:08 PM, "Zbigniew Jasiński" 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
On 24/01/11 10:53 AM, "Zbigniew Jasiński" 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 > > 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 > ) ; key id = 41870 > DNSKEY 257 3 10 ( > AwEAAdFituIkCms1lVbht+ykmwRUoBQJjHW9qep2GS1O > ) ; 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
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 21/01/11 2:05 PM, "Zbigniew Jasiński" 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
>
>
> 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/
>
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
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" 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 > > add example. 3600IN RRSIG DNSKEY 10 1 3600 > 20110218225336 20110119215336 57636 example. > SfFa5xjRtb/VBm3Zv1j31VRlqJORM0laX1PuZ+Asi6IFutH4q5TeknYN > > add example. 3600IN RRSIG SOA 10 1 3600 > 20110218225336 20110119215336 57635 example. > wYZ/nZbnN6HGrWTDLkfbyW4dQGMVs1ZVY+r8zc9t92ykxu7ipycxnITW > > > 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
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" 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 > > 256 3 10 AwEAAa/sFWJDcylO33IQWnpKEve661t0S/K8+AWPy+PSq69xo27WUGRN > > > 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 auto-dnssec issue bind-9.7.2-P3
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.
On 17/01/11 2:47 PM, "Zbigniew Jasiński" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Hi all,
>
> I have my test zone example configured with option auto-dnssec maintain;
>
> zone "example" {
> type master;
> file "var/zone/example";
> allow-update { loopback; };
> allow-transfer { trusted; loopback; };
> auto-dnssec maintain;
> key-directory "var/keys/example";
> };
>
> in server conf there's also 'dnssec-enable yes'
>
> and I've configured keys (KSK/ZSK) with timing options (same for both keys):
>
> ; Created: 20110114150841 (Fri Jan 14 16:08:41 2011)
> ; Publish: 20110114151339 (Fri Jan 14 16:13:39 2011)
> ; Activate: 20110114151839 (Fri Jan 14 16:18:39 2011)
> ; Inactive: 20110114152339 (Fri Jan 14 16:23:39 2011)
> ; Delete: 20110114152839 (Fri Jan 14 16:28:39 2011)
>
> I started bind, send update for my example zone with NSEC3PARAM:
>
> Jan 14 16:08:40 named[25297]: general: zone example/IN:
> dns_zone_addnsec3chain(hash=1, iterations=12, salt=28EA1FFF42617C9D59B1)
> Jan 14 16:08:40 named[25297]: general: zone example/IN:
> zone_addnsec3chain(1,CREATE,12,28EA1FFF42617C9D59B1)
>
> send the rndc sign command:
>
> Jan 14 16:08:41 named[25297]: general: received control channel command
> 'sign example'
> Jan 14 16:08:41 named[25297]: general: zone example/IN: reconfiguring
> zone keys
> Jan 14 16:08:42 named[25297]: general: zone example/IN:
> zone_addnsec3chain(1,REMOVE|NONSEC,12,28EA1FFF42617C9D59B1)
> Jan 14 16:08:42 named[25297]: general: zone example/IN: next key event:
> 14-Jan-2011 16:13:39.200
>
> next key event is scheduled for 16:13:39.200 which is correct, and this
> is the key Publish event:
>
> Jan 14 16:13:39 named[25297]: general: zone example/IN: reconfiguring
> zone keys
> Jan 14 16:13:39 named[25297]: general: zone example/IN: next key event:
> 14-Jan-2011 16:23:39.234
>
> but what with the Activate event??? in log I just see Publish, Inactive
> and Delete events but without Activate event. zone is just no signed by
> named.
>
> If I use default settings when generating keys (Created, Publish,
> Activate = NOW), change 'auto-dnssec maintain' to 'auto-dnssec allow'
> and send 'rndc sign example' zone is signed without problems.
>
> what's going on?
>
> - --
> regards
>
> zbigniew jasinski
> [SYStem OPerator]
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJNNEh0AAoJEH26UYiRhe/g2WoP/i4Ecn5Jq78GFFlJGpde6fyd
> vXN3pwFpWUvDSZqYQfLYMHg4PaI5RNDU2NLfnM0gnMZ83cXz0kw0h9bBj8O/EmXX
> 44+7/wheBnpOijlKItt2IjnBzFKV6uTu6nj5RtpbvTAMTEny0Hy4q41Y8zB8Mt4P
> h0VuTi91q2WmSisa2bYnIKrQzQFR6W+nbPRFpxHyzj3SX2hdoqSBQkbNhmC+nCJR
> nJQQa4u9JKcCtDkQeoRUiUVHNECuZSXMwCukXEagweEadP6EIPhC+TCyUTXKiR7s
> 9jQ/1svVmsKNqqFLgMf2w2x8oKXeAP/PvRzlyZlBwzHHgHBetgPsd1oKcHB9rElM
> /rVNk8nzIadrp0TF7WEy4Ld4GdbwVGbiv0p+vDounPmm4KntwcxyFxpu+PZRs/tp
> zt/z4KYrR+Z+1pNl6ojfg5mD7UTPEmMj9gFHhVuwdrcHP5EH/SkxofDFAB8C0IyX
> LJ3jbKITqmLHhVCDWVLxwXws4/QUOTF/rU48zk1XxaEP80tmKO9PfgCYr4QPz3v4
> UDPMvZyI5r0yqk+V5gxXMjWcbMh9K/lq00Nj4/dXCP9iIlvd0MkKdnfTHuMK5BNN
> OGTrQlVVyGG6+iKU1XXAp0BahVjQnGk46EsKcqUXOjc/4bm/myvfG3WyLFm8okYD
> 412Ik3YKP3YpZvxqc9X6
> =+ZO3
> -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: RT-Number?
On 14/01/11 1:26 PM, "Tom Schmitt" wrote: > I just read the release notes from Bind 9.7.2-P3 and noticed that behind every > short description of a change there is a number beginning with RT. > I hope this is some kind of ticket number were more detailed information about > this change could be found? I think it stands for Request Tracker. ISC's internal tracking system. I recall there being a statement on the website somewhere that the information is not made public. I hope I'm wrong on this. > > My question: > Were do I find these tickets? > (wouldn't make much sense to publish their numbers if the tickets themself > couldn't be read, but I couldn't find them on the ISC homepage) Reposting this to the list, since I replied directly accidently. -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
On 14/01/11 12:51 PM, "Peter Andreev" wrote:
> 2011/1/14 Kalman Feher :
>>
>>
>>
>> On 14/01/11 9:57 AM, "Peter Andreev" wrote:
>>
>>> 2011/1/13 Alan Clegg :
>>>> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>>>>
>>>>> I've executed
>>>>> rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1";
>>>>> };'
>>>>>
>>>>> and have got the file /etc/namedb/3bf305731dd26307.nzf:
>>>>> zone test.test { type master; file "/etc/namedb/master/test.1"; };
>>>>>
>>>>> The question was: can I force rndc addzone to use specific file (for
>>>>> example "/etc/namedb/includes/file2") instead of 3bf305731dd26307.nzf?
>>>>
>>>> No. The file is a hash of the view in which the data resides.
>>>>
>>>> "it's automated, just leave it alone and it won't hurt anyone" :)
>>>>
>>>> AlanC
>>>
>>> Thank you very much, Alan. Could you describe why it was made so?
>>> I asking because this feature could be very helpful for me, but such
>>> restriction does its completely useless.
>> I believe it was related to the difference between legal file names and
>> legal view names. Thus to avoid problems, the view name is hashed.
>>
>> I can't think of a situation where you would not know your view name and
>> that view name would change over time. So if you wish to edit the file in a
>> script, you can still do so, just use the hashed name. But there seems to be
>> a general preference not to change anything in that file by hand or script.
>> And the file naming scheme may change in future releases, if my change log
>> memory is correct.
>
> You haven't understood. I have several includes within one default
> view and I need to add zones to them. Different zones to different
> includes. For me name of view doesn't matter.
Bear in mind that includes make no sense in the context of rndc addzone
functionality. Since include functionality is only relevant when
parsing/reparsing the configuration file. Since the addzone feature bypasses
this to make adding zones not require parsing named.conf, it is circular to
use the include feature applicable to said parsing.
You can still use both methods to add a zone. Just not both to add the same
zone.
Consider why you use those includes, then reconsider those reasons in light
of the addzone function. Most people use includes to:
1.organise files and configs to keep them sane.
2.allow an external system to drop/ configs in a directory
without touching the main config file.
With rndc addzone:
1. Is somewhat improved and worsened. Your zone statements are together and
formatted neatly in a separate file. But comments are absent and zones are
all listed together, without any groupings you may find convenient.
2. The external system would now have to use rndc addzone/delzone to add and
remove the domain.
2.a Since the domain is now dynamic, editing the zone file is now replaced
with nsupdate. The caveat being that the zone statement itself is not
editable as far as I can see. At least not in a manner guaranteed to work in
future releases.
If using nsupdate to edit zone contents or adding domains using rndc, break
your current system or way of doing things, then the feature is not for you.
What were you hoping this feature would give you? Perhaps there is already a
way to achieve it without using the addzone feature..
> I believe that much more flexible and convenient way is to allow users
> to specify file than such non-transparent mechanism which has been
> realised.
>
> And I don't like idea that bind user must have permissions to write to
> namedb directory. For now without such permissions I get "permission
> denied" error when trying to delete zone.
>
>>
>> However, I'm curious regarding your requirements and why this restriction
>> causes them to be broken? For myself I can think of some occasions:
>> 1. Moving from secure to insecure (due to operational changes like transfers
>> between registrars).
>> 2. ACL changes
>>
>> Ideally there would be an "rndc editzone" with similar syntax to addzone.
>> Thus allowing you to update the zone statement without hand/script editing
>> the file. And protecting you from future file name changes.
>>>>
>>>> ___
>>>> 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: rndc addzone and file name
On 14/01/11 9:57 AM, "Peter Andreev" wrote:
> 2011/1/13 Alan Clegg :
>> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>>
>>> I've executed
>>> rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1"; };'
>>>
>>> and have got the file /etc/namedb/3bf305731dd26307.nzf:
>>> zone test.test { type master; file "/etc/namedb/master/test.1"; };
>>>
>>> The question was: can I force rndc addzone to use specific file (for
>>> example "/etc/namedb/includes/file2") instead of 3bf305731dd26307.nzf?
>>
>> No. The file is a hash of the view in which the data resides.
>>
>> "it's automated, just leave it alone and it won't hurt anyone" :)
>>
>> AlanC
>
> Thank you very much, Alan. Could you describe why it was made so?
> I asking because this feature could be very helpful for me, but such
> restriction does its completely useless.
I believe it was related to the difference between legal file names and
legal view names. Thus to avoid problems, the view name is hashed.
I can't think of a situation where you would not know your view name and
that view name would change over time. So if you wish to edit the file in a
script, you can still do so, just use the hashed name. But there seems to be
a general preference not to change anything in that file by hand or script.
And the file naming scheme may change in future releases, if my change log
memory is correct.
However, I'm curious regarding your requirements and why this restriction
causes them to be broken? For myself I can think of some occasions:
1. Moving from secure to insecure (due to operational changes like transfers
between registrars).
2. ACL changes
Ideally there would be an "rndc editzone" with similar syntax to addzone.
Thus allowing you to update the zone statement without hand/script editing
the file. And protecting you from future file name changes.
>>
>> ___
>> 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: DNSKEY NODATA responses not cached
I'm curious whether the domain in question had a DS in the parent zone? On 11/01/11 4:52 PM, "Chris Thompson" wrote: > On Jan 11 2011, Alexander Gall wrote: > >> It appears that NODATA responses for qtype=DNSKEY are not cached if >> DNSSEC validation is enabled (tested with 9.7.2-P3). What is the >> rationale behind this? > > I confirm the effect (same release). Or rather, the NODATA does get cached, > as shown by a "!DNSKEY" count in the statistics display, but a new request > goes back to the authoritative servers again anyway, as shown by the outgoing > queries count and by the SOA in the authority section of the NODATA response > having its original value. -- 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
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" 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: Wrong names for NS and glue records not in the child zone
On 20/12/10 4:18 PM, "Laurent Bauer" wrote: > On 20/12/2010 13:50, Kalman Feher wrote: >>> The registry NS return an authority section like : >>>> domain.tld. IN NS ns1.domain.tld. >>>> domain.tld. IN NS ns2.domain.tld. >>>> and an additional section with these glue records. >>>> >>>> The delegation should be : >>>> domain.tld. IN NS ns1.domain.com. >>>> domain.tld. IN NS ns2.domain.com. >>>> which are also glue records, by the way, but domain.com. resolution is OK. >>>> >>>> Anyway, my cache NS (bind 9.7.1-P2) still resolves A records for >>>> www.domain.tld. I flushed the cache before. >>>> Does it mean that bind ignores the authoritative answer for glue records >>>> and the NS records ? >> Glue records are not authoritative, although depending on the registry in >> question they may reply as such. In any case the apex of the zone is >> considered the most trustworthy by BIND so it will cache the child zone NS >> records in preference to the glue records. Of course once the cache expires, >> unless one of the delegation points is accessible from the parent zone (are >> all NS records for the domain wrong in the parent?) the domain will no >> longer be accessible. You've already proven as much with the +trace. Your >> only option is to fix the glue records. > > Thanks for your answer. > Yes, I've been trying to get the glue records fixed for several days ; > actually there should be no glue record at all, as the authoritative NS > for domain.tld should be ns(1|2).domain.com, not ns(1|2)domain.tld. > Sorry I forgot to tell there were only those two NS, so yes, all NS > records are currently wrong in the parent. > But the IP addresses of the glues refer to the correct servers (copied > from the correct NS names), so I was wondering if this was the reason > why my cache server was still resolving some records. Without the exact domain and TLD (their behaviours differ) its hard to guess. However if dig +trace doesn't work, that's fairly conclusive that the domain is offline as far as new lookups are concerned. Obviously those who have cached the old NS records would not notice it until TTLs expire. So it depends on TTLs as well as the type of audience that the domain targets (regular visitor vs transient/one off). > > Laurent > ___ > 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: Wrong names for NS and glue records not in the child zone
On 20/12/10 11:05 AM, "Laurent Bauer" wrote: > > Hello, > > We (my company) are registrar for a domain name which is delegated to > our client NS. Our client wanted to change the NS records (just the > names, same IP addresses) but the registry put the wrong names and > created glue records instead. > Obviously the glue records are not present in the child zone, and the NS > names do not match either, as this is not what the client had configured. > > The registry NS return an authority section like : > domain.tld. IN NS ns1.domain.tld. > domain.tld. IN NS ns2.domain.tld. > and an additional section with these glue records. > > The delegation should be : > domain.tld. IN NS ns1.domain.com. > domain.tld. IN NS ns2.domain.com. > which are also glue records, by the way, but domain.com. resolution is OK. > > Anyway, my cache NS (bind 9.7.1-P2) still resolves A records for > www.domain.tld. I flushed the cache before. > Does it mean that bind ignores the authoritative answer for glue records > and the NS records ? Glue records are not authoritative, although depending on the registry in question they may reply as such. In any case the apex of the zone is considered the most trustworthy by BIND so it will cache the child zone NS records in preference to the glue records. Of course once the cache expires, unless one of the delegation points is accessible from the parent zone (are all NS records for the domain wrong in the parent?) the domain will no longer be accessible. You've already proven as much with the +trace. Your only option is to fix the glue records. > Is it just because the IP addresses are the same, > or some kind of tolerance to this kind of configuration error ? Could > this be an implementation-dependant behaviour ? > > A "dig +trace" query fails with "connection timed out; no servers could > be reached" when trying to query the authoritative NS for domain.tld. > While I might find this is the right behaviour that dig only follows > authoritative NS, is it not supposed to connect to ns1.domain.tld. and > then return NXDOMAIN for ns1.domain.tld. ? > > My main problem is that the registry tells us there is no problem, as > the resolution is still OK for www records. > I would like to explain this, and have other arguments than "the client > does not want that" or "this will stop resolving the moment the glue > records change for ns1.domain.com." > > Thanks in advance for any answer to my questions. > > Laurent > ___ > 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
On 26/11/10 5:58 AM, "Mark Andrews" wrote: > > In message , > 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
On 13/10/10 12:13 PM, "Andrey G. Sergeev" 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
On 11/10/10 1:02 PM, "Alans" 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?
On 2/10/10 7:18 AM, "Joerg Dorchain" wrote: > On Fri, Oct 01, 2010 at 05:39:16PM +0200, Matus UHLAR - fantomas wrote: >> >> On 01.10.10 12:39, Joerg Dorchain wrote: >>> Well, I could agree agree that "wrong" means not thought of by >>> RfC-Designers and bind implementators (yet). >> >> probably it was not thought because it's wrong. > > This point is getting religious now, IMHO. Bear in mind that your rationale is based on getting an inaccessible DNS server to return information that a client has correctly asked for. I can't imagine a situation where there'll be a strong desire to codify that kind of set up. If your DNS server is not accessible to clients that need to query it for data, your set up is wrong. That isn't religious, that is practical reality. >> less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. >>> >>> Hm, this is not too easy in practice, but of course optimal solution. >>> IPv6 will help here, I hope. >> >> I don't think this will solve the problem, it will just be a workaround for >> it. > > With IPv6, I see much better chances of having more than one > address available, which would make the best architectural solution > a practical one as well. I think you need to consider your architectural design in a different light. Address availability is not your problem. Your solution seems to be a work around built on a work around. Ask yourself: "am I using DNS to fix a problem or shortcoming in another system?". If yes, fix the other system instead. >> 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). >>> >>> Not feasible as it contains dynamically generated content, >>> typically with a TTL of 0. >> >> this strongly indicates that there's something broken in your DNS. The DNS >> is not designed to provide anything that short-lived, the whole DNS >> architecture is based on cachind. > > Yes, DNS works best with caching. I know that this setup is a > corner case and very individual (If would had two public IPs then > I would be fine) > > To be a bit polemic, if you think it is wrong, TTL of 0 should be > forbidden, I suppose. To be more accurate, the reasons people think they need a TTL of 0 indicate they are using DNS incorrectly. Often it is an attempt at working around the restrictions of other systems. Hence the guess at load balancing. What data are you providing that changes second to second and must be provided using DNS? >> >> Are you doing any kind of DNS-based load balancing? > > No, then multiple A records or so would be just fine. > > 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: per-zone-recursion?
On 1/10/10 9:15 AM, "Joerg Dorchain" 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?
On 29/09/10 10:30 PM, "Kevin Oberman" wrote: >> Date: Wed, 29 Sep 2010 15:51:55 -0400 >> From: "Taylor, Gord" >> 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?
On 22/09/10 11:29 AM, "Matus UHLAR - fantomas" 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?
On 22/09/10 4:14 AM, "Doug Barton" 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?
On 21/09/10 3:43 PM, "Niobos" wrote: > On 2010-09-21 15:32, Kalman Feher wrote: >> On 21/09/10 8:43 AM, "Niobos" wrote: >> 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. > 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. 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. > >> On a large scale, manual >> intervention would make me very concerned with the likelihood of human based >> outages. > I'm even concerned that this will be the problem on my private zone... > > thank you again for the very insightful info! > > ___ > 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?
On 21/09/10 8:43 AM, "Niobos" 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?
On 20/09/10 6:09 PM, "Kevin Oberman" wrote: >> Date: Mon, 20 Sep 2010 11:03:31 +0200 >> From: Kalman Feher >> 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 time
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
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. 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. 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. 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. Regarding algorithms, you're likely to need 2 if you wish to use SHA 512 (or anything that isn't SHA1). My recollection on this may be wrong, but SHA1 is still required for DNSSEC I believe. So keep that in mind when staggering roll over times. Finally note that the blog on ISCs website regarding 9.7.2 foreshadowed some automated and sane timing controls: http://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-s igning I've seen no recommendations regarding NSEC3 salt lifetimes, but if you automate key generation (balanced by shorter lifetimes), you could change the salt as you re-sign. On 17/09/10 8:26 PM, "Niobos" wrote: > Hi, > > I'm playing around with the different timers of DNSSEC. Usually these > timers are a balance between a low overhead vs quick propagation: > * A high TTL gives more caching and thus less load on the authoritative > server; but it takes a long time for updates to propagate. > * A short RRSIG lifetime limits the amount of time old answers can be > replayed; but requires regular resigning > > Or they are a balance between low overhead and security: > * A DNSKEY (ZSK or KSK) used for a long time risks being cracked; > changing it often requires maintenance. > > But for the NSEC3 salt, I can't really figure out what the components > are... If someone is brute-forcing the NSEC3 hashes (cfr Daniel > Bernstein's presentation), changing the salt requires only a minuscule > change on their end. I see no reason to change the NSEC3 salt at all. > > So the question is: what is a normal lifetime of an NSEC3 salt, and for > what reason? > > And while I'm at it: what lifetimes, keylengths and algo's are popular > for ZSK's and KSK's? Are your keys stored online or offline? > > I'm thinking of using ZSK's of 1280bits for a year (since I'm lazy) and > KSK's of 2048bits until I feel like changing it (i.e. pretty much > indefinitely). This would allow the KSK to be offline, and only needed > once a year. > I'd like to use NSEC3 with RSA/SHA-512, but that might be unreasonable > strong compared to my lazy lifetimes. On the other hand, RSA/SHA1 is > more compatible (eg with bind 9.6). > My signature lifetime will probably be 3 weeks, resigning every week. > With 1 week expire timers, it leaves 1 week of margin to correct errors. > Are these values/argo's sane? > > Thx, > Niobos > > PS: don't try talking me into using NSEC. I'm using NSEC3 "because I > can", not that it would be any problem at all if they walked my zone. > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/
Re: Second dig lookup not the same as the first
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" 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 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 > >
Re: BIND 9.7.1 + DLZ + DNSSEC: Possible?
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" 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" > Para: "Kevin Mai" > 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 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: Timeouts and retries on high speed Lans
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" 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: AW: Limitation on concurrently handled queries
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" 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
On 27/07/10 8:10 AM, "Arnoud Tijssen" 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{}?
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" wrote: On Fri, Jul 16, 2010 at 01:57:05PM +, ALAIN AINA 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{}?
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 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
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8
FB5
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 to the . 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" 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
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" 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: ad flag for RRSIG queries
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)" 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: reason for "expected covering NSEC3, got an exact match" ?
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" 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: reason for "expected covering NSEC3, got an exact match" ?
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" 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: R: Does bind send email?
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" 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
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" 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 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
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" wrote:
>
>
>
> On 30/06/10 5:25 PM, "Alan Clegg" 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: Nsupdate -l not using session.key
On 30/06/10 5:25 PM, "Alan Clegg" 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
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: DNSSEC - Root zone - FUD
On 3/05/10 10:25 PM, "Ray Van Dolson" wrote: > David, I think you're exactly right. Lots of FUD, but, if I understand > correctly, BIND does by default does send out EDNS0 signalling by > default... EDNS0 does not imply DNSSEC. So you can get large responses back for lots of non DNSSEC queries. Having it enabled does not in anyway increase any risk on the 5/5. If you do not ask, you will not receive. So if today you do not have DNSSEC enabled; dnssec-enable and dnssec-validation (more recent BIND revisions), you will not receive the signed response, EDNS0 enabled or not. So these are your required checks: Do I have DNSSEC enabled? Yes - check your network as already discussed. No - Have a coffee, relax and consider enabling it by July, at least to test. > so it's still prudent to check your own firewall setups to > ensure you can handle the larger packet sizes. Yes, this will be useful in the future. But not required this week. > Worst case you see > delays if they do not. > -- 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
On 3/05/10 9:54 PM, "Lightner, Jeff" 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: Preparing for upcoming DNSSEC changes on 5/5
On 3/05/10 7:34 PM, "Lightner, Jeff" 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
On 1/05/10 7:10 PM, "Server Administrator" 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: Strange behaviour with DNSSec
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" 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
