Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
It appears that Dr Eberhard W Lisse said: >The IANA Function Operator does so for all ccTLDs (which would imply all TLDs). Indeed, but some of them are lame anyway. Here's today's report: FAIL ne. bow.rain.fr. 194.51.3.49 All nameservers failed to answer the query ne. IN SOA: Server 194.51.3.49 UDP port 53 answered REFUSED FAIL ne. ns-ne.afrinic.net. 2001:43f8:120:0:0:0:0:45 All nameservers failed to answer the query ne. IN SOA: Server 2001:43f8:120:0:0:0:0:45 UDP port 53 answered REFUSED FAIL pg. ns1.tiare.net.pg. 202.165.192.23 All nameservers failed to answer the query pg. IN SOA: Server 202.165.192.23 UDP port 53 answered SERVFAIL FAIL ss. b.ns.tznic.or.tz. 196.216.162.70 All nameservers failed to answer the query ss. IN SOA: Server 196.216.162.70 UDP port 53 answered SERVFAIL FAIL tg. ns1.admin.net. 198.73.186.1 All nameservers failed to answer the query tg. IN SOA: Server 198.73.186.1 UDP port 53 answered SERVFAIL FAIL ye. ns1.yemen.net.ye. 65.162.184.33 All nameservers failed to answer the query ye. IN SOA: Server 65.162.184.33 UDP port 53 answered SERVFAIL FAIL ye. ns2.yemen.net.ye. 65.162.184.34 All nameservers failed to answer the query ye. IN SOA: Server 65.162.184.34 UDP port 53 answered SERVFAIL There are 96 more that timed out but I can't tell whether they really aren't there or it's a temporary network issue. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks
On Sat, May 6, 2023 at 19:10, Havard Eidnes <[h...@uninett.no](mailto:On Sat, May 6, 2023 at 19:10, Havard Eidnes < wrote: > So, you're arguing that it would be "causing too much work"(?) for > the registry to insist on having the registrant stand up a couple of > public name servers to register the publically visible version of a > domain? Really? No. I'm predicting that finding agreement on the right technical criteria and appropriate actions will be difficult, and finding agreement on the policy side across many different policy regimes will be more difficult. The difficulties I described were intended to illustrate that this is stuff is not necessarily easy, and that there are factors beyond the technical to think about. Whether it's too much work is a question for the working group, but I think it's a reasonable question. Joe >___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks
> Pre-delegation checks add friction to the domain registration > process. They further complicate the commuications between > different actors in the commercial graph (registrars, registries, > resellers, DNS operators, hosting companies) and introduce delay > and manual intervention into what might otherwise be a fairly > automated or at least automatable process. That is to say, checks > have a cost, and that cost might well be difficult to sell in a > commercial environment, especially one where the policy depends on > a membership that is often quite commercially motivated. (I > appreciate not all TLDs are the same.) Oh, yes, the sanctity of making a buck, "we can't let any technical obstacle get in it's way", and by extension "contributing to maintaining the good health of the public DNS doesn't really matter, as long as we get to collect the registration fees." I guess it depends on what service the registry is actually offering. One way to look at it is that it's offering a service to extend the public DNS name space to registrants. In that scenario it makes perfect sense to do a one-time check on initial registration or update, with the intention of preventing the domain owner from shooting himself in the foot. Another way would be to look at it as purely a name space administration issue, i.e. just ensure uniqueness, and let loose the commercial folks with their "product innovations" and "improved efficiency" aims, casting aside quite a few technical considerations for the public DNS. In case you haven't noticed, I have a distaste for the latter, and a number of registries operate with the former model. On the technical side, I don't think anyone has suggested to introduce repeated checks with de-registration either of a single NS or an entire domain on auto-polit. Does any public registry actually do that sort of thing? I've never heard of it. I call that a straw man. > On the technical side, I think arriving at a generalised approach > will be difficult. For example, > > 1. Repeated checks -- just because something is declared good at >registration time doesn't mean it might not go bad later. How >often do you need to check? You are assuming too much here, I think, in particular what the goal is and what the a reasonable mechanism to attain that goal could be. I've not argued to "outlaw inconsistencies or lameness", and it is true that such errors may be introduced over time outside of the interactions with the registry. What I have argued is that it's probably a good idea to check for consistency & service on the time of registration or update. > 2. The possibility of cascading failure -- a partial failure in a >delegation, if punished by a domain suspension, might result in >a complete failure. This is at worst an attack vector and at >best contrary to the interests of stability for users of the >Internet. Making automated changes to disable things that are >already demonstrably fragile seems a bit like form over >function. Again, here you're assuming that something doing a repeated check will automatically de-register a domain on auto-pilot. I certainly have not argued for such a thing, and would find the suggestion absurd. > 3. Deliberately-incoherent namespaces -- many of the most common >responses in the DNS are generated at response time according >to a variety of dynamic policy, and are subject to access >control. So vantage points matter. Any policy that is measuring >the health of a delegation needs to be able to interpret the >results of multiple measurements from different vantage points >and understand which of them correspond to a policy that is >acceptable, without any a priori understanding of what the >response generation policy is. In general I think this is >problematic. I don't think this is problematic at all. If a registrant wants to do "private stuff" with his domain, he'd do best in keeping that private, and the effects of that out of visibility for the registry. The registry should be checking the publically visible data, and is unlikely to have a probe for consistency checking within a "private DNS zone" of a registrant. And ... if you really insist on doing violence to the DNS standards and expectations of consistency, you're of course free to do whatever dirty deeds you have convinced yourself you need to do in a subdomain / sub-zone of your properly functioning public DNS domain. > 4. The fiction of a single namespace. The particular bits of >machinery that respond to particular names and particular >addresses (including nameserver names and nameserver addresses) >are not always the same. Private namespaces exist that avoid >collisions with the nominally-public namespace by making the >same companyname.com domain exist in both, but implementing >each very differently. This is valid and good advice, even >(e.g. compared to squatting on .HOME or
[DNSOP] FW: Approved: draft-ietf-dnsop-alt-tld-25.txt
Hi DNSOP WG, I just wanted to let you know that I have approved draft-ietf-dnsop-alt-tld-25 and hence it will move on to the RFC editor queue. I appreciate that this document hasn't been the easiest to move through the process but I hope that it will prove beneficial to IETF and the DNSOP WG in the longer term. I would like to thank the WG, the chairs, and the authors for all their reviews and help during the process. Regards, Rob // As responsible AD for this document. -Original Message- From: iesg On Behalf Of Robert Wilton via Datatracker Sent: 06 May 2023 19:33 To: i...@iesg.org Subject: Approved: draft-ietf-dnsop-alt-tld-25.txt Secretary (Bcc'ed): draft-ietf-dnsop-alt-tld-25.txt has been approved. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis one week extension for lame delegation definition
Dear WG, The extended WGLC rfc8499bis has been closed. With the specific question from the chairs, the WG did not find consensus on either of the two proposed definitions of the term "lame delegation". In one subthread of the discussion there was some convergence towards a definition, but in other subthreads we saw suggestions for new terms and definitions, which was not the question to the working group. The chairs are taking the current WGLC discussion into their evaluation of how to proceed and will share our way forward with the document in the first half next week. In the meantime, please continue the discussion. Best regards, -- Benno On 27/04/2023 22:05, Benno Overeinder wrote: Dear WG, The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion on lame delegation did not find consensus, but two specific suggestions were put forward. We would like to include one of them in rfc8499bis if we can get consensus to do so. The chairs are seeking input on the following two suggestions: * Either we leave the definition of “lame delegation” as it is with the comment that no consensus could be found, or * alternatively, we include a shorter definition without specific examples. 1) Leaving the definition of lame delegation as in the current draft-ietf-dnsop-rfc8499bis, and including the addition by the authors that: "These early definitions do not match current use of the term "lame delegation", but there is also no consensus on what a lame delegation is." (Maybe change to ... no consensus what *exactly* a lame delegation is.) 2) Update the definition as proposed by Duane and with the agreement of some others (see mailing list https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/): "A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS RRset or by the child's apex NS RRset answers non-authoritatively [or not at all] for a zone". The chairs ask the WG to discuss these two alternative definitions of the term "lame delegation". We close the consultation period on Thursday 4 May. Regards, Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks
Håvard, ccNSO has no role to play here. Each ccTLD makes its own rules, and not that it matters, being tiny, .NA does require working name servers (at registration, and when we check on it). el On 05/05/2023 19:01, Havard Eidnes wrote: >>> I imagine that others also spend time on sorting out these entirely >>> unnecessary issues. If guidance were developed on delegation >>> acceptance checks, >> >> Well, yes... but where? > > ccNSO, perhaps? > > My advice would be to only enforce checks where violations would > negatively impact operations (e.g. disallow lame delegation setups), > and not enforce pure "dotting the i's and crossing the t's" > requirements where doing so contributes minimal to no improvement > operationally. > >> To me it feels like the IETF would be the right place to discuss and >> develop the guidance (personally I think that a parent should check if the >> name servers that are being proposed actually answer for the domain[0], and >> strongly suggest (but do not prevent) that that be fixed[1]. > ... >> [0]: Some, including myself, would call this lame, but... > > Yup. > > I personally think that if a ccTLD insists on non-lame delegations at > the time of registration or update, I would not object. > >> [1]: As an example, I have a-random-test-domain.net pointing to >> nameservers which have no idea about this domain - and I did that >> intentionally... > > There's of course always the option of doing your own dirty work in a > child zone of your own properly delegated and operational domain. > > Regards, > > - Håvard -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist e...@lisse.na / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;/ Sect 20 of Act No. 4 of 2019 may apply ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
The IANA Function Operator does so for all ccTLDs (which would imply all TLDs). el On 06/05/2023 17:20, John Levine wrote: > It appears that Joe Abley said: >> Pre-delegation checks add friction to the domain registration >> process. They further complicate the commuications between different >> actors in the commercial graph (registrars, registries, resellers, >> DNS operators, hosting companies) and introduce delay and manual >> intervention into what might otherwise be a fairly automated or at >> least automatable process. ... > > Thirty years ago, when you did domain registrations by e-mail, the > registry which was then called Network Solutions did indeed check that > your name servers were active before delegating the domain. It was > not an accident that they stopped doing so, and it seems vanishingly > unlikely that any gTLD registry would do so now, regardless of what > people here might think. -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist e...@lisse.na / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;/ Sect 20 of Act No. 4 of 2019 may apply ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
It appears that Joe Abley said: >Pre-delegation checks add friction to the domain registration process. They >further complicate the commuications between different actors in the >commercial graph >(registrars, registries, resellers, DNS operators, hosting companies) and >introduce delay and manual intervention into what might otherwise be a fairly >automated >or at least automatable process. ... Thirty years ago, when you did domain registrations by e-mail, the registry which was then called Network Solutions did indeed check that your name servers were active before delegating the domain. It was not an accident that they stopped doing so, and it seems vanishingly unlikely that any gTLD registry would do so now, regardless of what people here might think. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
