On 4/3/19 11:47 pm, Rubens Kuhl wrote: > >> On 26 Feb 2019, at 14:46, Tony Finch <d...@dotat.at> wrote: >> >> Rubens Kuhl <rube...@nic.br> wrote: >>> I imagine that DNS as a communication channel to assure registrant >>> willingness to change something, similar to CDNS/CDNSKEY, could be quite >>> useful. For instance, if the name servers that are delegated on the >>> registry are now pointing to new name servers, and this response is >>> signed by the current DS/DNSKEY on the delegation, changing the DNS >>> servers for that domain is pretty safe. >> There is RFC 7477 CSYNC, but I don't know of any implementations. > > It's possibly something in that direction, but CSYNC sounds a bit more > complicated by requiring support of a new RR-type on the user-side. Using the > same existing RRs would make it easier for end-user adoption. > > I believe an OOB mechanism signalling the user intent of changing name server > or in-bailwick glue records, with registry then fetching those records, would > have more traction. The nature of that OOB would be policy-realm dependent; > for some TLDs it could be as easy as flushing recursive DNS cache > (https://developers.google.com/speed/public-dns/cache , > https://www.verisign.com/en_US/security-services/public-dns/dns-cache/index.xhtml > , https://cachecheck.opendns.com/), for some it might require a > domain:update transaction from registrar. > > In all cases, any name server change not coming from a synchronous EPP > transaction should trigger a poll message informing the name servers have > been changed and to which ones. This is likely something to regext to work > on, possibly augmenting the existing draft-ietf-regext-change-poll- or using > it as it is.
I had previously read 7477 as being a useful tool for registrars, since the 'parent agent' (section1.1) description seemed to fit them. That would allow error handling to remain unchanged between EPP server and client and no need to deploy registry logic to the csync ingestion tool. The implications of adding or removing registry objects based only on DNS signalling might be quite challenging to overcome in common manner. The out of band error signalling imagined in RFC7477 would get much more complex if CSYNC were deployed at the registry, but registrars maintained the relationship with registrants. > > Security-wise, considering the limited adoption of DNSSEC, for non-signed > delegation one alternative would be using only TCP queries to verify the new > records. This is far from perfect, but counters some threat vectors. > I know I'm probably being snobbish or dismissive, but I can't think of a reasonable case where a domain name is import enough to a registrant to server lock, but not important enough to deploy DNSSEC. > > Rubens > > based on the users of the various server lock products I know, delegation changes are rare enough and planned ahead enough to not require bypassing the EPP update prohibitions without an explicit unlock/re-lock sequence. DNSSEC keyrolls on the other hand seem like an activity that should be able to continue and not require removal of server lock states. So my ideal server lock product would be: - supports CDS/CDNSKEY while locked - server states applied OOB between RR and Ry - server state change requests are standardised between Rt and RR, but are not reliant on established Rt - RR systems, otherwise server lock is no different to client lock in terms of risk. > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext -- Kal Feher Melbourne, Australia
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
