- dns-wg - mailman.ripe.net

DANE goes mainstream?
by Jim Reid 09 Apr '20

09 Apr '20

Microsoft has announced Office 365 Exchange Online is going to support DNSSEC and DANE: https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-a…

4 4

RIPE DNS WG meeting - April 15th
by Joao Luis Silva Damas 08 Apr '20

08 Apr '20

Dear all, As you may know RIPE 80 is going “virtual”, or online. The DNS WG chairs will testing a slightly different format, with online sessions focusing on DNS topics throughout the next months. The first session will take place on April 15th (Wednesday) at 15:00 CEST, using Zoom, provided by the RIPE NCC. The session topic is “Keeping the root zone signed when standard plans won’t work”. We will count with a presentation from Kim Davies of PTI/ICANN. We will provide the URL for the meeting as soon as possible, so stay tuned. Needless to say, as this is a RIPE community meeting the all RIPE meeting participation rules apply, including the RIPE code of conduct. Hoping to meet you online soon, Joao Damas for the DNS WG chairs.

1 1

Contingency plans for the next Root KSK Ceremony
by Jim Reid 26 Mar '20

26 Mar '20

FYI. If you have comments or questions, please contact Kim or one of the TCRs. > Begin forwarded message: > > From: Kim Davies <kim.davies(a)iana.org> > Subject: [RZERC] Contingency plans for the next Root KSK Ceremony > Date: 26 March 2020 at 01:52:29 GMT > To: "rzerc(a)icann.org" <rzerc(a)icann.org> > > Colleagues, > > (Feel free to circulate within your respective groups as you see fit.) > > The IANA team, and the broader ICANN organization, have been giving significant thought to the Coronavirus pandemic and its impact on root zone KSK operations. Managing the KSK is centred on conducting "key signing ceremonies", where trusted community representatives (TCRs) attend from around the world to witness utilization of the root zone KSK private key. This approach seeks to engender trust in the broader community that the key has not been compromised, in addition to more typical controls such as third-party auditing. > > In light of world events we have developed contingency plans around how to hold key ceremonies in the short term. To that end, we identified a graduated set of options, in summary: > Hold the next ceremony as planned on April 23, with a quorum of participants globally. > Hold the next ceremony on a different date using only US-based TCRs. > Hold the next ceremony using our disaster recovery procedure, which provides for a staff-only ceremony (i.e. no TCRs would be physically present). > In general, our goal has been to navigate from Option 1, and if that is not possible, Option 2, and so on. However, at this time, our focus is on developing a plan around Option 3. > > The ceremony is currently scheduled unusually early in the quarter (it is typically held in May), and needs to be held to generate signatures that will be needed in production for July. Our contingency plan is comprised of: > > Holding the ceremony with a bare minimum of staff (approximately 6); > Using 3 TCRs’ credentials, either by having their access key transferred to us in a secure manner in advance of the ceremony, or by drilling the safety deposit box that holds their secure elements. > Holding the ceremony under typical audit coverage, allowing for remote witnessing of events by all, plus providing additional opportunities for TCRs to stay involved in the process remotely. > Signing key materials to cover one or more subsequent quarters, to provide relief from the need to necessarily hold ceremonies later in 2020 if circumstances disallow it. (The additional signatures would be withheld securely until they are needed.) > Our key management facilities were designed with the disaster recovery capability of performing staff-only ceremonies in mind, but this is a significant shift from normal operations and we want to promote broader community awareness of this work. Those directly involved in key ceremonies - the trusted community representatives, our vendors and auditors - have been consulted and are broadly supportive of this effort. > > Should there be any specific feedback you would like to share with our team, please let me know or respond to this thread. We will take it into consideration as we finalize our plans. > Thank you for your support.

1 0

New on RIPE Labs: The Best Laid Plans…
by Mirjam Kuehne 25 Mar '20

25 Mar '20

Dear colleagues, How a virus can impact the carefully formulated plans that were made for signing the DNS root zone: The Best Laid Plans… (by João Luis Silva Damas) on RIPE Labs: https://labs.ripe.net/Members/joao_luis_silva_damas/the-best-laid-plans Kind regards, Mirjam Kühne RIPE NCC

1 0

Hidden master maintenance
by Anand Buddhdev 05 Mar '20

05 Mar '20

Dear colleagues, The RIPE NCC runs a pair of hidden masters for transferring in zones from various sources, and distributiong these zones to the K-root and reverse DNS anycast clusters that we operate. On Thursday 5 March 2020, between 12:00 and 17:00 UTC, we will be doing maintenance on one of these servers. In this duration, the server will be offline for some time. Its IP addresses are: 93.175.159.250 2001:67c:2d7c:66::53 This maintenance will not affect service in any way. The other hidden master will continue to function and keep all our DNS servers up to date. After the maintenance, I will send a follow-up message. Regards, Anand Buddhdev RIPE NCC

2 2

New on RIPE Labs: Detecting and Taking Down Fraudulent Webshops at the .nl ccTLD
by Mirjam Kuehne 26 Feb '20

26 Feb '20

Dear colleagues, In this article, Giovane Moura and Thymen Wabeke describe how they detected and took down a large number of fraudulent web sites using tools developed by SIDN Labs: https://labs.ripe.net/Members/giovane_moura/detecting-and-taking-down-fraud… Kind regards, Mirjam Kühne RIPE NCC

1 0

Call for contributions to the RIPE 80 meeting of the dns-wg
by Dave Knight 20 Jan '20

20 Jan '20

Colleagues, RIPE 80 in Berlin is 16 weeks away and we’d like to form our agenda. Please submit your presentation ideas, or suggestions for discussions to <dns-wg-chairs(a)ripe.net>. Please don’t submit anything using the meeting submission web form, it’s not intended for submission of content to working groups. Thanks! dave, for the working group chairs

1 0

Call for Presentations: 33rd DNS-OARC Workshop, Paris, France, May 09 - 10th 2019
by Dave Knight 13 Jan '20

13 Jan '20

Colleagues, The 33rd DNS-OARC Workshop will take place at the Marriott Rive Gauche Hotel & Conference Center in Paris, France on May 9th and 10th 2020. It is co-located with and will take place right after the ICANN GDD (May 3rd to 6th), Registrations Operations Workshop (May 6th) and ICANN DNS Symposium (May 7th and 8th). The Workshop's Program Committee is requesting proposals for presentations. All DNS-related subjects are welcome. A time slot will also be available for lightning talks (5-10 minutes each) on day two of the workshop, for which submissions will be accepted just before the start of the workshop and until the start of the morning break on day two. Poster submissions are also welcome. There will be an OARC Business session during the workshop, which will be for OARC Members only. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 10 Jan 2020 - Submissions open via Indico 05 Mar 2020 - Deadline for submission (midnight CEST) 19 Mar 2020 - Initial Contribution list published 02 Apr 2020 - Full agenda published 02 May 2020 - Deadline for slideset submission 09 May 2020 - Workshop begins Details for presentation submission are published here: <https://indico.dns-oarc.net/event/34/call-for-abstracts/> The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> <your name here>, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) Kind regards, Dave, for the DNS OARC Programme Committee

1 0

Resolve DNS Queries Based on Source IPs in BIND (NEED ADVISE)
by Md. abdullah Al naser 19 Nov '19

19 Nov '19

Hi everyone, I hope you all are fine. I am new in the mailing list and looking for an advise. If this mailing-list is not suitable for my below query then please pardon me. I am stuck in a situation and looking for a solution. My scenario is like below. I want to block some websites for my all users. For example:www.abc.comwww.xyz.cometc I did it using Response Policy Zone (RPZ) in BIND. response-policy {zone "rpz";};rrset-order { order cyclic; }; zone "rpz" { type master; allow-query { any; }; file "/etc/bind/rpz.db"; }; In my RPZ zone file I created CNAME entries for above mentioned FQDNs which have been pointed to discard.websites.com www.abc.com IN CNAME discard.websites.com.;www.xyz.com IN CNAME discard.websites.com.; And later on, in websites.com zone file (which is another fake zone) I created an A record for discard.websites.com which has been pointed to 192.168.127.127 (a fake IP). discard IN A 192.168.127.127; In this way all the dns requests from my all users for above mentioned sites are resolved to 192.168.127.127 and the real websites are unreachable. (N.B. I am not worry about the situation when users change their DNS IP to any open resolver and can access the websites.) Everything was going fine. By this time another requirement came into the picture. Now I need to block the mentioned websites for some specific users (based on source IP). So in my RPZ configuration I specified the users source IP block like below. zone "rpz" { type master; allow-query { 192.168.10.0/24; }; file "/etc/bind/rpz.db"; }; At this point the dns queries from the specified block 192.168.10.0/24 are resolved to my fake ip and all other requests from rest of IP blocks are dropped (as expected as per configuration). But I want to do like this, the dns queries from 192.168.10.0/24 blocks will be matched with RPZ zone and other requests from rest of IPs will bypass the RPZ configuration and will match my general "allow-query {any;}" statement mentioned in named.conf file. Will the logic work as I stated above?? Any comments from the experts will be great for me. (N.B. I came to know that, resolving different IP based on different source can be possible in KNOT DNS, but I would be happy to do it in BIND (if possible). Thanks & Regards, Md. Abdullah Al NaserDhaka, Bangladesh

2 1

New on RIPE Labs: Analysing the Costs (and Benefits) of DNS, DoT, and DoH for the Modern Web
by Mirjam Kuehne 28 Oct '19

28 Oct '19

Dear colleagues, For those of you who missed Austin Hounsel's presentation at RIPE 79, here is his article on RIPE Labs: Analysing the Costs (and Benefits) of DNS, DoT, and DoH for the Modern Web https://labs.ripe.net/Members/austin_hounsel/analysing-the-costs-and-benefi… Kind regards, Mirjam Kühne RIPE NCC

1 0