Hi Mark,
On Thu, 27 Jun 2024, Mark Andrews wrote:
I broached the possibility of CBOR in discussion on DNSOP before DTN
was CCed, making the above point to Scott Burleigh. Our conclusion
there, along with Mark Andrews, was that the current verbiage is the
current best course of action. I have no personal objection to wire
format for the IPN RRTYPE being CBOR, if ScottB and Mark agree that
there is gain to be had over using 64-bit unsigned int.
That said, it is unclear if appropriate CBOR functions/libraries
already exist/are used inside nameserver implementations. If not, that
could substantially delay deployment, and/or add burden to
implementers. There is an active draft which specifically treats CBOR
encoding of RRs (
https://datatracker.ietf.org/doc/draft-lenders-dns-cbor section 3.2.1),
but that document is still an Individual Draft at this point as well.
Mark, ScottB, opinions?
What real benefit would CBOR bring over a raw 8 byte value other than
saying it was entered via X or X.X?
This would be my criteria exactly. If we can save bytes, ok; lets
consider it. If not, then why?
The CBOR encoding is going to be as
long or longer in most cases on an internet wide scale. It’s also going
to require more complicated validators other than the record length is
8.
So it would add some complexity into the implementations, which is less
than optimal. Personally, I like applying the KISS principle when
possible.
0.0 -> 82 00 00
0 -> 00
3467.8979 -> 82 19 34 67 19 23 13
70000.500 -> 82 1a 00 01 11 70 19 01 f4
I hope I’ve got the hand encoding right.
This is not to say that CBOR couldn’t be used. I’m just not seeing the
benefit.
In space (non-planetary) use cases, where bandwidth is very precious,
connections intermittent, and latency often high, CBOR encoding makes
sense by reducing bytes on the wire over other formats, and is generally a
BP standard, used in encoding bundles themselves. That said, it is
generally accepted that normal DNS operation in these networks is not
possible, due to the high RTT and connections being temporary in nature.
Consider that solar system scale transit may take long enough that the
response is stale before it arrives.
I totally see CBOR in that use case. In terrestrial (non-planetary) use
cases, not so much, but I am willing to listen to a reasonable argument on
benefit that can be gained which justifies the extra work and complexity.
We already do stuff like this so CBOR complexity itself isn’t a issue.
I had no doubt, but I am the last person who wants to make something
unnecessarily more work than it needs to be, particularly when it is not
me doing the work!
Sincerely,
ScottJ
static isc_result_t
check_private(isc_buffer_t *source, dns_secalg_t alg) {
isc_region_t sr;
if (alg == DNS_KEYALG_PRIVATEDNS) {
dns_fixedname_t fixed;
RETERR(dns_name_fromwire(dns_fixedname_initname(&fixed), source,
DNS_DECOMPRESS_DEFAULT, NULL));
/*
* There should be a public key or signature after the key name.
*/
isc_buffer_activeregion(source, &sr);
if (sr.length == 0) {
return (ISC_R_UNEXPECTEDEND);
}
} else if (alg == DNS_KEYALG_PRIVATEOID) {
/*
* Check that we can extract the OID from the start of the
* key data.
*/
const unsigned char *in = NULL;
ASN1_OBJECT *obj = NULL;
isc_buffer_activeregion(source, &sr);
in = sr.base;
obj = d2i_ASN1_OBJECT(NULL, &in, sr.length);
if (obj == NULL) {
ERR_clear_error();
RETERR(DNS_R_FORMERR);
}
ASN1_OBJECT_free(obj);
/* There should be a public key or signature after the OID. */
if (in >= sr.base + sr.length) {
return (ISC_R_UNEXPECTEDEND);
}
}
return (ISC_R_SUCCESS);
}
As an a side, could you describe the needs of your application, I didn't quite
understand your HTTP request analogy, as that is a early-bind usage, and BP is
built on the concept of late-binding.
Again, sorry, but per the Note Well, the information I placed in the "Purpose"
section of the draft, per your request, is all I am at liberty and willing to disclose at
this time.
Thanks,
ScottJ
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
