From mir at ripe.net Mon Oct 3 16:56:10 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 03 Oct 2011 16:56:10 +0200 Subject: [dns-wg] Read on RIPE Labs: F-root IPv6 Route Leak - the DNSMON View Message-ID: <4E89CD0A.8080609@ripe.net> 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 From kzorba at otenet.gr Wed Oct 5 08:22:58 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Wed, 05 Oct 2011 09:22:58 +0300 Subject: [dns-wg] Moneytizing error pages using DNS Message-ID: <87ipo4q7nh.fsf@enigma.otenet.gr> 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 /\ From jim at rfc1035.com Wed Oct 5 11:22:17 2011 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Oct 2011 10:22:17 +0100 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <87ipo4q7nh.fsf@enigma.otenet.gr> References: <87ipo4q7nh.fsf@enigma.otenet.gr> Message-ID: <687277BD-9FFE-4E43-BDEF-3D582389C889@rfc1035.com> On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote: > .... Of course, the solution involves NXDOMAIN remapping. > > We as technical people are against the idea. Well duh! :-) > Apart from technical implications that are difficult to explain to > non-technical people, we would like to have some arguments > supporting our position. IMO Kostas, technical arguments are probably not going to be heard, no matter how distinguished the DNS experts are. Though one killer argument against NXDOMAIN rewriting could be DNSSEC. First off, it stops this nonsense. Or it reduces the scope for selling adverts when customers switch on DNSSEC or switch to a (paid for?) "secure" DNS resolving service. Next, DNSSEC deployment will be made more tricky for you if there are NXDOMAIN rewriters spreading their special kind of magic inside your network. Increased operating and support costs might support your position. For instance, maybe you'll need an extra DNS infrastructure: a "clean" one to run the network and another to do NXDOMAIN rewriting. [Maybe you'll have yet another for customers who expect a DNS service that doesn't tell lies.] This will of course complicate things and make life difficult for those doing customer support. For instance, what they see with the "clean" DNS is not the same as what the customers see. Bad Things happen to various services like email: mail goes to the IP address that serves up adverts instead of getting bounced. This could have all sorts of nasty legal issues: privacy, lawful intercept, etc. Remember the IAB statement on wildcarding which followed the SiteFinder debacle? However I doubt the beancounters and other members of the B ark will care about any of this. They will be salivating at the prospect of earning zillions from pay-per-click. So I think you need to construct arguments on business grounds: cost/benefit analysis, return on investment, customer support issues, etc. Questions that might be worth asking are how much money has the subsidiary spent on its NXDOMAIN solution, how much revenue it raises, what are the actual operating costs. I expect honest answers to these should settle the issue in your favour. Though the inevitable problem in most organisations is hadly anyone knows what DNS actually costs to run or the business impact of any service disruption. From jim at rfc1035.com Wed Oct 5 11:37:43 2011 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Oct 2011 10:37:43 +0100 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <87ipo4q7nh.fsf@enigma.otenet.gr> References: <87ipo4q7nh.fsf@enigma.otenet.gr> Message-ID: On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote: > Apart from respected voices expressing their opposition to such > techniques [1] > > [1] http://queue.acm.org/detail.cfm?id=1647302 IMO it would be unwise to reference this article in any arguments you make. It could rebound on you very badly. BIND9.9 can do NXDOMAIN rewriting. So presumably ISC thinks this sort of thing is OK now. Sigh. If/when your opponents find this out, it fatally undermines the very sensible things said in that article. From uhlar at fantomas.sk Wed Oct 5 12:00:42 2011 From: uhlar at fantomas.sk (Matus UHLAR - fantomas) Date: Wed, 5 Oct 2011 12:00:42 +0200 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: References: <87ipo4q7nh.fsf@enigma.otenet.gr> Message-ID: <20111005100042.GA5852@fantomas.sk> >On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote: >>Apart from respected voices expressing their opposition to such >>techniques [1] >> >>[1] http://queue.acm.org/detail.cfm?id=1647302 On 05.10.11 10:37, Jim Reid wrote: >IMO it would be unwise to reference this article in any arguments you >make. It could rebound on you very badly. BIND9.9 can do NXDOMAIN >rewriting. So presumably ISC thinks this sort of thing is OK now. Actually, they do not. They only think that if someone should do it, (s)he should do it correctly and (they think) it's better to have the feature in BIND insteat of letting violators to implement it (and usually break it) themselves. I (and many other people) have disagreed with this point in bind-users mailing list. >Sigh. If/when your opponents find this out, it fatally undermines the >very sensible things said in that article. That's one of reason why I think it's bad feature to have in BIND. -- Matus UHLAR - fantomas, uhlar at 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. Linux IS user friendly, it's just selective who its friends are... From fweimer at bfk.de Wed Oct 5 11:46:19 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 05 Oct 2011 09:46:19 +0000 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <87ipo4q7nh.fsf@enigma.otenet.gr> (Kostas Zorbadelos's message of "Wed, 05 Oct 2011 09:22:58 +0300") References: <87ipo4q7nh.fsf@enigma.otenet.gr> Message-ID: <82vcs3kbys.fsf@mid.bfk.de> * Kostas Zorbadelos: > 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. BIND 9.9 will support NXDOMAIN and NODATA rewriting. This might change the trade-offs involved in a rather radical way. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jim at rfc1035.com Wed Oct 5 17:13:03 2011 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Oct 2011 16:13:03 +0100 Subject: [dns-wg] NXDOMAIN rewriting in BIND9.9+ In-Reply-To: <20111005100042.GA5852@fantomas.sk> References: <87ipo4q7nh.fsf@enigma.otenet.gr> <20111005100042.GA5852@fantomas.sk> Message-ID: <320D5B38-8D06-45AC-9FC9-79E714DF9473@rfc1035.com> On 5 Oct 2011, at 11:00, Matus UHLAR - fantomas wrote: > On 05.10.11 10:37, Jim Reid wrote: >> IMO it would be unwise to reference this article in any arguments >> you make. It could rebound on you very badly. BIND9.9 can do >> NXDOMAIN rewriting. So presumably ISC thinks this sort of thing is >> OK now. > > Actually, they do not. Well it seems ISC has a rather strange way of showing their disapproval. If ISC truly thought NXDOMAIN rewriting was a Bad Idea, they would not have allowed this feature to embed itself in the reference DNS implementation. QED. IMO it sends out the wrong sort of messages and encourages those who advocate Stupid DNS Tricks. It's all very well for ISC to say they're just offering a "safer" way for people to play with these things. I take the view that this is a bit like letting children experiment with sharp objects when there's no responsible adult in charge. >> Sigh. If/when your opponents find this out, it fatally undermines >> the very sensible things said in that article. > > That's one of reason why I think it's bad feature to have in BIND. +1. I'm very disappointed ISC has gone down this path. From drc at virtualized.org Wed Oct 5 17:06:12 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Oct 2011 08:06:12 -0700 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <687277BD-9FFE-4E43-BDEF-3D582389C889@rfc1035.com> References: <87ipo4q7nh.fsf@enigma.otenet.gr> <687277BD-9FFE-4E43-BDEF-3D582389C889@rfc1035.com> Message-ID: On Oct 5, 2011, at 2:22 AM, Jim Reid wrote: > IMO Kostas, technical arguments are probably not going to be heard, no matter how distinguished the DNS experts are. Though one killer argument against NXDOMAIN rewriting could be DNSSEC. First off, it stops this nonsense. Not necessarily. NXDOMAIN rewriting can occur _after_ validation. If you as an end user are relying on your ISP for resolution service, you are accepting whatever they tell you, be it truthful or lies. If your ISP blocks you from doing your own resolution, look for a new ISP (or VPN out to a resolver you trust). > However I doubt the beancounters and other members of the B ark will care about any of this. Yep. On the brighter side, I've heard from folks involved in (very large) DNS infrastructure who have deployed NXDOMAIN redirection that the amount of money it brings in wasn't worth it and they're discontinuing the redirection stuff. Regards, -drc From yiorgos.adamopoulos at gmail.com Wed Oct 5 19:16:05 2011 From: yiorgos.adamopoulos at gmail.com (Yiorgos Adamopoulos) Date: Wed, 5 Oct 2011 20:16:05 +0300 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <87ipo4q7nh.fsf@enigma.otenet.gr> References: <87ipo4q7nh.fsf@enigma.otenet.gr> Message-ID: On Wed, Oct 5, 2011 at 9:22 AM, Kostas Zorbadelos wrote: > 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. Your best bet is to take this subject to the National Regulator (EETT). Since you cannot do this directly, you will insist on consulting with your legal department insisting that they research whether the National Regulator permits this, or it opens the possibility of a fine after users complain. Do not fight this inside the company. Change the terrain and take it where it really matters. -- http://gr.linkedin.com/in/yiorgos From vladimirvic at telekom.rs Thu Oct 6 11:32:39 2011 From: vladimirvic at telekom.rs (Vladimir Vico) Date: Thu, 6 Oct 2011 11:32:39 +0200 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <87ipo4q7nh.fsf@enigma.otenet.gr> References: <87ipo4q7nh.fsf@enigma.otenet.gr> Message-ID: <19B0FF6E4ABDC847BE243F94532A5ADE4C18631CA1@CCR3.it.telekom.yu> Hi, There is a bunch of arguments in this document by ICANN's Security and Stability Advisory Committee: http://www.icann.org/en/committees/security/sac032.pdf -- Vladimir Vico From kzorba at otenet.gr Thu Oct 6 14:17:04 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Thu, 06 Oct 2011 15:17:04 +0300 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: (Jim Reid's message of "Wed, 5 Oct 2011 10:37:43 +0100") References: <87ipo4q7nh.fsf@enigma.otenet.gr> Message-ID: <877h4il3gf.fsf@enigma.otenet.gr> Jim Reid writes: > On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote: > Thanks to everyone that provided feedback, on and off-list :) I think I have enough information to contruct my case. >> Apart from respected voices expressing their opposition to such >> techniques [1] >> >> [1] http://queue.acm.org/detail.cfm?id=1647302 > > IMO it would be unwise to reference this article in any arguments you > make. It could rebound on you very badly. BIND9.9 can do NXDOMAIN > rewriting. So presumably ISC thinks this sort of thing is OK now. > Sigh. If/when your opponents find this out, it fatally undermines the > very sensible things said in that article. > Now, this article also contains opinions on other matters I am not sure I support. For example, it also criticizes badly the use of DNS for load balancing on the grounds of "DNS was not designed to express policy". And what happens when a single machine is not enough to accomodate load? Do you employ NAT load balancers? Is this a better idea? Having a single "name" for a "service" seems to me like a good idea in general. Anyway, long talk, I guess it needs a thread of its own. Thanks again, Kostas PS1: Jim, you should REALLY reconsider your mail blacklist policies. Unless you do not prefer mail for person-to-person communication ;-) PS2: +1 against ISC for allowing the "feature" in bind. -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\ From rwl at tele.gl Thu Oct 6 15:04:08 2011 From: rwl at tele.gl (Rasmus Larsen) Date: Thu, 06 Oct 2011 11:04:08 -0200 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <877h4il3gf.fsf@enigma.otenet.gr> References: <87ipo4q7nh.fsf@enigma.otenet.gr> <877h4il3gf.fsf@enigma.otenet.gr> Message-ID: <1317906248.2624.51.camel@localhost> On Thu, 2011-10-06 at 15:17 +0300, Kostas Zorbadelos wrote: > Now, this article also contains opinions on other matters I am not sure > I support. For example, it also criticizes badly the use of DNS for load > balancing on the grounds of "DNS was not designed to express > policy". And what happens when a single machine is not enough to > accomodate load? Do you employ NAT load balancers? Is this a better > idea? Having a single "name" for a "service" seems to me like a good > idea in general. > Anyway, long talk, I guess it needs a thread of its own. Agreed, in particular NAT load balancers either limit the use of IPSEC in transport mode (which will become viable with ipv6), or will break horribly when people start using it. From my point of view, DNS seems to be the best load balancing strategy out there. Regards, Rasmus Larsen From kzorba at otenet.gr Fri Oct 7 13:47:28 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Fri, 07 Oct 2011 14:47:28 +0300 Subject: [dns-wg] [Jim Reid personal contact, rest please ignore] spam defences Message-ID: <87k48hhvlb.fsf@enigma.otenet.gr> 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 /\ From kzorba at otenet.gr Fri Oct 7 14:10:14 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Fri, 07 Oct 2011 15:10:14 +0300 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <1317906248.2624.51.camel@localhost> (Rasmus Larsen's message of "Thu, 06 Oct 2011 11:04:08 -0200") References: <87ipo4q7nh.fsf@enigma.otenet.gr> <877h4il3gf.fsf@enigma.otenet.gr> <1317906248.2624.51.camel@localhost> Message-ID: <87ehyphujd.fsf@enigma.otenet.gr> Rasmus Larsen writes: > On Thu, 2011-10-06 at 15:17 +0300, Kostas Zorbadelos wrote: I don't know where it is best to start a discussion for this but I admit that load balancing interests me. >> Now, this article also contains opinions on other matters I am not sure >> I support. For example, it also criticizes badly the use of DNS for load >> balancing on the grounds of "DNS was not designed to express >> policy". And what happens when a single machine is not enough to >> accomodate load? Do you employ NAT load balancers? Is this a better >> idea? Having a single "name" for a "service" seems to me like a good >> idea in general. >> Anyway, long talk, I guess it needs a thread of its own. > > Agreed, in particular NAT load balancers either limit the use of IPSEC > in transport mode (which will become viable with ipv6), or will break > horribly when people start using it. From my point of view, DNS seems to > be the best load balancing strategy out there. > This is a drawback in NAT load balancers I hadn't considered. Nice to know. Generally speaking, load balancing can be addressed either at the DNS or the routing layer. I am not aware of a "universal and clean" solution that would fit all purposes. An extra interesting thing is what will be used in IPv6 environments (which is a question posed also in the v6 WG in regards to RIPE 501) > Regards, > Rasmus Larsen > -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\ From uhlar at fantomas.sk Sat Oct 8 15:56:47 2011 From: uhlar at fantomas.sk (Matus UHLAR - fantomas) Date: Sat, 8 Oct 2011 15:56:47 +0200 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <1317906248.2624.51.camel@localhost> References: <87ipo4q7nh.fsf@enigma.otenet.gr> <877h4il3gf.fsf@enigma.otenet.gr> <1317906248.2624.51.camel@localhost> Message-ID: <20111008135647.GA11071@fantomas.sk> >On Thu, 2011-10-06 at 15:17 +0300, Kostas Zorbadelos wrote: >> Now, this article also contains opinions on other matters I am not sure >> I support. For example, it also criticizes badly the use of DNS for load >> balancing on the grounds of "DNS was not designed to express >> policy". And what happens when a single machine is not enough to >> accomodate load? Do you employ NAT load balancers? Is this a better >> idea? Having a single "name" for a "service" seems to me like a good >> idea in general. >> Anyway, long talk, I guess it needs a thread of its own. On 06.10.11 11:04, Rasmus Larsen wrote: >Agreed, in particular NAT load balancers either limit the use of IPSEC >in transport mode (which will become viable with ipv6), or will break >horribly when people start using it. From my point of view, DNS seems to >be the best load balancing strategy out there. I'd say that's still problem of those load balancers, or their configuration (or IPSEC configuration). DNS is still one of worst place to try load balancing and failover switching. -- Matus UHLAR - fantomas, uhlar at 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. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... From Woeber at CC.UniVie.ac.at Mon Oct 10 12:39:33 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 10 Oct 2011 10:39:33 +0000 Subject: [dns-wg] Moneytizing error pages using DNS In-Reply-To: <20111008135647.GA11071@fantomas.sk> References: <87ipo4q7nh.fsf@enigma.otenet.gr> <877h4il3gf.fsf@enigma.otenet.gr> <1317906248.2624.51.camel@localhost> <20111008135647.GA11071@fantomas.sk> Message-ID: <4E92CB65.7080602@CC.UniVie.ac.at> Matus UHLAR - fantomas wrote: [...] > DNS is still one of worst place to try load balancing and failover > switching. While I do agree with regard to failover, I am less convinced with regard to load balancing. Isn't that more like a question of: on which layer or plane do you want load balancing to happen? Like - fine-grained vs coarse-grained, TCP-connection-based, source-address of DNS client,... From jaap at NLnetLabs.nl Wed Oct 12 11:29:12 2011 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 12 Oct 2011 11:29:12 +0200 Subject: [dns-wg] Wanted: DNS WG Agenda items Message-ID: <201110120929.p9C9TC2a017329@bartok.nlnetlabs.nl> Dear all, Maybe it is was a bit early, but my previous request didn't raise a lot of responses, so here is it again. We still have agenda slots available for the WG meetings. Do claim the slot you want before they are gone or suggest topics to discuss; to be informed about etc. Remember, it is your working group and you meeting. Regards, jaap From mir at ripe.net Wed Oct 12 12:00:45 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 12 Oct 2011 12:00:45 +0200 Subject: [dns-wg] New article on RIPE Labs: Large-scale PCAP Data Analysis Using Apache Hadoop Message-ID: <4E95654D.2060504@ripe.net> Dear colleagues, Please find a new article on RIPE Labs: "Large-scale PCAP Data Analysis Using Apache Hadoop" http://labs.ripe.net/Members/wnagele/large-scale-pcap-data-analysis-using-apache-hadoop Kind regards, Mirjam Kuehne RIPE NCC From aferrara at uniplan.it Fri Oct 14 15:35:40 2011 From: aferrara at uniplan.it (Antonio Ferrara) Date: Fri, 14 Oct 2011 15:35:40 +0200 Subject: [dns-wg] PROBLEM_NO_REVERSE_MAPPING for entity Message-ID: 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. www.gesema.uniplan.it. IN A 85.33.176.119 $ORIGIN uniplan.it. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anandb at ripe.net Fri Oct 14 16:08:19 2011 From: anandb at ripe.net (Anand Buddhdev) Date: Fri, 14 Oct 2011 16:08:19 +0200 Subject: [dns-wg] PROBLEM_NO_REVERSE_MAPPING for entity In-Reply-To: References: Message-ID: <4E984253.3050902@ripe.net> On 14/10/2011 15:35, Antonio Ferrara wrote: Hi Antonio, > I have created this reverse zone: > > 217.20.0. Your reverse zone should be 0.20.217.in-addr.arpa. Please read the howto on the RIPE NCC website for help with setting up reverse DNS, and requesting delegation: http://www.ripe.net/data-tools/dns/reverse-dns/how-to-set-up-reverse-delegation Regards, Anand Buddhdev RIPE NCC From leo.vegoda at icann.org Mon Oct 17 22:21:41 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 17 Oct 2011 13:21:41 -0700 Subject: [dns-wg] Variant Issues Project -- Case Study Reports Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341837800EE92E@EXVPMBX100-1.exc.icann.org> 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 From wnagele at ripe.net Wed Oct 19 20:14:44 2011 From: wnagele at ripe.net (Wolfgang Nagele) Date: Wed, 19 Oct 2011 20:14:44 +0200 Subject: [dns-wg] Update to DNSSEC Policy and Practice Statement (DPS) Message-ID: -----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-statement Regards, Wolfgang Nagele, RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk6fE5QACgkQjO7G63Byy8fI6ACfa+zLgmkbaP6gK98BQsX0G5HG qpEAnRI7714fx+ANIPmJkL6qBQplsft1 =auU8 -----END PGP SIGNATURE----- From wnagele at ripe.net Wed Oct 26 10:55:43 2011 From: wnagele at ripe.net (Wolfgang Nagele) Date: Wed, 26 Oct 2011 10:55:43 +0200 Subject: [dns-wg] PGP Key signing Party at RIPE 63 Message-ID: -----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----- From jaap at NLnetLabs.nl Wed Oct 26 21:45:59 2011 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 26 Oct 2011 21:45:59 +0200 Subject: [dns-wg] Agenda WG meetings Message-ID: <201110261945.p9QJjxqO089923@bartok.nlnetlabs.nl> 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 $