On Thu, Jul 9, 2020 at 3:49 PM Mark Andrews <ma...@isc.org> wrote: > > > > 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.
<pedantic mode on> Having just (re-)read RFC 2136, I'll observe the following about what it says about MNAME: - It clarifies the intended purpose/value - Section 4.3 allows a requestor to direct the query to the MNAME as an optimization ONLY. It also acknowledges that this may fail for any number of reasons. This implies that the requestor should be prepared to handle those failures. - Nothing else specifically involves the value of the MNAME. The server needs to know if it is the primary master or not. And if it is not, the forwarding is done to upstream AXFR/IXFR server(s), which is metadata not necessarily contained in the SOA or NS RRSETs. - Thus, there is a distinction between "implied" and "inferred", and nothing technically would be "wrong" about using a value for an MNAME that doesn't resolve or is unreachable after resolution. <end pedantic mode> I think the question of whether to use some value of MNAME that signals non-support of UPDATE isn't precluded by 2136 per se. Clearly any server for the zone will know if UPDATE is supported or not, and respond appropriately regardless of MNAME value. There may be choices of MNAME that have varying levels of antisocial appearance: - "." (Joe's very reasonable suggestion) - "localhost." (not suggesting actually using that, just an example of something clearly evil and antisocial) - "something.empty.as112.arpa" (my suggestion for something designed to always return NXDOMAIN per RFC 7535). > 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. > Humbly disagree, that particular SRV is clearly part of a set of SRVs designed for the "back to my mac" protocol suite. Using that outside of that environment is IMNSHO much worse than implementing signalling in MNAME. It is extremely unlikely that anyone will have such SRV records, or the knowledge need to implement them, or the patience to apply those ubiquitously. UPDATE is a first-class "thing" in DNS. SRV is not, and should not be part of the signaling of DNS, IMHO. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
