From munteanu.nicoleta at outlook.com Thu Apr 3 11:22:03 2025 From: munteanu.nicoleta at outlook.com (Nicoleta Munteanu) Date: Thu, 3 Apr 2025 11:22:03 +0000 Subject: [dns-operations] ROW14 - Call for proposals Message-ID: <41360CD9-179E-4EFC-9A26-D0F6B6E14A50@outlook.com> [cid:1933bf06-2ae0-438e-8360-64e417f9a30c] ROW14 Call for Proposals is Now Open! | September 30th, 2025 | Zoom Video Conference Since 2014, the Registration Operations Workshop (ROW), supported by our sponsors Verisign and ICANN, and more recently CIRA, brings together industry professionals?such as address/gTLD/ccTLD registries, domain name registrars, resellers, and second level domain registries?to share and discuss technical topics related to real-world experiences of implementing registration operations (RDAP, EPP, WHOIS, RPKI, Registry Lock, and many more). See all ROW events at: https://regiops.net/events The Program Committee is now accepting proposals for ROW14 and encourages you to submit a brief abstract outlining your presentation or panel proposal to row at cofomo.com by August 15th, 2025. We invite submissions guided by this non-exhaustive list of broad topics and welcome any discussions or suggestions for additional topics on ROW?s mailing list: regiops at googlegroups.com * Operational impacts of provisioning protocol migration * Examples of how AI is being used in the registration ecosystem * RDAP implementation experience * Implementation of NIS2 Directive * Best practices for DNSSEC Key management * DNS abuse (Global Signal Exchange, etc.) * Topics relevant to EPP, RPKI and other protocols relevant to Registration Systems (Domain Connect protocol, etc.) * Digital Identity topics (eIDAS, etc.) The Program Committee will inform selected authors by August 21st, 2025. Checkout other ROW14 important dates at: https://regiops.net. We look forward to receiving your proposals. Please feel free to share this call for proposals with other mailing lists and contacts who may find it relevant. Thank you. ROW Program Committee regiops.net | row at cofomo.com | regiops at googlegroups.com [https://lh7-rt.googleusercontent.com/docsz/AD_4nXcGH7nbT7uKRvVv1y5scPZw84ev5-NXy5psB1293DxoJ0401v-cpVo0GpljL7U-jLLqO4XLkDN6Sq5NhVJtDkHwVXMXVjjkAk6uwV6y85KosBn8MlW3x_UeJUYM4YwtdHgloCiwLWKGNoDBsrs8alxN8mRJ?key=XgxU7iFlXv-tXtxZ-S2IRQ] [https://lh7-rt.googleusercontent.com/docsz/AD_4nXfnu28zcP-hyznC-1wjuIeCqpFfU-TM-0NV-Oi1ztfh5yh4E_E3eTL-a-KBYsE_LfKGtCyvXMomE2PNixLCqI2I5gddP6GeWNzeOXNxqHVrdrsqlj7PeHSSbfKLisxcEegDHtCEpQ?key=XgxU7iFlXv-tXtxZ-S2IRQ] [https://lh7-rt.googleusercontent.com/docsz/AD_4nXcFxJL05AhEhDKcbUC0w1OU5CPb64WeI6_cUR3-_1EGcts0A_cw3tPf9P4CupUByAtUCJ-uYylTIfTjTlBvVO856leidffu3uYTCtgFqava43Hq8ytnxDD30dbMiFNwANqhjLwhcUYuE1R4ce9fg_wV79Yo?key=XgxU7iFlXv-tXtxZ-S2IRQ] This event is sponsored by Verisign, ICANN & CIRA and organized by Cofomo. Cross-posting to multiple lists - sorry for any duplicates. To stop receiving ROW updates, please reply ?unsubscribe? to this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 10660 bytes Desc: image.png URL: From manu.fuste at gmail.com Thu Apr 3 13:18:10 2025 From: manu.fuste at gmail.com (=?UTF-8?Q?Emmanuel_Fust=C3=A9?=) Date: Thu, 3 Apr 2025 15:18:10 +0200 Subject: [dns-operations] Spurious NXDOMAIN response from a DNS hosting provider Message-ID: <996e1b75-5bbc-48b9-88b0-8550ec719bf6@gmail.com> Hello, I'm facing a very disturbing DNS behavior from a DNS hosting provider (a big LoadBalancer maker). I have strong opinion about it, but before reporting to my client, I would like to get the opinions/arguments of experts present on this list as you can never be careful enough and should always approach things with humility. Months ago I noticed some spurious NXDOMAIN response from authoritative servers from one of my customer. It even could occur on the A or SOA record of the zone apex and was hard to reproduce. We end up with a test of 200 udp request in a row on the A record of the zone apex witch sometimes in the day trigger some NXDOMAIN answers, not the rest of time. We suspected a configuration issue, a race condition in the automated maintenance of zone data, server deployments, etc. This took months (almost a year) and exchange of numerous request/response logs on our end with the provider witch indicated that some fix/tuning was (unsuccessfully made) to finally get a definite answer: "A user is making multiple requests to a non-existing DNS domain. This behavior triggers a DDoS protection mechanism, which blocks the user's IP address. As a result, requests from the blocked IP return NXDOMAIN on existing records" Clarification about "non-existing DNS domain": We do query which end up with an authoritative NXDOMAIN. We do not do DNS query for witch the offended DNS is not authoritative for. My opinion is: - They break all DNS protocol promises, presenting "alternate" reality based on query rate - They talk about DDOS protection. But there is nothing "distributed" with one IP - It is even not a DOS protection mechanism as the server continue to answer NXDOMAIN at full rate - There is no rationale behind returning NXDOMAIN - It appears that no query rate limiting of any kind is implemented on their side. - IP based query rate limiting/drop is one of the core mechanism essential to any modern DNS implementation. - DNS should never completely stop responding to one IP, just as it should never arbitrary alter the value of an answer. I could be wrong and it's in fact a good behavior. I could be right and there is even more standard/RFC compliance arguments that could be leveraged against. Thank you. Emmanuel. From vladimir.cunat+ietf at nic.cz Thu Apr 3 13:57:08 2025 From: vladimir.cunat+ietf at nic.cz (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Thu, 3 Apr 2025 15:57:08 +0200 Subject: [dns-operations] Spurious NXDOMAIN response from a DNS hosting provider In-Reply-To: <996e1b75-5bbc-48b9-88b0-8550ec719bf6@gmail.com> References: <996e1b75-5bbc-48b9-88b0-8550ec719bf6@gmail.com> Message-ID: On 03/04/2025 15.18, Emmanuel Fust? wrote: > - DNS should never completely stop responding to one IP, just as it > should never arbitrary alter the value of an answer. Ideally yes, but... here's a consideration: if you don't reply or make some reply that looks like an error, the client is more likely to make more retries than when you reply with something that looks like a plausible answer.? That's just for non-intentional DoS and perhaps indirect attacks through some 3rd-party resolver, of course; direct intentional attackers won't care. Still, I most likely wouldn't use NXDOMAIN in this case. Also note that over UDP the source IP is spoofable, so attackers can leverage such anti-DoS mechanisms to better DoS other particular consumers of that server. --Vladimir | knot-resolver.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at sury.org Thu Apr 3 15:12:59 2025 From: ondrej at sury.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 3 Apr 2025 17:12:59 +0200 Subject: [dns-operations] Spurious NXDOMAIN response from a DNS hosting provider In-Reply-To: References: Message-ID: What Vl??a said - implementing RRL (e.g. return empty answer with TC bit), requiring DNS COOKIE or perhaps at least just generating SERVFAIL would be much better option. Giving back NXDOMAIN is ? misunderstanding DNS at best. Ondrej -- Ond?ej Sur? (He/Him) > On 3. 4. 2025, at 15:57, Vladim?r ?un?t wrote: > > ? > On 03/04/2025 15.18, Emmanuel Fust? wrote: >> - DNS should never completely stop responding to one IP, just as it should never arbitrary alter the value of an answer. > Ideally yes, but... here's a consideration: if you don't reply or make some reply that looks like an error, the client is more likely to make more retries than when you reply with something that looks like a plausible answer. That's just for non-intentional DoS and perhaps indirect attacks through some 3rd-party resolver, of course; direct intentional attackers won't care. > > Still, I most likely wouldn't use NXDOMAIN in this case. > > Also note that over UDP the source IP is spoofable, so attackers can leverage such anti-DoS mechanisms to better DoS other particular consumers of that server. > > --Vladimir | knot-resolver.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rebecca at dns-oarc.net Thu Apr 3 22:21:09 2025 From: rebecca at dns-oarc.net (Rebecca Petro) Date: Thu, 3 Apr 2025 18:21:09 -0400 Subject: [dns-operations] =?utf-8?q?Save_the_Date_=E2=80=93_OARC_45_in_St?= =?utf-8?q?ockholm=2C_7=E2=80=938_October_2025?= Message-ID: We?re excited to announce that OARC 45 will take place in Stockholm, Sweden on 7?8 October 2025, proudly hosted by our partners at Netnod. We look forward to welcoming the DNS-OARC community to this remarkable city for another engaging and collaborative workshop. Stay tuned for more details as they become available. ?Save the date and bookmark the event page: < https://www.dns-oarc.net/oarc45> Best regards, The DNS-OARC Team From walists at mailbox.org Thu Apr 3 14:01:39 2025 From: walists at mailbox.org (Winfried) Date: Thu, 03 Apr 2025 16:01:39 +0200 Subject: =?US-ASCII?Q?Re=3A_=5Bdns-operations=5D_Spurious_NXDOMAI?= =?US-ASCII?Q?N_response_from_a_DNS_hosting_provider?= In-Reply-To: <996e1b75-5bbc-48b9-88b0-8550ec719bf6@gmail.com> References: <996e1b75-5bbc-48b9-88b0-8550ec719bf6@gmail.com> Message-ID: Hi, Are you asking a resolver or the authority on the server itself when this happens? Someone might be more likely to help if you show us a real-world example (using dig) with the affected zone. Winfried Am 3. April 2025 15:18:10 MESZ schrieb "Emmanuel Fust?" : >Hello, > >I'm facing a very disturbing DNS behavior from a DNS hosting provider (a big LoadBalancer maker). >I have strong opinion about it, but before reporting to my client, I would like to get the opinions/arguments of experts present on this list as you can never be careful enough and should always approach things with humility. > >Months ago I noticed some spurious NXDOMAIN response from authoritative servers from one of my customer. >It even could occur on the A or SOA record of the zone apex and was hard to reproduce. >We end up with a test of 200 udp request in a row on the A record of the zone apex witch sometimes in the day trigger some NXDOMAIN answers, not the rest of time. >We suspected a configuration issue, a race condition in the automated maintenance of zone data, server deployments, etc. >This took months (almost a year) and exchange of numerous request/response logs on our end with the provider witch indicated that some fix/tuning was (unsuccessfully made) to finally get a definite answer: > >"A user is making multiple requests to a non-existing DNS domain. This behavior triggers a DDoS protection mechanism, which blocks the user's IP address. >As a result, requests from the blocked IP return NXDOMAIN on existing records" > >Clarification about "non-existing DNS domain": We do query which end up with an authoritative NXDOMAIN. We do not do DNS query for witch the offended DNS is not authoritative for. > >My opinion is: >- They break all DNS protocol promises, presenting "alternate" reality based on query rate >- They talk about DDOS protection. But there is nothing "distributed" with one IP >- It is even not a DOS protection mechanism as the server continue to answer NXDOMAIN at full rate >- There is no rationale behind returning NXDOMAIN >- It appears that no query rate limiting of any kind is implemented on their side. > >- IP based query rate limiting/drop is one of the core mechanism essential to any modern DNS implementation. >- DNS should never completely stop responding to one IP, just as it should never arbitrary alter the value of an answer. > >I could be wrong and it's in fact a good behavior. >I could be right and there is even more standard/RFC compliance arguments that could be leveraged against. > >Thank you. >Emmanuel. >_______________________________________________ >dns-operations mailing list >dns-operations at lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations