- dns-wg - mailman.ripe.net

New RIPE Labs: RIPE Atlas & Anycast Instance Switches
by Mirjam Kuehne 22 Dec '11

22 Dec '11

[apologies for duplicate mails] Dear colleagues, RIPE Atlas can now test packet flows from more than 1000 vantage points on the Internet. We took a quick look at anycast traffic to DNS root name servers. There is a lot of interesting signal in this data. See the results on RIPE Labs: https://labs.ripe.net/Members/dfk/ripe-atlas-and-anycast-instance-switches Kind Regards, Mirjam Kuehne RIPE NCC

1 0

DNS Test Lab and Regression Testing
by Daniel Karrenberg 10 Nov '11

10 Nov '11

I got several questions in the hallway. Here is a flashback to 9y ago about DNS server regression testing and the differences that then existed between bind and NSD: http://meetings.ripe.net/ripe-43/presentations/ripe43-dnr-distel/index.html It is worth noting that at the time the testing was done "black box". While I was involved in getting NSD off the ground and I contributed to the basic design, I withdrew once implementation started and never saw a single line of code. I apologise for this spam and the way the slides are presented. Otoh it is a charming reminder of the way my slides looked like those days. ;-) Daniel

2 1

Agenda WG meetings
by Jaap Akkerhuis 26 Oct '11

26 Oct '11

Here is the current draft ageda. I'm afraid some holes still to need to be filled in. jaap --------- DNS WG, Thursday November 3 09:00-10:30, Morning Session I A. Administrative matters o Welcome o Scribe selection/introduction o Jabber selection/introduction o Microphone Etiquette o Finalise agenda B. Matters arising from RIPE-63 Minutes and Review of Action items (No open items?) C. IETF Reports - unknown volunteer What transpired on the DNSEXT & DNSOP meetings during the last IETF D. DNS operations at RIPE-NCC - Wolfgang Nagele E. Knot – a new high-performance authoritative name server Ľuboš Slovák (CZ.NIC) Knot is an authoritative DNS server developed in CZ.NIC Labs. It offers performance comparable or better than the most widely used implementations and advanced functionality in the same time. The main features of the server will be summarized together with some basic insight into the internals and a comparison with other implementations (BIND, NSD). F. Beyond Bind and NSD - Peter Janssen, EUrid. EUrid developed a new nameserver. The motivation of taking on this work will be explained. A performance comparison with BIND & NSD will be given. Additional functionality for integration purposes with backend systems will be explained. ___________________ DNS WG, Thursday November 3 11:00-12:30, Morning Session II G. What was all that traffic to the root - Wolfgang Nagele This summer there was for a short time some excessive increased query load on the root name servers. Wolfgang will present a report on the event. H. DNSSEC-Trigger - Olaf Kolkman NLnet Labs developed an application for use in DNSSEC hostile environments such as behind NATs, internet in hotels, you neighbourhood coffeshop etc. I. The IDN Variant Issues Project, an Update - Joe Abley ICANN started a study to get insight into the prob;em of variants for the same IDNs. Six case studies has been completed in the following six scripts: Arabic, Chinese (Han script), Cyrillic, Devanagari, Greek, and Latin and the reports are open for review. K. News from the DNS-EASY - Stéphane Bortzmeyer The Global Cyber Security Center in Rome organized with ICANN a conference about DNS Health" which was followed by a workshop on DNS Security Stability and Resiliency. L. Discussion "Domain Name Synthesis--For Fun, Profit and Law Abiding Citizens." There is more and more pressure to manipulate results from DNS queries to Enhance the User Experience, Protect users against bad Content (malware, porno etc.) or to protect Intellectual Property rights. Panelists are not fully known yet; suggestions are welcome. Z. AOB (Any Other Business) If you have AOB to discuss, let the chair person know in advance so some time might be reserved for that $Id: agenda-wg,v 1.5 2011/10/26 19:41:24 jaap Exp jaap $

1 0

PGP Key signing Party at RIPE 63
by Wolfgang Nagele 26 Oct '11

26 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicates] Dear colleagues, It has become a sort of tradition to have a PGP key signing party (http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html) during RIPE meetings. If you would like to take part this time during RIPE 63 in Vienna (http://ripe63.ripe.net), join us on Wednesday, 2 November 2011 at 15:30 (during the coffee break) at the registration desk. The process for the signing will be: 1. Add your public key to the keyring (http://biglumber.com/x/web?keyring=4320). In order for me to be able to print the list, the deadline for this is Wednesday, 2 November 2011 at 12:00. 2. You will be provided with a printout of the keyring. It is important that you verify your own fingerprint on it with a trusted copy of your key fingerprint. 3. After we are all gathered, we will take it in turns to read our own key fingerprint so everyone else can verify it on the printout provided. It is best to check off the fingerprints you have verified on the list. 4. Next we will verify the identity of the key owner by using a legal document (passport, driver's license, etc.). For each identity you have verified you can add another checkmark on the printout. 5. Now the official part of the party is finished and once you get back home you can download the keyring and sign each key that you validated. It is easy to identify those by having two checkmarks on the printout. You should then provide the owner of that key with your signed version and possibly upload it to a key-server. If you have any questions or problems, please feel free to contact me. You may also spread the word through other information channels. Regards, Wolfgang Nagele, RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk6nyw8ACgkQjO7G63Byy8fhGgCdHzO5k9srWXmEXkFcU0StlRZ/ 4akAoJd9TLQej1mF+lLrPnFjXc5qNijJ =e2DN -----END PGP SIGNATURE-----

1 0

Update to DNSSEC Policy and Practice Statement (DPS)
by Wolfgang Nagele 19 Oct '11

19 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, Today we have updated our DNSSEC Policy and Practice Statement (DPS). The most notable change to the policy has been a change to the Key Usage Period section. We have extended the usage period of a Key Signing Key (KSK) to one year from previously 6 months. You can find the updated version here: http://www.ripe.net/data-tools/dns/dnssec/dnssec-policy-and-practice-statem… Regards, Wolfgang Nagele, RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk6fE5QACgkQjO7G63Byy8fI6ACfa+zLgmkbaP6gK98BQsX0G5HG qpEAnRI7714fx+ANIPmJkL6qBQplsft1 =auU8 -----END PGP SIGNATURE-----

1 0

Variant Issues Project -- Case Study Reports
by Leo Vegoda 17 Oct '11

17 Oct '11

Hi, ICANN is currently conducting a public comment period on six case studies of individual scripts to investigate any issues that need to be resolved to facilitate a good user experience for IDN variant TLDs. The public comments received will inform the formulation of the combined issues report. If you have an interest in the possibility of IDN variant TLDs, please provide comments by 14 November. The Latin, Greek & Cyrillic Case Study Teams' Issues Reports and public comment forums can be found at: http://www.icann.org/en/public-comment/idn-vip-latin-07oct11-en.htm http://www.icann.org/en/public-comment/idn-vip-greek-07oct11-en.htm http://www.icann.org/en/public-comment/idn-vip-cyrillic-06oct11-en.htm Regards, Leo

1 0

PROBLEM_NO_REVERSE_MAPPING for entity
by Antonio Ferrara 14 Oct '11

14 Oct '11

I apologize if I re-post this message. But I had problems with the mail server and I'm not sure that it was posted. Hi, I have this zone: uniplan.it $ORIGIN . $TTL 3600 ; 1 hour uniplan.it IN SOA uniserv.uniplan.it. admin.uniplan.it. ( 2011101402 3600 1800 1209600 86400 ) $TTL 86400 ; 1 day NS uniserv.uniplan.it. NS uniserv1.uniplan.it. NS webserver.uniplan.it. $TTL 3600 ; 1 hour A 217.20.0.2 MX 10 uniserv.uniplan.it. $ORIGIN uniplan.it. axis2100 A 217.20.0.15 board A 217.20.0.140 clessidra A 217.20.0.32 $ORIGIN clessidra.uniplan.it. www A 217.20.0.32 $ORIGIN uniplan.it. frattamaggiore A 85.44.177.45 $ORIGIN frattamaggiore.uniplan.it. www A 85.44.177.45 $ORIGIN uniplan.it. ftp CNAME uniserv gargano A 217.20.0.73 $ORIGIN gargano.uniplan.it. www A 217.20.0.73 $ORIGIN uniplan.it. gesema.uniplan.it. IN A 85.33.176.119 $ORIGIN gesema.uniplan.it. <http://www.gesema.uniplan.it> www.gesema.uniplan.it. IN A 85.33.176.119 $ORIGIN uniplan.it. <http://www.gesemaeco> www.gesemaeco A 85.18.249.93 gm A 172.16.1.246 gm1mex A 172.16.80.61 gm2mex A 172.16.1.222 gm3mex A 172.16.1.222 localhost A 127.0.0.1 mailserver A 217.20.0.31 $ORIGIN mailserver.uniplan.it. mailserver A 217.20.0.31 $TTL 86400 ; 1 day $ORIGIN uniplan.it. $TTL 3600 ; 1 hour nt01 A 217.20.0.179 nt02 A 217.20.3.20 nt03 A 217.20.1.150 $TTL 86400 ; 1 day ovi A 217.20.0.31 $TTL 3600 ; 1 hour pomilia A 151.58.32.85 $ORIGIN pomilia.uniplan.it. www A 151.58.32.85 $ORIGIN uniplan.it. posta A 217.20.1.150 $ORIGIN posta.uniplan.it. www A 217.20.1.150 $ORIGIN uniplan.it. postfix A 217.20.0.76 radio A 217.20.0.73 $ORIGIN radio.uniplan.it. www A 217.20.0.73 $ORIGIN uniplan.it. rcis-01 A 217.20.0.1 rcis-02 A 217.20.0.14 rliv01-02 A 217.20.0.10 rliv02-02 A 217.20.0.13 rliv03-02 A 217.20.0.12 rliv04-02 A 217.20.0.11 sanmarcocavoti A 172.16.40.206 $ORIGIN sanmarcocavoti.uniplan.it. www A 172.16.40.206 $ORIGIN uniplan.it. spin0 A 217.20.1.8 spin1 A 217.20.3.3 spin2 A 217.20.3.2 spin3 A 217.20.3.103 www.radio.tanagro A 85.44.172.158 $TTL 14400 ; 4 hours uniplan TXT "v=spf1 a mx -all" $TTL 3600 ; 1 hour uniserv.uniplan.it. IN A 217.20.0.2 uniserv1.uniplan.it. IN A 217.20.0.3 watch02 A 217.20.0.176 watch03 A 217.20.0.177 weblinux A 217.20.0.72 webserver.uniplan.it. IN A 217.20.0.30 www CNAME uniserv www4 A 217.20.0.73 gol.uniplan.it. IN A 217.20.1.150 mailserver-dns.uniplan.it. IN A 217.20.0.2 uniserv.uniplan.it. PTR 217.20.0.2 uniserv1.uniplan.it. PTR 217.20.0.3 webserver.uniplan.it. PTR 217.20.0.30 I have created this reverse zone: 217.20.0. $ttl 38400 @ IN SOA uniserv.uniplan.it. system.uniplan.it. ( 2011101403 10800 3600 604800 38400 ) 2 IN NS uniserv.uniplan.it. 3 IN NS uniserv.uniplan.it. 30 IN NS uniserv.uniplan.it. 2 IN PTR uniserv.uniplan.it. 3 IN PTR uniserv1.uniplan.it. 30 IN PTR webserver.uniplan.it. I have tested the zone with RIPE Zone Delegation Checker and I have this error: >Check uniserv.uniplan.it details PROBLEM_NO_REVERSE_MAPPING for entity uniserv.uniplan.it >Args: 217.20.0.2, uniserv.uniplan.it >Check uniserv1.uniplan.it details PROBLEM_NO_REVERSE_MAPPING for entity uniserv1.uniplan.it >Args: 217.20.0.3, uniserv1.uniplan.it >Check webserver.uniplan.it details PROBLEM_NO_REVERSE_MAPPING for entity webserver.uniplan.it >Args: 217.20.0.30, webserver.uniplan.it Can you help me to solve this error? Thanks.

2 1

Moneytizing error pages using DNS
by Kostas Zorbadelos 10 Oct '11

10 Oct '11

Greetings to all, as you might guess from the subject, this mail is about a bad DNS trick. Our commercial people have been approached by some people in a subsidiary company trying to sell a "moneytizing product" that takes advantage of user error pages when serfing the web. In the subsidiary company the solution is already deployed in their production and it also involves cooperation with a search engine. The important thing is that Google refused to cooperate with them and they expressed their position against moneytizing error pages. Of course, the solution involves NXDOMAIN remapping. We as technical people are against the idea. Apart from technical implications that are difficult to explain to non-technical people, we would like to have some arguments supporting our position. Since a lot of people in this list might already have come across the problem (and some might already have implemented such a thing) I would be interested to hear your oppinions. Apart from respected voices expressing their opposition to such techniques [1], I would be interested in other arguments such as legal implications, costs or any other arguments anyone has used in a similar situation. By the way, there is an expired Informational rfc about the subject [2]. Cheers, Kostas [1] http://queue.acm.org/detail.cfm?id=1647302 [2] http://tools.ietf.org/html/draft-livingood-dns-redirect-03 -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\

9 13

[Jim Reid personal contact, rest please ignore] spam defences
by Kostas Zorbadelos 07 Oct '11

07 Oct '11

First of all apologies in advance for this. This is a message addressed to Jim Reid. I have no other means of personal communication, you seem to block my main OTENET address plus my gmail address (to both addresses I know for you, since the one redirects to the other). If you care, either whitelist the domain "eng.otenet.gr" or provide me another address with no "paranoid" SPAM defenses. Sorry for the noise on the list. Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\

1 0

Read on RIPE Labs: F-root IPv6 Route Leak - the DNSMON View
by Mirjam Kuehne 03 Oct '11

03 Oct '11

Dear colleagues, Prompted by a discussion on the nanog mailing list about an F-root IPv6 route leak, we were curious what DNSMON shows about that event. Read an article Emile Aben just published on RIPE Labs: http://labs.ripe.net/Members/emileaben/f-root-route-leak-the-dnsmon-view If you have any comments or questions, please feel free to post them under the article. Kind Regards, Mirjam Kuehne RIPE NCC

1 0