Re: auto-dnssec maintain stoped working again...
In message 20111002161255.GG11782@michelle1, Michelle Konzack writes: Hello Hauke Lampe, Am 2011-10-01 02:02:56, hacktest Du folgendes herunter: Do you mean expired signatures or no signatures at all? I have expired signatures... In the latter case, have you checked that the zone's keys are readable by named and still active? Ehm yes root@dns1 /etc/bind # ls -Al /etc/bind/master/net/tamay-dogan/*tamay-dogan* -rw-r--r-- 1 bind adm 502 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/KS= K_Kintranet1.tamay-dogan.net.+005+12154.key -rw--- 1 bind adm 1.2K Oct 2 18:01 /etc/bind/master/net/tamay-dogan/KS= K_Kintranet1.tamay-dogan.net.+005+12154.private -rw-r--r-- 1 bind adm 502 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/KS= K_Kintranet2.tamay-dogan.net.+005+45271.key -rw--- 1 bind adm 1.2K Oct 2 18:01 /etc/bind/master/net/tamay-dogan/KS= K_Kintranet2.tamay-dogan.net.+005+45271.private -rw-rw-r-- 1 bind adm 2.2K Jul 3 17:10 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan -rw-rw-r-- 1 bind adm 249 Jun 17 22:33 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.conf -rw-r--r-- 1 bind adm 256 Jul 3 17:10 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.conf.signed -rw-rw-r-- 1 bind adm 1.1K Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet1 -rw-rw-r-- 1 bind adm 238 Oct 2 17:59 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet1.conf -rw-r--r-- 1 bind adm 245 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet1.conf.signed -rw-r--r-- 1 bind adm 13K Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet1.signed -rw-rw-r-- 1 bind adm 798 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet2 -rw-rw-r-- 1 bind adm 238 Oct 2 17:59 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet2.conf -rw-r--r-- 1 bind adm 245 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet2.conf.signed -rw-r--r-- 1 bind adm 8.2K Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.intranet2.signed -rw-r--r-- 1 bind adm 7.1K Jul 26 04:22 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.signed -rw-r--r-- 1 bind adm 15K Jul 26 04:10 /etc/bind/master/net/tamay-dogan/ne= t.tamay-dogan.signed.jnl -rw-r--r-- 1 bind adm 459 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ZS= K_Kintranet1.tamay-dogan.net.+005+28905.key -rw--- 1 bind adm 1010 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ZS= K_Kintranet1.tamay-dogan.net.+005+28905.private -rw-r--r-- 1 bind adm 459 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ZS= K_Kintranet2.tamay-dogan.net.+005+36762.key -rw--- 1 bind adm 1010 Oct 2 18:01 /etc/bind/master/net/tamay-dogan/ZS= K_Kintranet2.tamay-dogan.net.+005+36762.private -rw-r--r-- 1 bind adm 439 Jul 3 17:10 /etc/bind/master/net/tamay-dogan/ZS= K_Ktamay-dogan.net.+005+30945.key -rw--- 1 bind adm 1010 Jul 3 17:10 /etc/bind/master/net/tamay-dogan/ZS= K_Ktamay-dogan.net.+005+30945.private If I am right, this looks right. No. It looks completely wrong. Someone/something has re-named the K* files. As the K* files have been renamed named can't find them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Basic Setting up request
On Sun, Oct 02, 2011 at 07:57:10PM +1100,
Leon Moya l...@mymail-box.com wrote
a message of 40 lines which said:
I'd now like (with help) to add resolution for an internal Apache
WebServer, used for developing and testing web pages prior to
FTP'ing to the Internet Host. The webserver is configured for a half
dozen varying domain names
No experience with MS-Windows, but, in BIND, you first declare
yourself authoritative for the zones of these names. Let's assume
www.example.com is such a name.
In named.conf:
zone example.com {
type master;
file example.com; // Choose the name at will
};
Test it with named-checkconf
Then, in the zone file (named after the zone, in my setup, but you're
free to have a different convention), assuming the name server is
ns1.example.net:
; Low value, since it is used only for testing
$TTL 30
; Meta-data for the zone
@ IN SOA ns1.example.net. root.example.net. (
2011100101 ; Serial. Useless since we do not have
secondaries
900 ; Refresh. Very low values, since it is
testing
30 ; Retry
100 ; Expire
30 ) ; Negative Cache TTL
IN NS ns1.example.net.
; Actual data
www IN A203.0.113.18
Test it with named-checkzone
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ZSK pre-publish
On 2011-10-01 11:40, Matthew Seaman wrote: The trick is to use dnssec-settime modify the dates built into your key by dnssec-keygen. Or equivalently to use dnssec-keygen with appropriate flags to set the 'Activate' date (not to mention Inactive and Delete) some time in the future. So --- this key is active now: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+04664.private Created: Sat Aug 13 07:40:28 2011 Publish: Sat Aug 13 07:40:28 2011 Activate: Sat Sep 10 07:40:28 2011 Revoke: UNSET Inactive: Sat Oct 8 07:40:28 2011 Delete: Sat Oct 8 07:40:28 2011 but this key is only published and will activate in a week: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+44132.private Created: Sat Sep 10 09:01:24 2011 Publish: Thu Jan 1 01:00:00 1970 Activate: Sat Oct 8 09:01:24 2011 Revoke: UNSET Inactive: Sat Nov 5 08:01:24 2011 Delete: Sat Nov 5 08:01:24 2011 dnssec-signzone will grok all the built-in dates and do the right thing when you sign the zone. BTW, how does dnssec-signzone behave when you pass -s option? Does it take into account that date when determining whether to use/publish key? Can one for example generate signatures for the future using dnssec-signzone, or is it possible only with careful manual inclusion? Regards, Torinthiel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto-dnssec maintain stoped working again...
Hello Mark Andrews, Am 2011-10-03 20:16:33, hacktest Du folgendes herunter: No. It looks completely wrong. Someone/something has re-named the K* files. As the K* files have been renamed named can't find them. No, they are found correctly. Here an extract (non relevant data striped): [ command 'scp dns1.tamay-dogan.net:/etc/bind/master/net/tamay-dogan/net.tamay-dogan /dev/stdout' ]-- @ 3600IN SOA dns1.tamay-dogan.net. hostmaster.tamay-dogan.net. ( 1317572159 14400 3600 604800 86400 ) IN NS dns1.tamay-dogan.net. IN NS dns2.tamay-dogan.net. IN NS dns3.tamay-dogan.net. IN MX 10 mail.tamay-dogan.net. IN MX 20 vserver04.tamay-dogan.net. tamay-dogan.net.IN TXT v=spf1 a mx ~all mail.tamay-dogan.net. IN A78.47.247.21 dns1.tamay-dogan.net. IN A78.47.104.44 dns2.tamay-dogan.net. IN A217.147.94.23 dns3.tamay-dogan.net. IN A78.47.247.21 striped webmail.tamay-dogan.net.IN CNAMEmail.tamay-dogan.net. $include /etc/bind/master/net/tamay-dogan/ZSK_Ktamay-dogan.net.+005+56865.key $include /etc/bind/master/net/tamay-dogan/KSK_Ktamay-dogan.net.+005+37663.key [ command 'scp dns1.tamay-dogan.net:/etc/bind/master/net/tamay-dogan/net.tamay-dogan.signed /dev/stdout' ]-- ; File written on Sun Oct 2 18:16:03 2011 ; dnssec_signzone version 9.7.3 tamay-dogan.net.3600IN SOA dns1.tamay-dogan.net. hostmaster.tamay-dogan.net. ( 1317572159 ; serial 14400 ; refresh (4 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) 3600RRSIG SOA 5 2 3600 2001151603 ( 20111002151603 56865 tamay-dogan.net. qxXVBhJU0DWLyKpCwIMlAU+El+UAWMDkK8bH 3HiY/2x8MYvJ2jBp/nb0IH5Z+/oLx+m6epR7 M1O4WJUc0CxCn56hRA1IcZGJ9SRkj5/9smvd yNDtnsUaEWQUUF/Q+J3nGL+sNhnTdiQqELAX Esc4mw+gfL/g31hbzJ0N7yU9b9Y= ) 3600NS dns1.tamay-dogan.net. 3600NS dns2.tamay-dogan.net. 3600NS dns3.tamay-dogan.net. 3600RRSIG NS 5 2 3600 2001151603 ( 20111002151603 56865 tamay-dogan.net. CWpYvXSTQnGdksDH2mVqaTyPfrIfbp2PKx1b +RAQFF3Q2FJlrjjiZwb/TxOqOzY03spGISBU 99055hyEEyLbnryOdvGMqEAED2vB+i21n51h nxtZojsQYGPOsNfiYtS+bTtVDS2kxQUNJFs3 WwaB4MHD44wkx1j9puYrTp6STMQ= ) 3600MX 10 mail.tamay-dogan.net. 3600MX 20 vserver04.tamay-dogan.net. 3600RRSIG MX 5 2 3600 2001151603 ( 20111002151603 56865 tamay-dogan.net. dk79clA+U5osuw2bDZMhtA4dS8NNAEibYWl8 7MVisx1xu+4A3Z6liKuU3uzOs/v5iaRE3Mdy gwTKiPBAuYKV1cxtaHy4vDwRneMhGQRZHWdB wYHVkLFjG7brlFXxQM4N+kUCvehHA8BnjnYb mnb+KVm5sMu458fhUo1qZyA3VZs= ) 3600TXT v=spf1 a mx ~all 3600RRSIG TXT 5 2 3600 2001151603 ( 20111002151603 56865 tamay-dogan.net. ZxSqPLqZzhZmQH2Q29cjvMkMIBl6MRXWHsjj 56J9FmjkegFUcr7R+QkODjQkhdRcbbUH0eTk Gh0Fs206xdokab783yF0UCtkEn+OMWtcuSKa BnfbBY0I1BjXD8eBdl839iK+OJVDObcPvH+M 3eYTGKbZ4qAHXnyzySdHLcRLR6s= ) 86400 NSECadmin.tamay-dogan.net. NS SOA MX TXT RRSIG NSEC DNSKEY 86400 RRSIG NSEC 5 2 86400 2001151603 ( 20111002151603 56865 tamay-dogan.net. bAMAXp2mj81LGqqZHqRD4llwnJc3ZA7cOrYM
Re: auto-dnssec maintain stoped working again...
On 10/3/2011 6:25 AM, Michelle Konzack wrote: Hello Mark Andrews, Am 2011-10-03 20:16:33, hacktest Du folgendes herunter: No. It looks completely wrong. Someone/something has re-named the K* files. As the K* files have been renamed named can't find them. No, they are found correctly. For the first signing, yes. For the other signings, no. Once the zones are signed, the $INCLUDE is not relevant. The files must remain in the format Kzone.+alg+id.key/private or the BIND executable (the thing dealing with auto-dnssec maintain) can't find them. AlanC signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC not populating parent zone files with DS records
Bill Owens ow...@nysernet.org wrote: However, in this case I believe your problem is the lack of NS records in nau.edu for extended.nau.edu. It's difficult to know for sure, but it appears that the only signature for the NS RRSET is using the ZSK for extended.nau.edu, not the ZSK for nau.edu. This is normal. DNSSEC does not sign delegation RRsets (NS records and glue A and records) because they are part of the child zone. DS records are special because although they live at the name of the child zone, they are considered part of the parent zone and are therefore signed by the parent, which forms a link in the chain of trust. For example, DiG 9.9.0a2 +dnssec ns cam.ac.uk. @ns0.ja.net. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1490 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 9 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;cam.ac.uk. IN NS ;; AUTHORITY SECTION: cam.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk. cam.ac.uk. 86400 IN NS authdns0.csx.cam.ac.uk. cam.ac.uk. 86400 IN NS dns1.cl.cam.ac.uk. cam.ac.uk. 86400 IN NS bitsy.mit.edu. cam.ac.uk. 86400 IN NS ns2.ic.ac.uk. cam.ac.uk. 86400 IN NS dns0.eng.cam.ac.uk. cam.ac.uk. 86400 IN NS dns0.cl.cam.ac.uk. cam.ac.uk. 86400 IN DS 5998 5 1 4FC806508D1FA1FE40AAF366A9180E052331D574 cam.ac.uk. 86400 IN DS 5998 5 2 B398A3523E2D6A10C0C3B349FA7AD0639551950F2FBD9E82A6B69370 C2725548 cam.ac.uk. 86400 IN RRSIG DS 8 3 86400 20111029080710 20110929080710 20880 ac.uk. PjKjwnwTrMin9srEn5t+2LZhwRzndokxJit/0339LhaGhtrB7Mr7Jo5M 5D2nqYdJr2oo7LXIN90p1RLitHVQrP05B6G8jyjJZJhPB6UlWMfvdIuQ k+FClgxnvWLBraXLdVWGmrMbp08i63KoYnBbtWOJEmts9CPnKMXLOtji 1K8= ;; ADDITIONAL SECTION: ns2.ic.ac.uk. 86400 IN A 155.198.142.82 dns0.cl.cam.ac.uk. 86400 IN A 128.232.0.19 dns0.eng.cam.ac.uk. 86400 IN A 129.169.8.8 dns1.cl.cam.ac.uk. 86400 IN A 128.232.0.18 authdns0.csx.cam.ac.uk. 86400 IN A 131.111.8.37 authdns0.csx.cam.ac.uk. 86400 IN 2001:630:212:8::d:a0 authdns1.csx.cam.ac.uk. 86400 IN A 131.111.12.37 authdns1.csx.cam.ac.uk. 86400 IN 2001:630:212:12::d:a1 ;; Query time: 4 msec ;; SERVER: 2001:630:0:9::14#53(2001:630:0:9::14) ;; WHEN: Mon Oct 3 14:25:26 2011 ;; MSG SIZE rcvd: 601 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking, North Utsire: Southerly veering southwesterly 6 to gale 8, occasionally severe gale 9 at first in northwest Viking. Moderate or rough becoming very rough or high. Rain then squally showers. Moderate or good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ZSK pre-publish
On 03/10/2011 13:45, Torinthiel wrote: On 2011-10-01 11:40, Matthew Seaman wrote: dnssec-signzone will grok all the built-in dates and do the right thing when you sign the zone. BTW, how does dnssec-signzone behave when you pass -s option? Does it take into account that date when determining whether to use/publish key? Can one for example generate signatures for the future using dnssec-signzone, or is it possible only with careful manual inclusion? If the date or offset you specify via the -s option is outside the period of activation of a key, then dnsssec-signzone won't use that key to sign that RR. So if you're trying to manage keys manually you will need to resign the zone once the activation date plus 1 hour has passed -- assuming you take the defaults for '-s' -- to pick up the RRSIGs made with the new key. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC not populating parent zone files with DS records
Michael Sinatra mich...@rancid.berkeley.edu wrote: There are ways of getting the DS records into the zone(s). Here are some steps that I took on some test zones: Alternatively, set update-policy local; on your parent zone and use this little pipeline on the master server. Substitute $parent and $child as necessary: dig +noall +answer dnskey $child | dnssec-dsfromkey -f /dev/stdin $child | (echo zone $parent; sed 's/^/update add /'; echo send) | nsupdate -l Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin: Southwesterly 7 to severe gale 9, occasionally storm 10 at first in northeast Rockall, decreasing 5 or 6 later. Very rough or high, occasionally very high at first in north Rockall. Squally showers. Moderate or poor, occasionally good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto-dnssec maintain stoped working again...
In message 20111003132508.GL11782@michelle1, Michelle Konzack writes:
Hello Mark Andrews,
Am 2011-10-03 20:16:33, hacktest Du folgendes herunter:
No. It looks completely wrong. Someone/something has re-named the K* fil=
es.
As the K* files have been renamed named can't find them.
No, they are found correctly.
Named is looking for Kdomain+alg+keyid.{private,key}. You
have changed the names of these files and as a result named cannot
find them.
Change the file names back to what they were originally. With
auto-dnssec named will add the contents of the K*.key files to the
zone automatically based on the times set on the keys so you do not
need to $INCLUDE them.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Bind DLZ and Postgres 8.4.8
Hello, by regarding the excellent guide of Jan Pit Mens, i have integrated Bind 9.8.1 DLZ with Mysql 5.x DB; everything is fine and fantastic. I cannot use Postgresql 8.4.8 backend; named correctly starts but, when first nslookup query take place, named crash with this dump: *** glibc detected *** named: corrupted double-linked list: 0x0a0e89c0 *** === Backtrace: = /lib/libc.so.6[0x7d67ca] /lib/libc.so.6(cfree+0x59)[0x7d6b09] /usr/lib/libpq.so.5(PQclear+0xf0)[0x4adf50] named[0x8096ec2] named[0x81657da] named[0x80c1bd8] named[0x805c53a] named[0x806219c] named[0x8067e1c] named[0x80519a0] named[0x81e9263] named[0x81ec853] named[0x81ecab8] named[0x81ecb62] named[0x805ae06] /lib/libc.so.6(__libc_start_main+0xdc)[0x782e9c] named[0x804b4e1] === Memory map: 00101000-00222000 r-xp 08:02 684452 /usr/lib/mysql/libmysqlclient.so.15.0.0 00222000-00264000 rwxp 0012 08:02 684452 /usr/lib/mysql/libmysqlclient.so.15.0.0 00264000-00265000 rwxp 00264000 00:00 0 00265000-002f8000 r-xp 08:02 280557 /usr/lib/libkrb5.so.3.3 002f8000-002fb000 rwxp 00092000 08:02 280557 /usr/lib/libkrb5.so.3.3 002fb000-0030b000 r-xp 08:02 1361521/lib/libresolv-2.5.so 0030b000-0030c000 r-xp f000 08:02 1361521/lib/libresolv-2.5.so 0030c000-0030d000 rwxp 0001 08:02 1361521/lib/libresolv-2.5.so 0030d000-0030f000 rwxp 0030d000 00:00 0 0030f000-00324000 r-xp 08:02 1361519/lib/libpthread-2.5.so 00324000-00325000 r-xp 00015000 08:02 1361519/lib/libpthread-2.5.so 00325000-00326000 rwxp 00016000 08:02 1361519/lib/libpthread-2.5.so 00326000-00328000 rwxp 00326000 00:00 0 00328000-0033d000 r-xp 08:02 1361505/lib/libnsl-2.5.so 0033d000-0033e000 r-xp 00014000 08:02 1361505/lib/libnsl-2.5.so 0033e000-0033f000 rwxp 00015000 08:02 1361505/lib/libnsl-2.5.so 0033f000-00341000 rwxp 0033f000 00:00 0 0034a000-0034d000 r-xp 08:02 1361501/lib/libdl-2.5.so 0034d000-0034e000 r-xp 2000 08:02 1361501/lib/libdl-2.5.so 0034e000-0034f000 rwxp 3000 08:02 1361501/lib/libdl-2.5.so 0034f000-0047b000 r-xp 08:02 284429 /usr/lib/libxml2.so.2.6.26 0047b000-0048 rwxp 0012c000 08:02 284429 /usr/lib/libxml2.so.2.6.26 0048-00481000 rwxp 0048 00:00 0 00481000-0048b000 r-xp 08:02 1361511/lib/libnss_files-2.5.so 0048b000-0048c000 r-xp 9000 08:02 1361511/lib/libnss_files-2.5.so 0048c000-0048d000 rwxp a000 08:02 1361511/lib/libnss_files-2.5.so 0048d000-00498000 r-xp 08:02 1363298 /lib/libgcc_s-4.1.2-20080825.so.1 00498000-00499000 rwxp a000 08:02 1363298 /lib/libgcc_s-4.1.2-20080825.so.1 004a3000-004c6000 r-xp 08:02 272273 /usr/lib/libpq.so.5.2 004c6000-004c8000 rwxp 00022000 08:02 272273 /usr/lib/libpq.so.5.2 004c8000-0050c000 r-xp 08:02 1364068/lib/libssl.so.0.9.8e 0050c000-0051 rwxp 00043000 08:02 1364068/lib/libssl.so.0.9.8e 00561000-00562000 r-xp 00561000 00:00 0 [vdso] 00661000-0066a000 r-xp 08:02 1361499/lib/libcrypt-2.5.so 0066a000-0066b000 r-xp 8000 08:02 1361499/lib/libcrypt-2.5.so 0066b000-0066c000 rwxp 9000 08:02 1361499/lib/libcrypt-2.5.so 0066c000-00693000 rwxp 0066c000 00:00 0 00744000-0076b000 r-xp 08:02 1361503/lib/libm-2.5.so 0076b000-0076c000 r-xp 00026000 08:02 1361503/lib/libm-2.5.so 0076c000-0076d000 rwxp 00027000 08:02 1361503/lib/libm-2.5.so 0076d000-008c r-xp 08:02 1361495/lib/libc-2.5.so 008c-008c2000 r-xp 00153000 08:02 1361495/lib/libc-2.5.so 008c2000-008c3000 rwxp 00155000 08:02 1361495/lib/libc-2.5.so 008c3000-008c6000 rwxp 008c3000 00:00 0 00902000-0090a000 r-xp 08:02 280549 /usr/lib/libkrb5support.so.0.1 0090a000-0090b000 rwxp 7000 08:02 280549 /usr/lib/libkrb5support.so.0.1 00962000-00987000 r-xp 08:02 280551 /usr/lib/libk5crypto.so.3.1 00987000-00988000 rwxp 00025000 08:02 280551 /usr/lib/libk5crypto.so.3.1 0099c000-009c9000 r-xp 08:02 280746 /usr/lib/libgssapi_krb5.so.2.2 009c9000-009ca000 rwxp 0002d000 08:02 280746 /usr/lib/libgssapi_krb5.so.2.2 00c33000-00c45000 r-xp 08:02 267645 /usr/lib/libz.so.1.2.3 00c45000-00c46000 rwxp 00011000 08:02 Abortito (core dumped) [root@none etc]# *** glibc detected *** named: corrupted double-linked list: 0x0a0e89c0 *** /usr/lib/libpq.so.5(PQclear+0xf0)[0x4adf50] Perhaps a bug? Onyl with Postgresql DB... Thank you, cheers! Francesco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NXDOMAIN redirection in BIND 9.9
On 9/30/2011 6:21 PM, Shawn Bakhtiar wrote: We came to the conclusion that no matter how much we wanted it to not be true, people find a way to do NXDOMAIN if they want to. The issue is not ours to push, it's between the ISP and the customer ultimately, and people will do it -- and more intrusively -- than BIND 9.9 will. That is just giving in. To what WILL end up being akin (is akin) to taking away access. The argument that everyone is doing it so let's just facilitate it is a bad one. This is a cave in to bad behavior which borders on freedom of speech violation, since your sanctioning the ability to arbitrarily redirecting (without redirecting) content. Important part being the sanctioning of. http://en.wikipedia.org/wiki/DNS_hijacking On 30.09.11 19:43, David Miller wrote: You get to run your network how ever you like. This is your right. Turn the feature on if you like -or- make sure it is off if you don't like it. and he can blame ISC for providing the feature at all. You don't get to tell others how to run their networks. Well... you can tell them, but they don't have to listen to you... He does, and (for example) you listen. Many organizations want to do NXDOMAIN redirections on their resolvers on their own internal networks or on guest wireless networks or on whatever networks they control for whatever reasons they like. and most of them are invalid, ill and sick. This won't change, especially since we can expect more of people do it now, when ISC provides a way do to it. Other resolvers have had the ability to do NXDOMAIN redirections for many years. The pressures keeping ISPs from implementing NXDOMAIN redirections has never been the fact that BIND didn't support it. I hoped that ISC stays out of the world where companies will break DNS to do something it is not designed for. Now I see it doesn't. Bad. -- 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. I'm not interested in your website anymore. If you need cookies, bake them yourself. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec config sanity check
We are getting ready to deploy dnssec, and I'd appreciate a quick sanity check on our configuration and key timings to make sure I didn't miss anything that would cause things to blow up ;). Our zone data is maintained in a revision control repository; when changes are made there is a process that generates a bind format zone file from the data, checks it for syntax errors, compiles, and then signs it, at the end reloading the zone into bind with rndc. Our zones are configured with a 1 hour refresh/5 minute retry/two week expiration for zone transfers and a default TTL of 12 hours. We're using RSASHA256 for both KSK and ZSK, with a keysize of 2048 and 1024 respectively. The KSK's are rotated yearly on July 1 at midnight. New KSK's are created with a publish date set 1 year in the future, an inactive date 2 years in the future, and a deletion date of 2 years and 14 days in the future. At any given time there are 2 or 3 KSK's being published: the key currently being used to sign the ZSK, the key that will be used to sign the ZSK starting at the next rotation period, and for 14 days after the rotation the key that was previously being used (this 14 day window is to ensure enough time to update the DS entries in the parent zones). The ZSK's are rotated monthly on the 1st at 12:02am. New ZSK's are created with a publish date set 1 month in the future, an inactive date 2 months in the future, and a deletion date of 2 months and 2 days in the future. At any given time there are 2 or 3 ZSK's being published: the key currently being used to sign the zone, the key that will be used to sign the zone starting at the next rotation period, and for 2 days after the rotation the key that was previously being used. dnssec-signzone is configured to automatically pull the appropriate keys from the key directory, and the zones are signed with NSEC3 with a 35 day validity and 30 minute jitter. After the new keys are generated on the first of the month, all of the zones fiels are generated and signed. The only issue I see is that if there are no updates to the zone in a given month (resulting in another signing with a 35 day validity from that date), and the master dies on the last day of the month, the slaves will have zones which would be good for two weeks based on SOA timings, but with signatures that will die off in as little as five days. I don't consider that very likely; there are typically updates at least every day or two, and if our master died I'm pretty sure we'd have it fixed within 24 hours. Are there any timing issues or edge cases that I'm missing? Thanks in advance for any feedback... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec config sanity check
In message 4e8a5412.7050...@acm.org, Paul B. Henson writes: We are getting ready to deploy dnssec, and I'd appreciate a quick sanity check on our configuration and key timings to make sure I didn't miss anything that would cause things to blow up ;). Our zone data is maintained in a revision control repository; when changes are made there is a process that generates a bind format zone file from the data, checks it for syntax errors, compiles, and then signs it, at the end reloading the zone into bind with rndc. Our zones are configured with a 1 hour refresh/5 minute retry/two week expiration for zone transfers and a default TTL of 12 hours. We're using RSASHA256 for both KSK and ZSK, with a keysize of 2048 and 1024 respectively. The KSK's are rotated yearly on July 1 at midnight. New KSK's are created with a publish date set 1 year in the future, an inactive date 2 years in the future, and a deletion date of 2 years and 14 days in the future. At any given time there are 2 or 3 KSK's being published: the key currently being used to sign the ZSK, the key that will be used to sign the ZSK starting at the next rotation period, and for 14 days after the rotation the key that was previously being used (this 14 day window is to ensure enough time to update the DS entries in the parent zones). Don't ASSUME that the DS will be published in time. Build checks into your proceedures from the beginning. e.g. Publish and activate July 1. Change DS records July 8. Check that DS is published July 15 and set inactivate and deletion dates if and only if new DS is published to August 1 and September 1 respectively. If the DS is not publish chase up with parent and recheck the next day slipping inactivate and deletion dates for a day for each day the DS publication date is past July 15. The ZSK's are rotated monthly on the 1st at 12:02am. New ZSK's are created with a publish date set 1 month in the future, an inactive date 2 months in the future, and a deletion date of 2 months and 2 days in the future. At any given time there are 2 or 3 ZSK's being published: the key currently being used to sign the zone, the key that will be used to sign the zone starting at the next rotation period, and for 2 days after the rotation the key that was previously being used. dnssec-signzone is configured to automatically pull the appropriate keys from the key directory, and the zones are signed with NSEC3 with a 35 day validity and 30 minute jitter. After the new keys are generated on the first of the month, all of the zones fiels are generated and signed. The only issue I see is that if there are no updates to the zone in a given month (resulting in another signing with a 35 day validity from that date), and the master dies on the last day of the month, the slaves will have zones which would be good for two weeks based on SOA timings, but with signatures that will die off in as little as five days. I don't consider that very likely; there are typically updates at least every day or two, and if our master died I'm pretty sure we'd have it fixed within 24 hours. Are there any timing issues or edge cases that I'm missing? Thanks in advance for any feedback... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
