> On 10 Jul 2020, at 08:17, Joe Abley <jab...@hopcount.ca> wrote: > > On Jul 9, 2020, at 17:18, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> > wrote: > >> This seems like a reasonable idea to me. We should be able to incorporate >> this for the next draft revision. > > I guess I'll mention that when I suggested MNAME=. to indicate that a zone > did not accept dynamic updates, the proposal was roundly shot down as a > disgusting idea that would cause junk to be sent to root servers.
You attempted to CHANGE the purpose of MNAME from identifing the primary server to signalling that UPDATE is not supported. When you change the purpose of a field you have to consider the existing users of that field. Given that there is a registered SRV prefix for UPDATE (_dns-update._tcp) you already have a signal. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?amp=&skey=-3&page=125 This establishes the signalling from the very beginning they same way as SRV uses “.” to signal no such service. That too was done from the very beginning. > I didn't agree with that reaction at the time. I remember noting established > use of MX 0 . to indicate that a domain did not accept mail, and my suggested > use with NOTIFY didn't seem very different. Changing MX was also after the fact but “MX 0 .” didn’t have another use. > If the tide of opinion has changed on this then perhaps we could document use > of the single empty label for multiple analogous and similar purposes, and > not just for SVCB? > > https://tools.ietf.org/html/draft-jabley-dnsop-missing-mname-00 > > > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
