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

[Brian Dickson <[e-mail]>]

(Apologies for any weird quoting-style/depth issues, mail user agents
aren't terribly consistent.)

On Thu, Jul 9, 2020 at 8:03 PM Mark Andrews <[e-mail]> wrote:

>
>
> > On 10 Jul 2020, at 11:53, Joe Abley <[e-mail]> wrote:
> >
> > On 9 Jul 2020, at 18:48, Mark Andrews <[e-mail]> wrote:
> >
>
> > 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.
>

That's an IF conditional which is only applicable if the IF condition is
matched. It says nothing about what to do if the SOA MNAME doesn't match an
NS name.

I'm also confused about the objection. Are you saying you want to allow
UPDATEs, or that you want a mechanism that programmatically blocks UPDATEs
without changing your use of MNAME?
See below (next block of text from me) if it is the latter case.


>
> >> 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.
>
>
This illustrates the importance and value in documenting dependencies/uses
in RFCs, even if they are Informational or even ISE.
The uses you are referring to aren't in any RFCs, are they?
I could overload the TTL field of a DNS record to be a DSCP thing, but if I
didn't tell anyone about it, I shouldn't be surprised if future changes to
standards broke it.

However, this doesn't mean this use case isn't valid.
The fundamental question is whether there are ways to support that use (XFR
topology discovery) while also supporting Joe's concept(s) for making
useless UPDATE things stop.
 (And more generally have ways to signal anything that might be a host name
from being used for something when that something isn't supported by
policy.)

Rather than the NAME of the thing (FQDN, e.g. MNAME field or MX target),
what about using the VALUE or STATUS (e.g. presence/absence of A/AAAA
RRSETs, or NXDOMAIN results)?

The corner case for XFR topology could be accomplished with DNS "views" for
the FQDN in the MNAME field (only permitted XFR clients would get the
"real" value).

The logic path for clients would be relatively simple:

   - Check if the name resolves and has A/AAAA records
   - Use it for the field's purpose only if BOTH things are satisfied.

That seems like a simple and pragmatic compromise.
I think it would be easy to implement, and would be mostly an optimization
(to not send UPDATEs that will be ignored).
Interoperability would be dead easy to confirm.


> > 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.
>

I agree with this concept.
See above for an idea on how to implement this that doesn't rely on the
FQDN being the empty string per se, but which would be satisfied IF the
FQDN were the empty string (or something under empty.as112.arpa, for
example.)

Brian