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

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2020 05:42:31 +1000

We should use “HTTPS 0 .” to signal that there is no service offered. Similarly for SVCB. 

Currently “.” has no useful purpose in the alias form.

-- 
Mark Andrews

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Jul 2020 17:18:00 -0400

This seems like a reasonable idea to me.  We should be able to incorporate
this for the next draft revision.

On Thu, Jul 9, 2020 at 3:42 PM Mark Andrews <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Joe Abley <[email-masked]>
Date: Thu, 9 Jul 2020 18:17:43 -0400

On Jul 9, 2020, at 17:18, Ben Schwartz <bemasc=[email-masked]>
wrote:

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.

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.

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

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 09 Jul 2020 15:48:18 -0700

+1

When implementing the client, this case needs to be caught anyhow (the error of aliasing to your own domain), so it has the effect of indicating that no service is valid. This suggestion turns this case from an error (which still had the desired effect), to a proper signal.

Tommy

> On Jul 9, 2020, at 2:18 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> This seems like a reasonable idea to me.  We should be able to incorporate this for the next draft revision.
> 
> On Thu, Jul 9, 2020 at 3:42 PM Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2020 08:48:44 +1000

> On 10 Jul 2020, at 08:17, Joe Abley <[email-masked]> wrote:
> 
> On Jul 9, 2020, at 17:18, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 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?
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Thu, 9 Jul 2020 21:53:13 -0400

On 9 Jul 2020, at 18:48, Mark Andrews <[email-masked]> wrote:

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

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

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

> 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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 9 Jul 2020 19:08:22 -0700

On Thu, Jul 9, 2020 at 3:49 PM Mark Andrews <[email-masked]> 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.
>
>
> 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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2020 13:02:49 +1000

> On 10 Jul 2020, at 11:53, Joe Abley <[email-masked]> wrote:
> 

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.

> 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 DN…

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.

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

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

---

From: Brian Dickson <[email-masked]>
Date: Fri, 10 Jul 2020 09:41:10 -0700

(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 <[email-masked]> wrote:

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

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

---

From: Joe Abley <[email-masked]>
Date: Fri, 10 Jul 2020 12:54:39 -0400

On 9 Jul 2020, at 23:02, Mark Andrews <[email-masked]> wrote:

> So you discard everyone that has to diagnose DNS issues.

Nope. I'm saying that in many cases there is no useful information to put in the MNAME field, so even if it was common practice to diagnose DNS problems with reference to the contents of that field (which I think is not true) the contents of the field have no particular relevance.

If I generate a zone that is distributed by means other than zone transfer, there is no common meaning of "primary master".

If I publish a zone from a private, non-world-reachable single master but then distribute it through a graph of distribution masters, why is the name of that private origin master useful to anybody trying to diagnose a problem?

>  You discard anyones self configuring provisioning system.  The field is in use for purposes other than DNS UPDATE.

Just because you say it doesn't make it universally true, Mark. You're going to have to show your working if you want to make a point.

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

And so your argument is that there are no other UPDATE clients that use the MNAME? Or are you agreeing with me?

Joe

---

From: Dick Franks <[email-masked]>
Date: Fri, 10 Jul 2020 18:19:45 +0100

On Thu, 9 Jul 2020 at 23:18, Joe Abley <[email-masked]> wrote:

> disgusting idea that would cause junk to be sent to root servers.i
>

The idea is respectable enough.
There is also a precedent to be found in RFC1035 (3.3.7) no less.

--Dick

<https://tools.ietf.org/html/draft-jabley-dnsop-missing-mname-00>
> ___________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Jul 2020 11:21:35 +1000

> On 11 Jul 2020, at 02:41, Brian Dickson <[email-masked]> wrote:
> 
> (Apologies for any weird quoting-style/depth issues, mail user agents aren't terribly consistent.)
> 
> 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.

UPDATE says to send the update requests to the servers listed in the NS RRset.  The SOA MNAME provides a sorting criteria for those names.

> 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?
> This illustrates the importance and value in documenting dependencies/uses in RFCs, even if they are Informational or even ISE.

The use of MNAME to point to the primary server IS documented in STD13.  You don’t have to document every possible use that falls out of that specification.  So no there isn’t any RFC documenting them but there is no expectation that there would be either.  Where is it documented that EVERY use you make of the existing specifications needs to be documented in a RFC.  The same way as there is no documentation on millions of uses that naturally fall out of all the existing RFCs.  Joe is trying to CHANGE the specification of MNAME and I’m pointing out some of the potential uses of the existing specification.

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

Now you are just throwing stupid straw man arguments about.

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

Which kind of defeats the diagnostic use.

> 	• Check if the name resolves and has A/AAAA records
> 	• Use it for the field's purpose only if BOTH things are satisfied.
> I think it would be easy to implement, and would be mostly an optimization (to not send UPDATEs that will be ignored).
> 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

---

From: Joe Abley <[email-masked]>
Date: Sat, 11 Jul 2020 07:18:19 -0400

Hi Mark,

On 10 Jul 2020, at 21:21, Mark Andrews <[email-masked]> wrote:

> Joe is trying to CHANGE the specification of MNAME and I’m pointing out some of the potential uses of the existing specification.

I think what I am actually trying to do is propose a value for the MNAME field in cases where there is otherwise no clear value to use. Whether we call this a change (or a CHANGE :-) or a clarification seems like a weird thing to fixate on.

I would like to understand what the existing use cases are that you mention.

In the case where there is no primary master in the sense used in 2136 or 1035, what are the potential uses of that field, and which of those uses would be defeated by the use of a standard value (e.g. the empty label) to indicate that there is no useful data included there? Common alternatives are to arbitrarily copy RDATA from an apex NS RR, or to make something up that may or may not be an actual host name. Those alternatives seem to have less diagnostic value, to me; a value that means "nothing to see here" is surely a better signal to someone trying to troubleshoot.

I appreciate this sub-thread has nothing much to do with SCVB (and sorry for overloading), but your enthusiastic objection to the idea of codifying the use of the empty label more broadly than just with that RR has intrigued me.

Joe