Re: [dns-wg] RIPE NCC domain registrations
Moin! On 30 Jun 2015, at 14:30, Romeo Zwart wrote: > Dear colleagues, > > The RIPE NCC holds a number of domains besides ripe.net. > > Some of these domains were only registered as a "protection" > mechanism, which was considered good practice at the time. Is this considered bad practice now? Was there a policy change I missed? > We now plan to release the following domains, which are not being > actively used by the RIPE NCC: > > ripe-ncc.org > ripe-ncc.com > ripe-ncc.net > ripencc.com > ripencc.net > ripencc.org > ripelabs.net > ripen.cc > ripe.int > ipv6roadshow.com > ipv6roadshow.net > ipv6roadshow.org So we are talking about 12 domains. What is the hassle of keeping them? I'm pretty "confident" the new owners won't do as good things with it as the RIPE NCC. I would like to see more reasoning behind why you don't want to serve these 12 domains any longer. So long -Ralf
Re: [dns-wg] RIPE NCC domain registrations
Moin! On 30 Jun 2015, at 16:41, Jim Reid wrote: So we are talking about 12 domains. What is the hassle of keeping them? Adding cruft for cruft's sake creates needless hassles and overhead. We should all be wary about asking the NCC to make open-ended commitments and at the very least review those sorts of requests/decisions from time to time. From that perspective, getting a sense from the WG about these domain names is a good thing. That is a good argument. I like clean systems, we just have to weigh it against the effort and the possible damages. Running a couple of more domains doesn't seem like a big burden to me, a lot of people on this list host thousands or millions of domains. I'm pretty "confident" the new owners won't do as good things with it as the RIPE NCC. Who cares? If the domains no longer serve any useful purpose or have no worthwhile affiliation with the NCC or the RIPE community, there seems to be little point in keeping them. Or as was discussed a few months ago, there would be no point rolling over their DLV keys. Since DLV is going away, that may well be the catalyst to give some of these crufty domains a one-way ticket to Dignitas. I don't care about DLV as you know, but I am pretty sure these will be used in abuse going forward if the RIPE NCC releases them. The RIPE NCC name has some authority when it comes to IPv4 addresses It seems that people are not concerned about that and that's fine with me. I might just be overly paranoid, and have certain opinions on these domain and IPv4 traders. Holding on to these domains and continuing to maintain them "just because" seems unwise. ICANN already has ripe. on a reserved list so there is no chance of them going to an impostor. ripen.*, but not ripe(-)ncc.*. Will be interesting to see what happens to them. Personally speaking, I do not like open-ended commitments which are just allowed to drift. In this case, nobody appears to be sure why these domains need to exist any more or have a good reason to hold on to them. Romeo's asking the WG if there are good reasons, just in case there are factors which have been overlooked. If anyone knows of such considerations, please speak up. I did. Do whatever you want with it. If there are more people who think the NCC should drop them I'm a good democrat ;-). So long -Ralf
Re: [dns-wg] New on RIPE Labs: Securing Network Infrastructure for DNS Servers
Moin! On 28 Jun 2016, at 12:26, Mirjam Kuehne wrote: Dear colleagues, Ramtin Kiaei shows how to mitigate DNS attacks by implementing a stateless firewall filter at the aggregation or edge router. Please find his article on RIPE Labs: https://labs.ripe.net/Members/ramtin_kiaei/securing-network-infrastructure-for-dns-servers?pk_campaign=labs&pk_kwd=list-dnswg IMHO this is full of bad ideas and against protocol specs. While I agree that at these day and age one must defend against attacks on DNS systems, just blindly dropping on packet size or fragments is a very bad idea. Forwarding to 8.8.8.8 also is, although I know people who disagree with me on that. If you deploy this approach I'm pretty sure down the road you will spend endless ours trying to debug why something does not work and then find out that it's the filter on packet size you totally forgotten about. So long -Ralf
Re: [dns-wg] New on RIPE Labs: Securing Network Infrastructure for DNS Servers
Moin! On 29 Jun 2016, at 8:55, Henrik Lund Kramshøj wrote: and when being attacked the harm is already done, service will be interrupted if we do nothing … There is a difference on doing something as a response to attacks or having something hanging there that might treat you bad down the road. so the talk about these boxes throwing away some traffic, bad middleboxes etc. These are not middleboxes, but part of the overall solution at the end-network - and as such they increase operational cost - but they bring more resilience and stability to the service. They even work using the existing hardware devices in many circumstances, making the cost less than buying “DDoS protection service box model 2000" YMMV, and you should always consider your own environment, adding DNSSEC comments are great etc. Some things SHOULD be discarded, others rate-limited I don't have problems with discarding, but again it should be done where the impact is understood and a router doesn't have that. Doing opaque dropping to the outbound of a resolver even while part of the solution can have weird effects and should be avoided. and shameless link https://ripe72.ripe.net/wp-content/uploads/presentations/32-simulated-ddos-ripe.pdf which has similar advise Again that was during the attack and not permanent (Anand can correct me if I got it wrong). Also this was an authoritative server which has a different defence pattern that a resolver that was described in the article. So long -Ralf
Re: [dns-wg] nomination for DNS WG co-chair
Moin! On 1 Sep 2016, at 14:57, Peter Koch wrote: > for the vacant position as a DNS WG co-chair I would like to nominate > Ralf Weber <https://de.linkedin.com/in/fl1ger>. > > Ralf has been an active and thoughtful member of the DNS community > within RIPE and beyond for a longer while. He is familiar with various > roles in the DNS, be that vendor, operator, registry or registrar. And of > course, he's on this list and will join the thread to respond to > questions the group might have. Thanks Peter for the nomination. I feel honoured and of course would like to help the RIPE DNS community as DNS WG co-chair should the working group decide to select me. My bills are payed since 1994 by working on delivering DNS services starting at a regional ISP and then at larger operators covering Europe, where I also became involved in the RIPE community I currently work at a DNS software vendor (Nominum Inc.) that supplies software to ISPs and Telcos around the world. I also helped DENIC as member of the technical advisory council to get .de DNSSEC signed. Most of my work has been on operating recursive DNS and recently the security challenges that come with that (unfortunately mostly DDOS and abuse and not DNSSEC), and while I do code (mostly python these days), it's usually operations related and not core DNS software (There are smarter people than myself to do this ;-). The RIPE DNS working group was always at the forefront of DNS operations and research and if appointed as co-chair I'll do my best to continue the good work of Jim and Peter. If you have any questions feel free to reach out to me. So long -Ralf
Re: [dns-wg] 2017 dns-wg co-chair appointment
Moin! On 1 Sep 2017, at 8:52, Joao Damas wrote: Dear all, With this email I would like to put my name forward as a candidate for the DNS WG cochair role as announced yesterday by the current co-chairs. I have been involved in the DNS WG at RIPE for a long time, contributing when and where possible throughout the years during my time at the RIPE NCC, ISC, Dyn, Bondis and APNIC. This trajectory has made me fairly familiar with the DNS world, its history and evolution as well as the current topics under discussion. As you might also know, I am currently co-chair of the Routing WG, a role which I am intending to pass on to a new co-chair at the WG meeting during RIPE 75 (Email regarding this matter is not yet out due to the fact I want to finalise the text by talking to the other Routing WG co-chair before sending the announcement to the list and summer has made coordination a bit harder). As has been the case for the last several years, one of my goals continues to be to bring to RIPE new interesting topics and new interesting people so we can all grow. Hopefully I will have the wg’s support I'll fly support Jao as co-chair for the DNS working group. So long -Ralf
Re: [dns-wg] NCC reverse delegation criteria
Moin! On 11 Jun 2019, at 20:40, Jonas Frey wrote: > I do see 3 major benefits to combine/unify these: > - "saving" IP addresses (depending of how many you run of course[1]) Should not be a problem with IPv6, and running the same function like http on the same IP is quite different from running different functions (recursive vs authoritative DNS) on the same IP. > - less effort managing (not having multiple places for configuration > thus unifiying [automated] setup) That is wrong. You have more efforts managing as you need to update the sever software more often. I can not count the numbers of times some CVE in bind was caused by the fact that it is both a recursive and authoritative server. From a security these have different attack scenarios and you now need to take care of both and some mitigations are only applicable to one function. > - saving ressources (servers, virtual machines, whatever they run on) Those are machine resources and cheap. Your manpower resources running mixed servers are higher as you have to be a lot more careful how you treat a mixed function dns server. Even pur bind shops these days run there servers with only one function. And all modern DNS software is either authoritative or recursive and there is a good reason for that. Unless you believe people dealing with this for decades are wrong. So long -Ralf —-- Ralf Weber
Re: [dns-wg] New on RIPE Labs: NXNSAttack: Upgrade Resolvers to Stop New Kind of Random Subdomain Attack
Moin! On 20 May 2020, at 16:43, Mirjam Kuehne wrote: > This article by Petr Špaček of CZ.NIC describes a newly discovered DNS > protocol vulnerability that affects all recursive DNS resolvers. That is not exactly true and while I normally would not have bothered to correct that, but I had to answer quite a few customer questions yesterday, so here we are. Akamai/Nominum Cacheserve and Akamai/Xerocole AnswerX are not affected by this. We had limits in the software for this in the Cacheserve case from day one. Would appreciate if you could correct that in the article. So long -Ralf —-- Ralf Weber
Re: [dns-wg] Volunteer list for RIPE DNS working group chair
Moin! On 14 Oct 2020, at 15:29, Dave Knight wrote: The nomination period for the RIPE DNS working group chair selection has completed with a single volunteer, Joao Damas. I support Joao’s appointment as DNS working group chair and want to thank him for his continued service. So long -Ralf ——- Ralf Weber
Re: [dns-wg] Sony Wins Pirate Site Blocking Order Against DNS-Resolver Quad9
Moin! On 21 Jun 2021, at 13:15, Stephane Bortzmeyer wrote: > I think it is the first time there is a court ruling specifically > against a public DNS resolver? > > https://torrentfreak.com/sony-wins-pirate-site-blocking-order-against-dns-resolver-quad9-210621/ > > Note the reasoning (if some german-speaking person can confirm this is > a fair summary?): Well its a preliminary ruling, so I would not read to much into it yet. This will take years to sort out especially as Quad9 said they would defend against it. Here is the link to the German article about it on heise: https://www.heise.de/news/Urheberrechtsverletzung-Sony-erwirkt-einstweilige-Verfuegung-gegen-DNS-Resolver-6111633.html There are high hurdles for getting a blocking order in Germany even for ISPs, however there were some cases that were successful. My personal opinion as a German citizen is that if ISPs have to block a site via DNS because it is illegal then the DNS Cloud providers should also have to block it. I see no reason why they should be treated differently. >> One of the arguments that Sony brought up in court was that Quad9 >> already blocks various problematic sites voluntarily. > > This is indeed common in court: either you are neutral or you are not > and, in the second case, you can no longer claim you are "just an > intermediary". When you start filtering DNS answers, it is hard to > resist pressures to add more filtering. Interesting wasn’t aware of this angle to it, but IANAL. So long -Ralf --- Ralf Weber
Re: [dns-wg] DNS4EU?
Moin! On 15 Nov 2021, at 7:57, Stephane Bortzmeyer wrote: > Political pressure on Mozilla so that they use by default the DoH > resolver of DNS4EU? It is not "forcing" (users can still disable it) > but it is close. It was Mozilla that came up with the bad idea of using a default DoH resolver instead of using the network provided one. I always said that was a bad idea. > A similar (?) case: > > https://www.cira.ca/newsroom/canadian-shield/mozilla-partners-cira-upgrade-canadas-online-privacy-through-firefox I can see no downside on that. Canadian people now use a in country provider instead of the default US based provider. As said the bad idea was setting a default. That at least is a better default for Canadians. So long -Ralf ——- Ralf Weber To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
Moin! On 29 Nov 2021, at 12:59, Anand Buddhdev wrote: > We propose to lower, in the first quarter of 2022, the TTL on NS records to > 86400 and on DS records to 3600. I very much support that and would go even lower for for NS records. Maybe consider 21600 there. So long -Ralf ——- Ralf Weber To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] DNS wg co-chair selection: candidates
Moin! On 9 Oct 2022, at 19:43, Shane Kerr wrote: > Colleagues, > > The deadline for the DNS co-chair candidate volunteering is now over. > > We have a single excellent candidate. > > The period to express support (or concern) for the candidate starts now and > runs until Wednesday, 26 October 2022. > > Below find a few words from the candidate. > > > Willem Toorop > > I propose myself as a candidate to follow-up Shane as DNS working group > co-chair. I support the selection of Willem as the next RIPE DNS working group co-chair and wish him a successful tenure. So long -Ralf ——- Ralf Weber -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] Draft of RIPE DNS Resolver Best Common Practices
Moin! On 26 Nov 2023, at 18:01, Shane Kerr wrote: > ### Aggressive NSEC caching > > **Aggressive NSEC caching should be enabled.** > > For: Public resolver operators. > > "Aggressive NSEC caching", meaning negative caching based on NSEC and > NSEC3 values, can reduce traffic greatly. It is important to protect > against random subdomain attacks. > > This style of caching takes advantage of the way that NSEC and NSEC3 > records cover a range of names in a zone. A resolver can know that a > query falls within such a range without sending any further queries, > by remembering the NSEC or NSEC3 redords that is has seen as answers > to earlier queries. > > Aggressive NSEC caching is almost always a good idea. However enabling > this is less important for DNS resolver operators who have a close > relationship with users, since they can stop attacks by blocking users > or otherwise directly dealing with the source of abusive queries. > > [RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes > negative caching in detail. So I would disagree with this section for a couple of reasons. First not all resolver software might have the data structures to allow that. Second it becomes more and more obsolete with authorities doing DNSSEC black and white lies meaning the send the minimal covering NSEC. And given that especially providers with large domain portfolios do that the odds of finding a DNSSEC based domain where this actually would are low. So I would downgrade that to a “may” and also lighten the language a bit as there afaik have been no incidents where it actually helped. > ### DNS Cookies > > **Interoperable DNS Cookies should be supported.** > > For: Public resolver operators. > > DNS cookies provide some improved security over plain UDP, and are > designed to be more lightweight than TCP. If more than one server is > responding for a given IP address, then the Server Secret must be > shared by all servers, and the answer must be constructed in a > consistent manner by all server implementations. > > Since client-side support for DNS cookies is not very widespread, and > since managing server-side secrets involves some work, the costs may > outweigh the benefits for some non-public resolver operators. > > [RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS > cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) > standardizes shared DNS cookies. Same as above may instead of should. While it theoretically might seem like a good idea, the practical deployed implementations have shown its not: https://casey.byu.edu/papers/2021_pam_dns_cookies.pdf > ### Filtering and blocking > > Legal blocking: > **Legal requests and blocking and filtering laws:** DNS resolvers > should not filter content and block access to web-services. When the > local law requires blocking, and the law applies to the resolver, the > resolver should transparently disclose a list of blocked websites and > services. There are cases where this is not possible, eg. the law forbids it. We should IMHO at least acknowledge that. > RPZ-based filtering > > Response Policy Zone (RPZ) allows a way to both document specific > modifications that resolvers will make to DNS answers, and send the > rules to resolvers. Resolvers can be directed to block or modify > answers in various ways. Blocklists may be provided by governments, > communities, or other parties (for example security firms) using RPZ. > This allows updates to occur very quickly. These source must be highly > trusted, as changes to blocklists will usually immediately impact user > queries. > > RPZ is not standardized, but there is an IETF draft, > [draft-vixie-dnsop-dns-rpz](https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/). RPZ is just one mechanism to do this. It has nothing to do with the actual content. Shouldn’t we generalise that requirement and just talk about blocklists and not the mechanism? Overall the document is an extensive well written overview of the DNS resolver problem space and I would like to thank the members of the RIPE DNS Resolver BCP Task Force for all of their hard work on this. So long -Ralf --- Ralf Weber -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
