Jeremy Saklad

As a starting point for design, think of tasks as depending on subtasks. From there, you only need to add the ability for a task to be “under” multiple tasks...

If anyone ever actually took advantage of this, of course, something must have gone horribly wrong. But then, I'd say that's true for anything that involves IP address certificates.

By the way, the [Client behavior](https://github.com/MikeBishop/dns-alt-svc/blob/main/draft-ietf-dnsop-svcb-https.md#client-behavior-client-behavior) and [DNS Server Behavior](https://github.com/MikeBishop/dns-alt-svc/blob/main/draft-ietf-dnsop-svcb-https.md#dns-server-behavior-server-behavior) sections should at least acknowledge the special handling of AliasMode "." records. As written, they technically say that you should...

> This draft is already past IESG and in the RFC editors queue. Any changes at this point (especially > any with technical/normative impact) would need to be in subsequent...

> It also nicely matches RFC 7505, "null MX". I was specifically thinking of RFC 7505 when I opened this issue, yes. SVCB-optional records have the same fallback to A/AAAA,...

> Is the suggestion that a "." alias should prevent connection for "http://"-scheme requests? Doesn't it already do that in the current draft? "If an HTTPS RR query for this...

> So in the very least for HTTPS, it seems changing the MAY to SHOULD/MUST is unnecessary and potentially detrimental, so it would certainly not be ideal to make that...

Speaking of doomed connection attempts, there is another scenario that calls for null AliasMode records: hosts that act only as a target for other hosts. ``` example.com. 7200 IN HTTPS...

What you just wrote seems like a decent start. I'd also add that RFC 7505 uses SHOULD, and even this standard says the client SHOULD abandon the connection if SVCB...

> One comes with specific potential for downgrade attacks I initially thought so too, but no: that part applies to all kinds of SVCB record, not just those with SvcParams...