swinog

swinog@lists.swinog.ch

2916 discussions

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

Geolocating IP's
by Stefan Renner 28 Apr '10

28 Apr '10

hello everybody Is anybody of you aware, how the most popular services (Google, Zattoo, Facebook, etc) are matching geographic locations to ip-adresses ? Our AS (41666) is located in CH, so also all the ripe objects are registered with country-code CH. Now we have a customer located in Germany, so I created a inetnum-block with his subnet in ripe-db with country-code DE. This was a week ago. The customer is still complaining that he is constantly redirected to the swiss-versions of all the services. Does anybody of you experienced a similar problem ? Does anybody knows proper solution ? Thanks for any advice in advance Best regards Stefan Renner Stefan Renner Network Engineer MYGATE Translumina Networks AG Flurstrasse 50 CH-8048 Zürich Fon: +41 44 540 22 11 Fax: +41 44 540 23 46 stefan.renner(a)mygate.net www.mygate.net

9 11

Looking for a parking lot closed
by Xaver Aerni 28 Apr '10

28 Apr '10

Hello, We are looking for a parking place "Garage" in Zurich west ore Altstetten. We are needing place for 2 or 3 Sprinters. The high of the one is 320 cm. When you know who has one. please contact me offline. Greetings Xaver

2 1

Cablecom SMTP
by Q-X GmbH - Pascal Wagenhofer 26 Apr '10

26 Apr '10

Hello Could someone from Cablecom-MTA Team contact me offlist, pls? Thank you and kind regards Pascal Wagenhofer Head of Technical Services Q-X GmbH Schmittestrasse 5 Postfach 61 CH-8606 Nänikon / Switzerland Phone 0840 11 11 10 (International +41 840 11 11 10) (Lokaltarif) Fax 0840 22 22 20 (International +41 840 22 22 20) (Lokaltarif) www.Q-X.ch <http://www.q-x.ch/>

1 0

Internet-Community Meeting @ Tweakfest, April 24, Zurich
by Norbert Bollow 17 Apr '10

17 Apr '10

(Für deutschen Text siehe unten.) ---> Internet-Community Meeting <--- at Tweakfest 2010 ( http://www.tweakfest.ch/ ) When? Saturday 24.4.2010, 14.00-16.00 Where? Alte Börse in Zurich (Bleicherweg 5), Gallerie http://alteboerse.com/lageplan.15.html (Die Gallery is in the Club in the fourth floor, and can be reached via the spiral stairs on the left. We will put up signs to help you find the Meeting.) Why, and what's the goal? The Federal Institute of Intellectual Property ( http://ige.ch/ ) organizes in May a meeting called "Urheberrechtsgespräch" (rough translation: "conversation about copyright matters"). They have invited various interest groups to nominate representatives for this event. The "Internet-Community" is one of the interest groups that have been invited. As per the invitation, the associations Digitale Allmend ( http://allmend.ch ) and /ch/open ( http://ch-open.ch ) have designated representatives who shall represent the Internet Community at that event. In order to achieve an authentic representation of the Internet Community, it is of course important that before the event, there should be a discussion involving as many diverse members of the Internet Community as possible, so that our representatives will be able to represent not only their own perspective, but as far as possible the concerns and interests of the Internet Community as a whole. This year, the topic of collection societies and their supervision will be one focus area of the "Urheberrechtsgespräch", but there will also be a session for addressing other topics. We really should give our representatives an authentic first-hand impression of how we see things. For example, we could formulate a position statement on ACTA, the so-called "Anti-Counterfeiting Trade Agreement", in which the negotiators want to include a chapter about the Internet. Are you coming? Please register for the meeting by email to: siug(a)siug.ch If you cannot come to the meeting, you are welcome to email suggestions to siug(a)siug.ch and we'll discuss them at the meeting. Responsible for the Internet-Community Meeting: Swiss Internet User Group (SIUG), an Initiative of /ch/open http://siug.ch/ With best regards in the name of SIUG Norbert Bollow --snip--------------------------------------------------------------- ---> Internet-Community Meeting <--- am Tweakfest 2010 ( http://www.tweakfest.ch/de/ ) Wann? Samstag 24.4.2010, 14.00-16.00 Wo? Alte Börse in Zürich (Bleicherweg 5, Zürich), Gallerie http://alteboerse.com/lageplan.15.html (Die Gallerie ist oben im vierten Stock im Club über die kleine Wendeltreppe links zu erreichen. Wir werden das Treffen vor Ort signalisieren.) Warum und wozu? Das Eidgenössische Institut für Geistiges Eigentum ( http://ige.ch/ ) veranstaltet im Mai ein "Urheberrechtsgespräch", zu dem Vertreter der verschiedenen Interessengruppen eingeladen werden. Auch die "Internet-Community" ist eine der dazu eingeladenen Interessengruppen. Entsprechend der Einladung haben die Vereine Digitale Allmend ( http://allmend.ch ) und /ch/open ( http://ch-open.ch ) Vertreter bestimmt, die die Internet-Community dort vertreten sollen. Um eine möglichst authentische Vertretung der Internet-Community zu erreichen, ist natürlich wichtig, dass zuvor eine möglichst breit abgestützte Diskussion unter Mitgliedern der "Internet-Community" stattfinden sollte, damit unsere Vertreter nicht nur ihre eigene Perspektive, sondern möglichst die Sorgen und Interessen der Internet-Community insgesamt vertreten können. Vom IGE her ist vorgesehen, dass es beim "Urheberrechtsgespräch" in einem ersten Teil um den Themenbereich "kollektive Verwertung und Aufsicht" (mit "Aufsicht" ist Aufsicht über die Tätigkeit der Verwertungsgesellschaften gemeint) und dann in einem zweiten Teil um ein grösseres Themenspektrum gehen soll. Wir sollten unseren Vertretern unbedingt von der Community her aus erster Hand einen starken Eindruck mitgeben, wie wir die Dinge sehen. Zum Beispiel bietet es sich an, eine Position im Hinblick auf ACTA zu formulieren, das sogenannte "Anti-Counterfeiting Trade Agreement", das ein Kapitel über das Internet enthalten soll. Kommst Du auch? Bitte Anmeldung per Email an: siug(a)siug.ch Wer nicht zu dem Meeting kommen kann, kann gerne Anregungen in schriftlicher Form an siug(a)siug.ch senden, diese werden dann am Meeting diskutiert. Verantworlich für das Internet-Community Meeting: Swiss Internet User Group (SIUG), eine Initiative von /ch/open http://siug.ch/ Mit herzlichen Grüssen im Namen der SIUG Norbert Bollow

1 0

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 15 Apr '10

15 Apr '10

This is the fourth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. 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. DOCUMENTATION The following draft document was recently published: - Resolver Testing with a DURZ - TCR - Proposed Approach to Root Key Management ICANN has begun the process of formally soliciting expressions of interest for volunteers from the technical community to act as Trusted Community Representatives. These volunteers will witness cryptographic key ceremonies and also carry out various important roles relating to KSK key management. For more information, see: http://www.icann.org/en/announcements/announcement-12apr10-en.htm Expressions of interest can be submitted here: http://www.root-dnssec.org/tcr/ DEPLOYMENT STATUS KSR exchanges continue between production platforms at VeriSign and ICANN. Build-out of KSK Key Ceremony facilities at ICANN continues, and both facilities (east- and west-coast USA) are expected to be ready on schedule. 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 now made the transition to the DURZ. No harmful effects have been identified. Some early analysis of packet captures from many root servers surrounding each event was recently presented at the IETF meeting in Anaheim, CA, USA and can be found with other presentation materials at <http://www.root-dnssec.org/presentations/>. 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

Port 25 Blockade @ Swisscom (Bluewin)
by Steven.Glogger＠swisscom.com 14 Apr '10

14 Apr '10

Hi everyone To officially talk about the "mail problems on port 25 with swisscom dsl" I would like to give you some (technical) information. We had several needs to stop spam from our network: - We're receiving about 30'000-100'000 abuse complaints per month (contains multiple reports per case) - Mail filtering on our infrastructure (our mail servers) are only catching 20% of all spam sent from swisscom dsl - 80% is sent directly from the customer lines. (source: http://www.maawg.org/port25) - About 60% to over 90% of all mails sent over residential customer lines are identified as spam. This is more than 10 millions spam emails per day (~375 terabytes per year) The impacts are clear: - Spam generates a quite high amount of cost within Swisscom (money, personal, time, storage, data, etc.) - Our reputation is getting bad - We might get listed on blacklists (-> impact on legimite traffic) - Customers are getting blocked (e.g. in sandbox) and are not happy therefore (most of the customers are not realizing, that they are sending spam, because they are virus-/trojan-infected) So, what we did and what are we doing? We currently ran a pilot. The productive rollout which will affect all customers will start this week and will take around 2 months until all customers are migrated. Only (ex-)bluewin customers with dynamic adsl-lines will be affected. Swisscom has published an official statement on http://www.swisscom.ch/p25 and modifies the error-message sent to the customer which will be more clearer. The pilot showed very clearly that this countermeasure is very effectful in stopping outgoing spam. Going to the technical part: We're running a transparent proxy on port 25 (smtp) which gets communication from any customer to any port 25 (Layer 4 redirect feature). The proxy is analyzing the email and if it detects that spam has been sent he will reject the connection by issuing an error message to the customer (the mailclient will notice: smtp-error). If the mail is a normal and legitimate email -> no problem: mail will be sent. We will even insert a "received-from:" line in the header. If a bot/trojan is trying to send emails, the customer will not notice. There are no mails beeing stored on the filter server. All decisions are made on-the-fly. Customers, which are virus-affected are handled by the standard abuse process which we have in place (inform, quarantine in a sandbox, etc.). The option for layer 4 redirect is activated via radius - so it can be turned off on request and the customer just has to reconnect. For dynamic customers the option will be activated by default. Customers are asked to authenticate their smtp session and use the mail submission port 587 (not filtered). So, will this affect non-smtp traffic on port 25? Unfortunately, yes. This traffic will be lost. If the customer has a need to use port 25 for other purposes than email he can request turning of the redirecting feature. If a customer usses SSL via port 25 does it work? No, it will be dropped. Customers are kindly requested to use port 465 instead. If a customer uses smtp auth via port 25, will this work? He will receive a smtp error like "sorry, smtp auth not possible. use 587" (error 573). Will we start to block completely port 25 in the future? No, absolutely not. So, I hope things are now getting clearer ,-) Greetings -steven Steven Glogger ___________________________________________________________________________ Cisco CCIE#23778 Network Engineer Telefon +41 44 294 58 41 Mobile +41 79 277 92 35 Fax +41 86 079 277 92 35 steven.glogger(a)swisscom.com ___________________________________________________________________________ Swisscom (Schweiz) AG Network & IT Network Engineering & Operations Binzring 17 CH-8045 Zürich www.swisscom.com

11 14

Trusted Community Representatives
by Joe Abley 13 Apr '10

13 Apr '10

Colleagues, ICANN and VeriSign, with the support of the US Department of Commerce, continue to work towards DNSSEC deployment in the root zone of the DNS. ICANN is looking for Trusted Community Representatives (TCRs) to help us carry out various technical security operations. An announcement can be found here: <http://www.icann.org/en/announcements/announcement-12apr10-en.htm> You can submit an expression of interest here: <http://www.root-dnssec.org/tcr/> DNSSEC key ceremonies are carried out in English. TCRs must therefore have a good understanding of written and spoken English. Regards, Joe

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog