On Monday, February 3, 2025 10:19:59 PM CET Paul Hoffman wrote:
> I have made many updates to the draft based on the input so far. Please see
> the extended use case and design parts, as well as the other additions
> y'all have suggested.
> --Paul Hoffman
Hello,
I have read your draft revision, and like the sentiment behind it. To introduce
a portable
format like JSON into the DNS, seems like a prudent decision to make. This
would
ultimately increase portability.
As you may or may not have seen in bind-users
(https://lists.isc.org/pipermail/bind-users/
2025-January/109451.html[1]), I have made a JSON interface for both ISC DHCP
and BIND.
The intention behind that implementation was different from yours, yet
strikingly similar.
The idea behind my implementation was that of repeated record entries, and
rebuilding
entire zone files based on JSON inventory. Meanwhile it appears that your
sentiment is
more aligned with commercial providers (e.g. SPF, DKIM, DMARC, Google,
Microsoft, ...)
using DNS to prove domain ownership and policy, and its interface with
registrars.
As such, I will consider your perceived use case primary to my own. I will,
however, express
my gratitude and respect towards you if my email ended up being the catalyst.
That's
more than I could've ever wished for. Thank you.
I've kept tabs on the feedback you've received until now, and was particularly
interested in
the matter of newlines, and other such formatting. Perhaps it would be more
important to
ensure that those remain aligned to the I-JSON specification (RFC 7493?), than
to introduce
our own interpretations to this matter.
That being said, we should certainly not underestimate users' ability to mangle
these
things. A certain law firm I work with, prints e-mailed documents before
scanning them
back in for retransmission in another e-mail. For remote management of my
systems in
crisis situations, I have had significant trouble expressing to people on-call
where to put
dashes and spaces in shell commands. Ultimately, I resorted to only ever having
them
responsible for pressing the power button, and designing my systems around
successful
SSH service regardless of circumstance.
When it comes to what's actually expressed in my JSON databases, I think I may
have
some useful input for you. Especially if this work is indeed in response to my
message on
bind-users, I'd consider it a disservice to not share my own notes with you.
>From https://git.nixmagic.com/infra/config/src/branch/dev/readme.md[2]
>(private):
Network configuration toolkit
This project contains the network configuration files, and tools to create
associated
domain-specific language files.
For now the project only supports classful networking, with development being
done
against infrastructure with multiple /24 networks.
Configuration syntax
The configuration file uses the following syntax:
{ "network": [{
"domain": [ "example.com" ],
"serial": "1",
"prefix": [ "192.168.0" ],
"description": [ "Example network" ],
"hosts": [
{
"name": "example",
"mac": "01:23:45:67:89:ab",
"ip": "1",
"type": "example"
}]
}
--EOF--
The rationale is that this offers inventory, for multiple networks that have
each been
assigned one or more zone names, and one or more network prefixes (whose
amounts
must match). These are one-to-one relationships, so e.g. the first zone matches
against
the first prefix. The serial is analogous to the zone's serial, and matches all
networks /
zones. The idea is that if a change is expressed in the JSON file, it affects
all resulting zone
files and DHCP configs equally. With no exceptions I can think of, this affects
all networks
expressed in that block. Lastly, the description is used to offer a comment in
the zone file,
for an operator that may not be aware of, or willing to integrate with the JSON
scheme.
Organizational inertia is certainly worth considering, and it's why I consider
the voluntary
basis of this proposed standard a good thing.
Perhaps Section 1.2 is worth reconsidering though, JSON is inherently a
machine-readable
format. To which extent its syntax is compatible with DNS, is certainly
something worth
looking into -- particularly for use cases more complex than A and PTR, and
perhaps MX
and TXT records. So far, my own implementation only implements the former two.
But if
machine-to-machine transmission (across different organizations) is to be
excluded, then
perhaps other formats like TOML or YAML may be better contenders to this role.
Regardless, I would like to continue the push into JSON here, with the
long-term
expectation for such machine-to-machine interface to be normalized.
Regarding the remarks on Base64, I completely agree. This is meant to be for
binary
compatibility and (within offensive security context) obfuscation, not
reliability. A mangled
Base64 string is still just as mangled as the thing it encodes.
Regarding Section 2, I would like to propose something akin to the syntax I
alluded to
above. Rather than using an array where elements are to be addressed by element
alone,
using it as key-value pairs may offer both more descriptive and resilient
results. This would
increase both user awareness, and implementation stability. The only cost
trade-off I could
think of, is that it is more verbose.
Other than that, I quite like the proposal and have no further objections.
Thank you for
having spent your time and effort on this, and for having read my e-mail(s) to
this point.
--
Met vriendelijke groet,
Michael De Roover
Mail: i...@nixmagic.com
Web: michael.de.roover.eu.org
--------
[1] https://lists.isc.org/pipermail/bind-users/2025-January/109451.html_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
