swinog

swinog@lists.swinog.ch

17 participants
2973 discussions

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 05 May '10

05 May '10

Root Zone DNSSEC Deployment Technical Status Update 2010-05-05 This is the sixth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. ** The final transition to a signed root zone took place today ** on J-Root, between 1700--1900 UTC. ** ** All root servers are now serving a signed root zone. ** ** All root servers will now generate larger responses to DNS ** queries that request DNSSEC information. ** ** If you experience technical problems or need to contact ** technical project staff, please send e-mail to rootsign(a)icann.org ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred ** if possible. ** ** See below for more details. RESOURCES Details of the project, including documentation published to date, can be found at <http://www.root-dnssec.org/>. We'd like to hear from you. If you have feedback for us, please send it to rootsign(a)icann.org. DEPLOYMENT STATUS The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. All of the thirteen root servers have now made the transition to the to the DURZ. No harmful effects have been identified. The final root server to make the transition, J-Root, started serving the DURZ in a maintenance window between 1700--1900 UTC on 2010-05-05. Initial observations relating to this transition will be presented and discussed at the DNS Working Group meeting at RIPE 60 in Prague on 2010-05-06. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ To come: 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.)

1 0

Antw: Open position as Deliverability Manager
by Peter Schwindt 04 May '10

04 May '10

Could you guys please stop messing with the discussion threads? Having these headers: -- snip -- References: <4BCC4AEA.30701(a)atrila.net> In-Reply-To: <4BCC4AEA.30701(a)atrila.net> -- snap -- in a new topic's thread is simply bad behaviour. So please start a new post instead of replying to old ones. Thanks, Peter >>> André Görmera.goermer(a)ecircle.com> 04.05.2010 14:45 >> ( mailto:a.goermer@ecircle.com ) we are searching for an additional Deliverability Manager to join our team in Munich: http://news.ecircle.com/imgproxy/cont/600299859/DeliverabilityManager042010…

1 0

Open position as Network Engineer
by Aarno Aukia 04 May '10

04 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, We are looking for an additional Network Engineer to join our team in Zürich: http://www.jobwinner.ch/(o23ndp45ovmhk545f1cmdue3)/employee/viewclassified.… Feel free to contact me if you have any questions. Best Regards, Aarno - -- Atrila GmbH Aarno Aukia, CTO Postfach 4412 6304 Zug Switzerland Mobile: +41 76 4000 464 Main: +41 41 741 55 45 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvMSuoACgkQRasxUPYfw9whvACcCBwQSB+OalFBwzmqzuY0Ytv5 aW0An3+e4gs/pklc33yFmUnOFpJDOXoJ =DZzk -----END PGP SIGNATURE-----

2 2

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 03 May '10

03 May '10

Root Zone DNSSEC Deployment Technical Status Update 2010-05-03 This is the fifth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. ** The final transition to the DURZ will take place on ** J-Root, on 2010-05-05 between 1700--1900 UTC. ** ** After that maintenance all root servers will be serving the ** DURZ, and will generate larger responses to DNS ** queries that request DNSSEC information. ** ** If you experience technical problems or need to contact ** technical project staff, please send e-mail to rootsign(a)icann.org ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred ** if possible. ** ** See below for more details. RESOURCES Details of the project, including documentation published to date, can be found at <http://www.root-dnssec.org/>. We'd like to hear from you. If you have feedback for us, please send it to rootsign(a)icann.org. DEPLOYMENT STATUS The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. Twelve of the thirteen root servers have already made the transition to the DURZ. No harmful effects have been identified. The final root server to make the transition, J-Root, will start serving the DURZ in a maintenance window scheduled for 1700--1900 UTC on 2010-05-05. Initial observations relating to this transition will be presented and discussed at the DNS Working Group meeting at the RIPE meeting in Prague on 2010-05-06. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ To come: 2010-05-05: J starts to serve DURZ 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) A more detailed DURZ transition timetable with maintenance windows can be found in the document "DNSSEC Deployment for the Root Zone", the most recent draft of which can be found on the project web page at <http://www.root-dnssec.org/>.

1 0

swinog-20 voucher codes
by Steven Glogger 03 May '10

03 May '10

1 1

Wave Equinix 1 - Layer One
by Alexandre Egger 30 Apr '10

30 Apr '10

Hello Swinog list, I am looking for a provider that can offer a wave C or D-WDM between: - Point A: Equinix 1, Hardstrasse 235, 8005 Zurich or - Point A: ICT-Center, Josefstrasse 225, 8005 Zurich and - Point B: Layer One, Letzigraben 75, 8003 Zurich Don't hesitate to revert to me with you offers. Kind Regards, Alexandre

1 0

SwiNOG-BE85 - Beer Event 85 - 3rd of May 2010 @ Outback / ZH
by Steven Glogger 29 Apr '10

29 Apr '10

hi everybody here's the announcement for the next beer event. the facts for the next event: ----------------------------- Date: 3rd of May 2010 Time: starting around 18.30 o'clock Location: @ the "Outback" Bahnhof Stadelhofen Registration deadline: 02.05.2010 16:00 (Sunday) Registration: http://swinog.mrmouse.ch ------------- Please register here: http://swinog.mrmouse.ch/ since we have to make reservations, i need to know who's coming and who not. If you cannot attend and you're registered please inform me asap (+41 79 277 92 35). -steven

1 0

Re: [swinog] Geolocating IP's
by Philipp Nyffenegger 29 Apr '10

29 Apr '10

Hi, one of the most sophisticated Country to IP Databases i know of is at http://ip.ludost.net It even allows you to download the lists pre-formated in Cisco-ACLs, Iptables, apache .htaccess and a lot of other differerent formats. Afaik it's updated daily. Hope this helps. Cheers, Phippu

1 0

DNS: Clueless: Strange problems resolving ch domains...
by Christian 'wiwi' Wittenhorst 29 Apr '10

29 Apr '10

I got some reports from customers that some CH domains no not resolve... While testing if found: Only two of the [a-f].nic.ch seem to give replies... The ones that answer are exactly the ones that do not have IPv6 addresses... Happens at least for ksz.ch and swisscom.ch. Anyone else sees this? Any ideas? (820)[root@svn /tmp]# sh ch dig swisscom.ch ns @A.nic.ch ;; Got referral reply from 130.59.1.80, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> swisscom.ch ns @A.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig swisscom.ch ns @B.nic.ch ;; Got referral reply from 130.59.211.10, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> swisscom.ch ns @B.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig swisscom.ch ns @C.nic.ch ;; Got referral reply from 147.28.0.39, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> swisscom.ch ns @C.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig swisscom.ch ns @D.nic.ch ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> swisscom.ch ns @D.nic.ch ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24625 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;swisscom.ch. IN NS ;; AUTHORITY SECTION: swisscom.ch. 3600 IN NS dns2.swisscom.com. swisscom.ch. 3600 IN NS dns1.swisscom.com. ;; Query time: 218 msec ;; SERVER: 200.160.0.5#53(200.160.0.5) ;; WHEN: Thu Apr 29 10:41:36 2010 ;; MSG SIZE rcvd: 79 dig swisscom.ch ns @E.nic.ch ;; Got referral reply from 204.61.216.47, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> swisscom.ch ns @E.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig swisscom.ch ns @F.nic.ch ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> swisscom.ch ns @F.nic.ch ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61901 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;swisscom.ch. IN NS ;; AUTHORITY SECTION: swisscom.ch. 3600 IN NS dns1.swisscom.com. swisscom.ch. 3600 IN NS dns2.swisscom.com. ;; Query time: 24 msec ;; SERVER: 194.146.106.10#53(194.146.106.10) ;; WHEN: Thu Apr 29 10:41:51 2010 ;; MSG SIZE rcvd: 79 dig ksz.ch ns @A.nic.ch ;; Got referral reply from 130.59.1.80, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ksz.ch ns @A.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig ksz.ch ns @B.nic.ch ;; Got referral reply from 130.59.211.10, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ksz.ch ns @B.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig ksz.ch ns @C.nic.ch ;; Got referral reply from 147.28.0.39, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ksz.ch ns @C.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig ksz.ch ns @D.nic.ch ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ksz.ch ns @D.nic.ch ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59974 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;ksz.ch. IN NS ;; AUTHORITY SECTION: ksz.ch. 3600 IN NS zug.ch.ns.progon.net. ksz.ch. 3600 IN NS udns1.ultradns.net. ksz.ch. 3600 IN NS udns2.ultradns.net. ;; Query time: 228 msec ;; SERVER: 200.160.0.5#53(200.160.0.5) ;; WHEN: Thu Apr 29 10:44:25 2010 ;; MSG SIZE rcvd: 107 dig ksz.ch ns @E.nic.ch ;; Got referral reply from 204.61.216.47, trying next server ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ksz.ch ns @E.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached dig ksz.ch ns @F.nic.ch ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ksz.ch ns @F.nic.ch ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1256 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;ksz.ch. IN NS ;; AUTHORITY SECTION: ksz.ch. 3600 IN NS zug.ch.ns.progon.net. ksz.ch. 3600 IN NS udns2.ultradns.net. ksz.ch. 3600 IN NS udns1.ultradns.net. ;; Query time: 24 msec ;; SERVER: 194.146.106.10#53(194.146.106.10) ;; WHEN: Thu Apr 29 10:44:41 2010 ;; MSG SIZE rcvd: 107 (825)[root@svn /tmp]# dig -d swisscom.ch ns @A.nic.ch main parsing swisscom.ch clone_lookup() make_empty_lookup() clone_server_list() looking up swisscom.ch main parsing ns main parsing @A.nic.ch make_server(130.59.1.80) make_server(2001:620::4) setup_system() create_search_list() ndots is 1. copy_server_list() make_server(81.94.122.18) lock_lookup dighost.c:3100 success start_lookup() setup_lookup(0x2ad26cf3ed98) resetting lookup counter. using root origin recursive query add_question() starting to render the message done rendering create query 0x2ad26cf63b88 linked to lookup 0x2ad26cf3ed98 create query 0x2ad26cf63d68 linked to lookup 0x2ad26cf3ed98 do_lookup() send_udp(0x2ad26cf63b88) bringup_timer() have local timeout of 1 working on lookup 0x2ad26cf3ed98, query 0x2ad26cf63b88 sockcount=1 recving with lookup=0x2ad26cf3ed98, query=0x2ad26cf63b88, sock=0x2ad26cf86010 recvcount=1 sending a request unlock_lookup dighost.c:3102 lock_lookup dighost.c:1919 success send_done() sendcount=0 check_if_done() list empty unlock_lookup dighost.c:1948 recv_done() lock_lookup dighost.c:2605 success recvcount=0 lookup=0x2ad26cf3ed98, query=0x2ad26cf63b88 before parse starts sending query 0x2ad26cf63d68 send_udp(0x2ad26cf63d68) bringup_timer() have local timeout of 5 working on lookup 0x2ad26cf3ed98, query 0x2ad26cf63d68 sockcount=2 recving with lookup=0x2ad26cf3ed98, query=0x2ad26cf63d68, sock=0x2ad26cf87070 recvcount=1 sending a request ;; Got referral reply from 130.59.1.80, trying next server clear_query(0x2ad26cf63b88) sockcount=1 check_next_lookup(0x2ad26cf3ed98) still have a worker unlock_lookup dighost.c:2848 lock_lookup dighost.c:1919 success send_done() sendcount=0 check_if_done() list empty unlock_lookup dighost.c:1948 connect_timeout() lock_lookup dighost.c:2160 success resending UDP request to first server send_udp(0x2ad26cf63d68) bringup_timer() have local timeout of 5 working on lookup 0x2ad26cf3ed98, query 0x2ad26cf63d68 sending a request unlock_lookup dighost.c:2201 lock_lookup dighost.c:1919 success send_done() sendcount=0 check_if_done() list empty unlock_lookup dighost.c:1948 connect_timeout() lock_lookup dighost.c:2160 success resending UDP request to first server send_udp(0x2ad26cf63d68) bringup_timer() have local timeout of 5 working on lookup 0x2ad26cf3ed98, query 0x2ad26cf63d68 sending a request unlock_lookup dighost.c:2201 lock_lookup dighost.c:1919 success send_done() sendcount=0 check_if_done() list empty unlock_lookup dighost.c:1948 connect_timeout() lock_lookup dighost.c:2160 success ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> -d swisscom.ch ns @A.nic.ch ;; global options: printcmd ;; connection timed out; no servers could be reached cancel_lookup() check_if_done() list empty check_next_lookup(0x2ad26cf3ed98) still have a worker unlock_lookup dighost.c:2201 recv_done() lock_lookup dighost.c:2605 success recvcount=0 lookup=0x2ad26cf3ed98, query=0x2ad26cf63d68 no longer pending. Got operation canceled clear_query(0x2ad26cf63d68) sockcount=0 check_next_lookup(0x2ad26cf3ed98) try_clear_lookup(0x2ad26cf3ed98) destroy freeing server 0x2ad26cf41408 belonging to 0x2ad26cf3ed98 freeing server 0x2ad26cf41c38 belonging to 0x2ad26cf3ed98 start_lookup() check_if_done() list empty shutting down unlock_lookup dighost.c:2632 destroy cancel_all() lock_lookup dighost.c:3116 success unlock_lookup dighost.c:3146 destroy_libs() freeing task freeing taskmgr lock_lookup dighost.c:3173 success flush_server_list() freeing commctx freeing socketmgr freeing timermgr destroy DST lib detach from entropy unlock_lookup dighost.c:3219 Greetings from Zug wiwi

6 6

DNSSEC Deployment in ARPA Children
by Joe Abley 28 Apr '10

28 Apr '10

Colleagues, ICANN plans to begin a test deployment of DNSSEC in various zones starting on 2010-04-29: IN-ADDR-SERVERS.ARPA IP6.ARPA IP6-SERVERS.ARPA IRIS.ARPA URI.ARPA URN.ARPA These zones will be signed using RSASHA256 and NSEC with 2048-bit KSKs and 1024-bit ZSKs. Given DNSSEC deployment experience to date, ICANN does not expect the signing of these zones to cause any operational problems. However, should you have any concerns please feel free to contact us at ticket(a)dns.icann.org or phone +1 310 301 5810 (e-mail/ticket preferred). At the end of the test period, given no observed or reported harmful effects, ICANN will arrange for trust anchors for these zones to be included in ARPA as DS RRSets and will invite the five RIRs to submit DS RRSet add/delete requests in IP6.ARPA when they are ready. We anticipate the testing period to last at least two weeks. Regards, Joe Abley Director DNS Operations, ICANN

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog