Re: [regext] Publication has been requested for draft-ietf-regext-rdap-reverse-search-22

[Mario Loffredo]

Hi Murray,

thanks for your reply.

Please find my responses inline.

Il 25/07/2023 22:49, Murray S. Kucherawy ha scritto:
On Tue, Jul 11, 2023 at 8:44 AM Mario Loffredo 
 wrote:




* In Sections 12.2.3.2 and 12.2.4.2, the individual entries are
run together into one big blob.  Could we get blank lines between
them, or maybe put each in its own subsection if necessary?  Or
make it a table?


[ML] I know that the layout is redundant and not compact at all
but it's the only one making the JSONPath expressions quite readable.

I can move the fileds assuming always the same value (e.g.
"Related Resource Type", "Registrant Name" and "Registrant
Information") at the beginning so that each group of properties
related to an entry in the IANA registry gets shorter.

Does it work for you ?

Looks like you could put each of the four registrations in its own 
subsection to nail this down.  But what's weird is that if I view it here:


https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-22

...it's all mashed together, but when I view it here:

https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-22.html

...it looks fine.

Let's just leave it for now (unless you like the subsections idea) and 
ask the RFC Editor to help with formatting.  It may become an issue 
earlier if IANA finds it confusing.
[ML] Hope I made it more readable. Let's how it will be rendered. I 
checked the layout in TXT, HTML and PDF and looks good to me.




* In Section 13, we have a "REQUIRED" followed by some
non-specific advice about what to implement.  This doesn't seem
like a good use of BCP 14 key words.  Can we say it some other way?


[ML] Would it be better to use "SHOULD" instead of "are REQUIRED to" ?


I would change "are REQUIRED" to "need".  The problem I have is that 
saying "you are REQUIRED to assure privacy" doesn't tell the 
implementer exactly what needs to happen to interoperate or assure 
privacy, so being able to specify what it will take to comply isn't 
possible.  It's like the difference between saying "you MUST make sure 
your data are secured somehow" versus "you MUST use TLS 1.3"; it's 
easy to prove compliance with one of those, but not the other.

[ML] Agreed.




* Section 3 should probably specify what should happen if the
JSONpath refers to an attribute/value that's not present in the
object it's referencing.


[ML] The JSONPath expressions related to reverse search properties
are provided by servers and have been previously registered with
IANA, hence they have been checked by Designated Experts. It's
very unlikely they are wrong. Can't imagine how clients can
operate when servers provide wrong information. I mean, servers
can return an error code when clients include wrong or unsupported
reverse search properties in thei requests, but servers are always
expected to provide correct data.


It just feels strange to presume you will always have valid input and 
never discuss error condition handling.  I'm still learning about 
JSONpath (it's also in "AD Evaluation") so maybe this is a teachable 
moment for me, but it seems like there's a presumption that a query 
will always be run against a value that will resolve; is that the case 
here too?  Maybe we should say that if so.


[ML] Probably I didn't make myself clear or I still don't catch your 
remark. The JSONPath expressions are provided by servers to help clients 
in linking the available reverse search properties to the reponse 
fields. Client can only use the reverse search properties in their 
queries. The invalid use of both reverse search poperties and predicates 
by clients results in servers returning an error as defined in Section 7:


*
*

*Servers MUST return an HTTP 501 (Not Implemented) **[RFC9110 
]**response 
to inform clients of unsupported reverse searches.*


*Based on their policy, servers MAY restrict how predicates are used to 
make a valid search condition, by returning a 400 (Bad Request) response 
when a problematic request is received.*



Obviously, it can happen that a server returns  an either wrong or 
unmatched JSONPath expression in the reverse_search_properties_mapping 
member. In this case, think there are two options for the client:


1) The JSONPath expression is wrong but the related reverse search 
property works (e.g. the propertyPath value for the "email" reverse 
search property is "$.entities[*].vcardArray[1][?(@[0]=='email')][*2*]" 
instead of "$.entities[*].vcardArray[1][?(@[0]=='email')][*3*]"). The 
server will return a valid response. If a client will discover the 
mistake in JSONPath expression, the server will be informed about it in 
an out-of-band communication.


2) The JSONPath expression is supposedly correct but the related reverse 

Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

[Gould, James]

James,

I find your historic EPP server policies to be very interesting.  I provide 
comments embedded with your points below with a “JG – “ prefix.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of James Mitchell 

Date: Tuesday, July 25, 2023 at 5:39 PM
To: "Hollenbeck, Scott" 
Cc: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] [Ext] [DNSOP] Best Practices for Managing 
Existing Delegations When Deleting a Domain or Host

Feedback my own and not from IANA.

If I recall correctly, the approach I took when building an EPP server several 
years ago was:

  *   allow deletion of domains with linked subordinate hosts – there is no 
need to prevent this if the registrar can simply rename the subordinate hosts 
and free themselves of this restriction

JG - Allowing the deletion of the parent domain with a set of linked child 
hosts can result in an extremely large OLTP transaction and more importantly 
can result in severe DNS delegation issues.  This is even more for the bad case 
of an accidently or maliciously deletion.  There is no way for the registry to 
know whether the deletion is a good case or a bad case, and with both cases the 
size of the OLTP transaction can result in system stability issues.  I would 
not leave the lame delegations, so that means a cascade delete from the parent 
domain to all child hosts and all name server links to those child hosts.  
Imagine if registrar accidentally or maliciously deleted a large ISP domain 
name (e.g., isp.example) with a large set of child hosts that are linked to 
thousands of domain names.  There are other bad things a registrar could do, 
such as putting the clientHold status on the ISP domain name, but that can be 
easily reversed.  Bad deletes and updates can be protected via a registry lock 
service, but otherwise the registry needs to reduce the blast radius based on 
the data it has available.



  *   when the domain is removed from DNS (deletion, but also 
client/serverHold) then the delegation and any glue is removed from the DNS – 
queries for the name result in NXDomain. I believe we left lame delegations 
from other domains for simplicity, but these lame nameservers could also have 
been pulled from the DNS.

JG – Leaving the lame nameserver delegations in place would be a referential 
integrity issue in the registry database, assuming that the name server object 
model is being used.


  *   when the domain is purged, purge all subordinate hosts, including all 
their nameserver associations, and remove those records from the DNS. At this 
point there are no NS records with target at or below the deleted domain - no 
lame delegations.

JG – This moves the large OLTP transaction problem to the backend with the 
purge.  The DNS resolution issues would have occurred upfront when the parent 
domain is deleted.


  *   domains with one remaining name server remain published in the DNS

JG – The number of domains linked to the deleted child hosts is 
non-deterministic, so there will be some that still have active delegating name 
servers and some that have none after the delete and purge.

It may be worth noting that we used a narrow glue policy - only publish glue 
address records for name servers below the delegation. A wide glue policy may 
require slightly different actions to prevent promoting glue records to 
authoritative.

JG – The glue could be required for all internal hosts.

Host rename always seemed a dangerous operation – we ended up allowing it but 
restricted to renaming hosts within the same domain, eg ns1.example.com to 
nsa.example.com, but not to nsa.another-example.com.

JG – The host rename is a real use case that can certainly include renaming 
outside of the parent domain.  To handle the rename outside of the parent 
domain with the restricted policy, the registrar would need to create a new 
internal host or external host and require all linked domain names to be 
updated to point to it instead of the old host.  There can be thousands of 
linked domain names that would need to be updated and there is no formal method 
of communication to inform them to update their domain names.  Did a registrar 
have an issue with this restriction?

I was not okay with allowing a third-party registrar to prevent deletion of a 
domain by creating subordinate hosts, and I was not okay by allowing one 
registrar to change the delegation for another domain (through a rename outside 
the existing domain boundary).

JG – Is there a use case of wanting to prevent the deletion of a domain by 
creating child hosts?  This may be a valid use case, but I simply haven’t come 
across it.

Best,
James Mitchell

On Jul 11, 2023, at 12:07 PM, Hollenbeck, Scott 
 wrote:
Folks, we could really use feedback from people with DNS expertise to help
document a set of best practices for managing

Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

[Peter Thomassen]

James,

On 7/26/23 06:22, Gould, James wrote:

  * allow deletion of domains with linked subordinate hosts – there is no need 
to prevent this if the registrar can simply rename the subordinate hosts and 
free themselves of this restriction

JG - [...]  I would not leave the lame delegations, so that means a cascade delete from the parent domain to all child hosts and all name server links to those child hosts.  Imagine if registrar accidentally or maliciously deleted a large ISP domain name (e.g., isp.example) with a large set of child hosts that are linked to thousands of domain names.  There are other bad things a registrar could do, such as putting the clientHold status on the ISP domain name, but that can be easily reversed.  Bad deletes and updates can be protected 
via a registry lock service, but otherwise the registry needs to reduce the blast radius based on the data it has available.


I don't agree with this characterization.

It's not the protocol's task to limit the kind of operations that can be done, 
including ones with large impact. The protocol's job is to ensure that requests 
are authenticated, and if they are, that they are executed consistently.

Of course, one might introduce measures protecting against the execution of 
unintended operations -- but that shouldn't be done at the cost of consistency. 
In fact, that gets us in the situation we're in now.

The right place for such measures is before sending a request (e.g., in the 
registrar's system), or before executing the request (e.g., by requiring 
out-of-band confirmation).

Note that the size of the transaction is rather secondary to its impact: in 
your large ISP domain example, deleting it may cause a large cascading 
transaction, but much smaller transactions may have comparable impact. (For 
example, if a (malicious?) registrant change occurs for isp.example and the new 
registrant sets new NS records for the delegation, the same number of domains 
is impacted.)


  * when the domain is purged, purge all subordinate hosts, including all their 
nameserver associations, and remove those records from the DNS. At this point 
there are no NS records with target at or below the deleted domain - no lame 
delegations.

JG – This moves the large OLTP transaction problem to the backend with the 
purge.


Yes. That's good!

Peter

--
https://desec.io/

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

[Gould, James]

Peter,

This moves beyond the protocol itself and into operational concerns of chosen 
policies.  Based on the language in the EPP RFCs, the registry can choose 
various policies on which hosts require glue (e.g., all internal hosts, only 
in-bailiwick hosts), what pre-conditions need to be met to delete a host (e.g., 
no linked domains, only linked domains from same sponsoring registrar, 
independent of linked domains), what pre-conditions need to be met to delete a 
domain (e.g., no linked child hosts,  only linked child hosts to domains from 
same sponsoring registrar, independent of linked child hosts), and how to 
implement the deletion to meet the data integrity and performance requirements 
of the system (e.g., don't allow lame delegations by implementing a cascade 
delete upfront, allow lame delegations and perform cascade delete later).  The 
protocol doesn't dictate the policy in this case but does include guidance in 
the form of normative SHOULDs with an eye on maximizing data integrity.  EPP is 
for provisioning and not bulk transactions, which is why the size of the OLTP 
transaction is material when it comes to operations.  My preference is to have 
small transactions that don't have undefined sizes due to having no maximum 
number of child hosts and no maximum number of domains linked to the child 
hosts.  

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  




On 7/26/23, 1:26 PM, "Peter Thomassen" mailto:pe...@desec.io>> wrote:


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. 


James,


On 7/26/23 06:22, Gould, James wrote:
> * allow deletion of domains with linked subordinate hosts – there is no need 
> to prevent this if the registrar can simply rename the subordinate hosts and 
> free themselves of this restriction
> 
> JG - [...] I would not leave the lame delegations, so that means a cascade 
> delete from the parent domain to all child hosts and all name server links to 
> those child hosts. Imagine if registrar accidentally or maliciously deleted a 
> large ISP domain name (e.g., isp.example) with a large set of child hosts 
> that are linked to thousands of domain names. There are other bad things a 
> registrar could do, such as putting the clientHold status on the ISP domain 
> name, but that can be easily reversed. Bad deletes and updates can be 
> protected 
> via a registry lock service, but otherwise the registry needs to reduce the 
> blast radius based on the data it has available.


I don't agree with this characterization.


It's not the protocol's task to limit the kind of operations that can be done, 
including ones with large impact. The protocol's job is to ensure that requests 
are authenticated, and if they are, that they are executed consistently.


Of course, one might introduce measures protecting against the execution of 
unintended operations -- but that shouldn't be done at the cost of consistency. 
In fact, that gets us in the situation we're in now.


The right place for such measures is before sending a request (e.g., in the 
registrar's system), or before executing the request (e.g., by requiring 
out-of-band confirmation).


Note that the size of the transaction is rather secondary to its impact: in 
your large ISP domain example, deleting it may cause a large cascading 
transaction, but much smaller transactions may have comparable impact. (For 
example, if a (malicious?) registrant change occurs for isp.example and the new 
registrant sets new NS records for the delegation, the same number of domains 
is impacted.)


> * when the domain is purged, purge all subordinate hosts, including all their 
> nameserver associations, and remove those records from the DNS. At this point 
> there are no NS records with target at or below the deleted domain - no lame 
> delegations.
> 
> JG – This moves the large OLTP transaction problem to the backend with the 
> purge.


Yes. That's good!


Peter


-- 
https://secure-web.cisco.com/1BNxy1WbO00swY7YlTazQsxg69G_7d9ief2UAmb9I3jaw6_7HMpoZXdeiB_o3jax2EXYl98OepTh0bEnTldOGO6IknSVSwk6vtGwV4_R-YaA6BvzdVhUQbtDUKdSXw5aajtRG8n3LMmmwTPFoCQOdcrEh7qqXKBP91xqurEPD6UEXvEJS8e6Gz8kE1vSbtpqYrM_-YO-S7r1R-4dBkTnSASq70LeeW004ZZs0eFFSVJiQ0m7Ozg_bQvnA3ZVWaw8f1WVxsiCgS0_HILF1aek_zQakDrTGp18csHcG4gYmhGc/https%3A%2F%2Fdesec.io%2F
 




___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

[James Mitchell]

Thanks! Replies with a JM.

On Jul 26, 2023, at 6:22 AM, Gould, James  wrote:


James,

I find your historic EPP server policies to be very interesting.  I provide 
comments embedded with your points below with a “JG – “ prefix.

--

JG




James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 
[verisigninc.com]

From: regext  on behalf of James Mitchell 

Date: Tuesday, July 25, 2023 at 5:39 PM
To: "Hollenbeck, Scott" 
Cc: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] [Ext] [DNSOP] Best Practices for Managing 
Existing Delegations When Deleting a Domain or Host

Feedback my own and not from IANA.

If I recall correctly, the approach I took when building an EPP server several 
years ago was:

  *   allow deletion of domains with linked subordinate hosts – there is no 
need to prevent this if the registrar can simply rename the subordinate hosts 
and free themselves of this restriction

JG - Allowing the deletion of the parent domain with a set of linked child 
hosts can result in an extremely large OLTP transaction and more importantly 
can result in severe DNS delegation issues.  This is even more for the bad case 
of an accidently or maliciously deletion.  There is no way for the registry to 
know whether the deletion is a good case or a bad case, and with both cases the 
size of the OLTP transaction can result in system stability issues.  I would 
not leave the lame delegations, so that means a cascade delete from the parent 
domain to all child hosts and all name server links to those child hosts.  
Imagine if registrar accidentally or maliciously deleted a large ISP domain 
name (e.g., isp.example) with a large set of child hosts that are linked to 
thousands of domain names.  There are other bad things a registrar could do, 
such as putting the clientHold status on the ISP domain name, but that can be 
easily reversed.  Bad deletes and updates can be protected via a registry lock 
service, but otherwise the registry needs to reduce the blast radius based on 
the data it has available.


JM: A counter point, while probably less likely, a registrar could accidentally 
rename those hosts, which would have an equivalent blast radius that also 
results in large transactions. I understand that you’re working at a much 
larger scale - I was working with 2-3 million domains. The problem with a 
rename is that a registrar might not be able to undo it, esp when renaming to 
an external host. However an accidental delete could be reversed while the 
domain is in the pending delete hold down period.

Yes, Registry lock and clientDeleteProhibted are tools that can reduce the 
likelihood of an accident, but we all know that if those tools aren’t used, 
we’re one EPP command away from an accident. I’d wager that a registrar’s 
delete code is probably going to iterate over the subordinate hosts renaming 
them all before issuing the delete, because anybody can create junk subordinate 
hosts for the domain, and you force them to delete or rename those hosts to 
issue the delete domain command.

I was never sure if registry lock applied to subordinate hosts - I assume it 
would cover them to some degree otherwise it would present a gap in protection. 
Regardless, a registry lock concept could be applied to hosts either directly 
or indirectly.



  *   when the domain is removed from DNS (deletion, but also 
client/serverHold) then the delegation and any glue is removed from the DNS – 
queries for the name result in NXDomain. I believe we left lame delegations 
from other domains for simplicity, but these lame nameservers could also have 
been pulled from the DNS.

JG – Leaving the lame nameserver delegations in place would be a referential 
integrity issue in the registry database, assuming that the name server object 
model is being used.

JM - The delete results in the domain entering a hold down period that can be 
undone (eg pendingDelete). There are no referential integrity issues as other 
domains retain their reference to the subordinate hosts, that are by 
association pending delete. The deleted domain is pulled from the DNS 
immediately. My reference to lame delegations was that I recall leaving in the 
DNS the other NS records that target hosts that are pending delete. These 
“lame” delegations would be cleaned up both in the database and DNS when the 
deleted domain and its subordinate hosts are purged.

I also recall preventing the creation of hosts while the parent domain is 
pending delete.



  *   when the domain is purged, purge all subordinate hosts, including all 
their nameserver associations, and remove those records from the DNS. At this 
point there are no NS records with target at or below the deleted domain - no 
lame delegations.

JG – This moves the large OLTP transaction