Ok, let me phrase my statement differently then. IF people do not want DS in the parent zone of a zone cut, then the registry should not publish the DS they have for domain names they do not have NS.
My only point was to not use this as an argument to make the epp transactions even more complicated and "stateful". Patrik On 28 feb 2013, at 02:27, Edward Lewis <[email protected]> wrote: > I don't know if there's a smoking gun "MUST NOT" but we did discuss a NS-less > DS. Unreliably I'd say it would be a protocol-level error to have. > > But I did find this, which in as much as an RFC is ever a spec, infers that > NS-less DS's aren't to be seen. From RFC 4035: > 3.1.4.1. Responding to Queries for DS RRs > > The DS resource record type is unusual in that it appears only on the > parent zone's side of a zone cut. > > On Feb 28, 2013, at 0:59, Patrik Fältström wrote: > >> >> On 27 feb 2013, at 14:18, Alexander Mayrhofer <[email protected]> >> wrote: >> >>> We've been discussing internally whether or not including DS records into a >>> zone without respective NS record(s) makes any sense (assuming that there >>> are no other RRSETs for the respective label in the zone itself - pure >>> "delegation" scenario)... My personal assumption is that it does not, since >>> the DS record can never be used to verify the information in the >>> (unreachable) delegated zone? >> >> It sort of does not make any sense, but I would be nervous if you set a >> policy that force the NS to exist before you publish DS. This because adding >> NS and adding DS are two different epp operations, and you would set a >> constraint on in what order such things could happen. And for example that >> removing NS would not be allowed if not DS is removed first (or DS >> implicitly be removed if NS is removed). That in turn would create race >> conditions in the case NS is changed completely because even for a fraction >> of a section a domain name that is registered might exist in the registry >> without any NS records, but with DS. >> >> So, I this "makes no real sense" be one of acceptable things that domain >> name holders should be allowed to do if they want. And/or the registrar of >> course that have their internal algorithms regarding in what order various >> epp commands are made. >> >> paf >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > There are no answers - just tradeoffs, decisions, and responses. >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
