On 3/6/23 03:35, Shumon Huque wrote:
2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it
only has meaning for "type covered" fields in signature records such as SIG(0) (RFC 2931). There
appears to be no collision with usage in the NSEC type bitmap, and IMHO it appears to be a very natural meta
type fit. ("This is NULL, There Really Is Nothing Underneath.")
If I didn't get the math wrong, it would also save 11 bytes in the type
bitmap (compared to using the lowest available meta type code, 128), slightly
reducing the chance of packet size issues e.g. when double-signing etc.
I'm a bit allergic to re-using an RR type already designated for another
purpose.
I'm fully with you (= also allergic), but that doesn't mean I'm strictly
opposed. I think it's fine to use an already assigned rrtype for another
purpose, if there are good reasons for doing so and there's no risk of
collision/confusion.
It will require more process work (potentially blocking) to revise other
documents too.
I checked before proposing it, and couldn't find anything that would need
revision. RFC 1035 calls that type experimental, no NULL RRs allowed in zone
file, and content opaque (if used on the wire). To me, that actually looks like
a rather ideal set of pre-conditions.
Also, I've been told by a few folks who deal with RR type allocation, that if
we standardize this mechanism, it will have to be a meta-type.
Sure. But I'm not proposing to allocate anything; the NULL type is already allocated.
Also, I think it is "meta enough", as the type is already specified to not show
up as the type of an actual record.
I find the natural semantics of "This is NULL, There Really Is Nothing Underneath."
really appealing, as opposed to "This is 0xFF01, ...".
It's certainly true that using a type in the meta-type range will increase the
size of the type bitmap some. Your calculation sounds right. By comparison, the
ENT private type used by NS1 presently consumes only 3 more octets (window
number 255, 1 byte bitmap).
There's a contradiction of goals here: the meta type values lie entirely in
window block 0. All of those, except the NULL type, are in the second half of
the window.
This all still seems to be in the noise to me, and perhaps not worth worrying
about. To your comment about double signing, I suspect the bigger concern will
be about the computational cost to perform multiple cryptographic operations
rather than a few extra bytes in the signature input.
I agree for now, but we don't know the size constraints of the future, such as
which algorithms one will have to roll to. My take is that barring a technical
reason to spend 11 bytes, we should pick the more compact data structure unless
that would cause confusion or an interop problem.
It's unclear whether the 11 bytes will ever be important, and I don't feel
strongly about it. I find the natural semantic fit much more important.
As you pointed out in a separate message, keeping NXDOMAIN signaling clean and
healthy is an important concern. Just assume for a moment that Compact DoE with
NULL type had been around for years. It would feel very clean and almost
obvious for this signal to live in the first bit of the type map.
This bit is currently unused and happens to have a fitting name already.
For responses to queries without "do" flag, there is no DoE processing. To
preserve the DoE information, the return code fur such responses should IMO continue to
be NXDOMAIN.
This isn't defined clearly in the original draft or in this one, and we should
state explicitly what we want it to be. I believe Cloudflare already does what
you suggest. But NS1 always returns NODATA, regardless of the DO flag.
Hm, at least the latter I find rather unexpected.
If the return code is not allowed to depend on the "do" flag, it may be better to
return NXDOMAIN even to "do" queries, in combination with the Compact Denial NSEC record.
The draft correctly says that it is not authenticated, but retaining it probably wouldn't hurt.
I suspect that unilaterally putting NXDOMAIN into the rcode field will break a
lot of validator code. They are likely to use the rcode to advise them on what
type of proof to look for in the message body, and they won't find a
traditional NXDOMAIN proof. Maybe we can ask resolver implementers on the list
to speak up about what the actual impact would be for them.
I second the idea of asking them!
Peter
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
