Paul Hoffman wrote:
> Greetings again. The following is a proposal to help end-users who are told
> "please enter this record in your zone to prove your existence". It
> simplifies the process without automating it; in short, it makes
> copy-and-pasting more likely to work, particularly for the _label names that
> are being used more. (DomainConnect is working on automation, but with a
> different target audience.)
>
> If this interests you, please read the short draft, particularly the use case
> and design descriptions in the introduction. Those sections describe why the
> format is purposely limited for this narrow use case.
Hi, Paul:
1) This format does not specify what zone to apply the change to. E.g.,
taking the example:
["DUJ", [["add", "mail.yourname.example", "TXT",
"v=spf1 a:mail.yourname.example ip4:192.0.2.49"]]]
Should this update be applied to the mail.yourname.example zone, the
yourname.example zone, the example zone, or the root zone?
If the goal is to reduce errors by making it easier for a user to
specify an operation to a DNS operator's interface, including the zone
name would make sure the correct zone is being operated on, or allow
reducing the number of interactions (for instance, not needing to
manually select a zone to operate on first).
2) Regarding:
The DNS operator SHOULD be able to handle [RFC3597] RRtypes.
However, they may have a local policy to not allow users to add or
delete unknown RRtypes.
A DNS operator MAY reject any DUJ string for any reason. If the
DUJ was received from a user interface, the DNS operator SHOULD
clearly describe why a DUJ was rejected.
The RFC 3597 generic syntax is not limited to unknown RRtypes. It can
also be used to represent RRtypes known to the implementation. Whether
to support the 3597 syntax or not should probably be orthogonal to
whether the operator supports the RRtype or not for updating via a DUJ
string (indeed, the next sentence allows rejecting a DUJ object for
any reason).
If the use case is to support ease copy-and-paste operations, though,
why not *only* use the RFC 3597 generic syntax? That would simplify
parsing and generation of DUJ strings. Presumably an operator accepting
a DUJ string could render the record data encoded in the DUJ string and
present UI to the user to confirm the operation. Actually, this would
be a good idea even if the DUJ string contained display format encoded
record data.
So my suggestion would be to mandate the RFC 3597 syntax as the only
allowable syntax for encoding record data, unless there is also an
unstated requirement that the record data be visually decipherable on
its own to end-users without the aid of external tools (in which case,
*allowing* RFC 3597 format as an option would seem to cut against such
a requirement).
3) Regarding:
Some RRtypes require multiple character-strings, where
"character-string" is defined in Section 5.1 of [RFC1035]. In such a
case, each character-string is a separate JSON string. For example:
["DUJ", [["add", "yourname.example", "WALLET", "ETH",
"0xb775599c76b4672B0D820E3AA534F7cF9312c263"]]]
I guess this should be "<character-string>", which appears in the
section of RFC 1035 about the encoding of the zone file format used
by nameservers. So does a DUJ encode the display format of record data,
or does it encode a zone file fragment that embeds the display format of
record data?
Not all record types are encoded as one or more <character-string>'s,
for instance the SOA RDATA encodes two <domain-name>'s followed by five
32-bit integers. Should that be represented like this?
["DUJ", [["add", "yourname.example", "SOA",
"ns1.yourname.example", "hostmaster.yourname.example", "2024112101",
"7200", "3600", "604800", "60"]]]
Or like this?
["DUJ", [["add", "yourname.example", "SOA",
"ns1.yourname.example hostmaster.yourname.example 2024112101 7200 3600
604800 60"]]]
What about this?
["DUJ", [["add", "yourname.example", "SOA",
"(\n yourname.example. ; MNAME\n hostmaster.yourname.example. ; RNAME\n
2024112101 ; SERIAL\n 2H ; REFRESH\n 1H ; RETRY\n 1W ; EXPIRE\n 1M ; MINIMUM\n)"
]]]
SOA's are probably unlikely to be encoded using DUJ strings, but what
about e.g. MX records? Should those be represented like this?
["DUJ", [["add", "yourname.example", "MX", "10 mx1.provider.example"]]]
Or like this?
["DUJ", [["add", "yourname.example", "MX", "10", "mx1.provider.example"]]]
--
Robert Edmonds
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
