Re: [DNSOP] HTTPS SVCB no service available signal.

[Mark Andrews <[e-mail]>]

> On 10 Jul 2020, at 11:53, Joe Abley <[e-mail]> wrote:
> 
> On 9 Jul 2020, at 18:48, Mark Andrews <[e-mail]> wrote:
> 
>> On 10 Jul 2020, at 08:17, Joe Abley <[e-mail]> wrote:
>> 
>>> On Jul 9, 2020, at 17:18, Ben Schwartz <bemasc=[e-mail]> 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.
> 
> By that logic, DNS UPDATE changed the original purpose of MNAME to be the target for a DNS UPDATE.

No. DNS UPDATE says any listed nameserver is a target for DNS UPDATE.  If the SOA MNAME matches a NS name then you try that nameserver FIRST.

>> When you change the purpose of a field you have to consider the existing users of that field.
> 
> The only purpose of MNAME today that I am aware of is to identify the target for a DNS UPDATE. If you know of another way that the field is interpreted I'd be interested to hear it. Even without DNS UPDATE being a primary concern, there are many zones whose provisioning means that "primary master" has no real meaning; there's no reachable server that is more master or more primary than any other; the concept of a single, primary master server or service is a legacy that no longer applies to many high-use zones.

So you discard everyone that has to diagnose DNS issues.  You discard anyones self configuring provisioning system.  The field is in use for purposes other than DNS UPDATE.

>> Given that there is a registered SRV prefix for UPDATE (_dns-update._tcp) you already have a signal.
> 
> That is certainly an option for clients that use SRV lookups to identify targets for a DNS UPDATE. I'm not aware of any, but I believe your inference that they exist. I think it's fair to say that there are other clients that don't support that mechanism, though. It wasn't mentioned in RFC 2136.

You local MacOS machine will lookup _dns-update._tcp SRV as do some CPE routers.

>>> 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.
> 
> Sure it did; it had the meaning that the highest-priority host for delivering mail to is the empty string, which would have the effect of denying mail delivery since that empty string could not be used as a host name to derive an address. That's shockingly close to the intent of "MNAME = ." And by shockingly close I really mean it's the same.
> 
> I still think it'd be a service at this point to codify the use of an empty string in a field that is intended for use as a hostname to indicate that no host is available to do whatever the client was hoping to do. The only identified harm from such a definition, even after the fact, is the potential for a few client libraries that are unfamiliar with the concept of a hostname sending a few queries that will quickly be cached at multiple levels.
> 
> Making this assertion for all RDATA fields that might contain hostnames seems more beneficial than poking about in particular RRSet definitions, since it opens the door for efficient suppression of traffic in client libraries.
> 
> Having clients inadvertently send DNS UPDATEs to servers that are not prepared to accept the is at least an inefficiency; at worst it's a systematic leak of local topology information.

> Joe

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]