Hello authors,
Please find below my review of your draft.
It mixes spellings/phrasing fixes and more formal questions/problems.
* The title itself does not look like to me specific enough to the goal.
Even more so as you finish the abstract with:
"This same protocol can be used by Registrants"
So it is not a "Third Party DNS Operator to ..." but something like a
"Non-Registrar to ..."
In short I am not good at this but I believe a better name can be found.
Also further down you say:
" For the purposes of this draft, a third-party DNS Operator is any DNS
Operator responsible for a zone, where the operator is neither the
Registrant nor the Registrar of record for the delegation."
So at the end of the day it is not 100% clear if the intent is to be
also used by registrants or not. I believe the whole document should
be more clear on that and state only one case through the whole of it.
* Abstract
I think it would be best to at least have a sentence explaining the goal
before beginning to describe the current situation and its shortcomings.
So that people reading it know where you are going to right at the beginning.
* "The current system does not work well, as there are many types of
failures that have been reported at all levels in the registration
model."
It would be useful to be able to provide such examples or even some references,
if they exist. Or at least types of failures, the kind of consequences they
create
and so what the protocol in the document could have solved.
There is a sentence just after it about that but it gives one vague example
where
the sentence above has "many types of failures".
* I am not convinced in the use of REST/REST-framework/REST-nomenclature
for the exposed use case.
The fact that all your exchanges (except one) do not need any content in the
body
(both in request and in reply) - but need multiple explanations in the protocol,
and the fact that your two resources are not really resources handled at the
server on which the client has any say show that your protocol is just a
signaling
one (the client signals the server that it has something to do, that happens
completely
outside of the REST setup) not something really letting clients act on resources
stored on the server.
In fact, about HTTP verbs to use, I would be more inclined to use PUT to
initiate
the trust (it is an action of creating something) and PATCH for later updates.
However note that using POST/PUT/PATCH has consequences on property like
idempotence
and security of write operations, whereas a simple GET would work on your case,
since it is a at its core a signaling protocol.
This GET would also even work for token retrieval and would even be the more
logical
case.
So is the REST setup really providing you any benefit here?
* 2.1 You say CDS and CDNSKEY are like interchangable in the context of the
protocol,
so I would recommend to change the path of all endpoints in order to not have
cds at the end, nor cdnskey but something more generic that would not be
ambiguous.
Maybe /dnssec simply ?
In the same train of thought you write later
"the child DNS Operator needs to upload the DS record(s) to the parent."
... but some registries only work (accept from their childs) with DNSKEY data
where
they generate the DS records themselves.
I recommend you rephrase there and everywhere below in the same context to have
a more generic sentence that would apply to both DS-based and DNSKEY-based
registries
without having the need to repeat both cases each time.
* 3.1 Identifying The Registration Entity
About the automated discovery of the base URL of the API, did you think
about using SRV records at the parent? And/or URI or NAPTR?
Would also well-known URIs (RFC5785) have something to offer here?
* 3.2 "Registration Entities MAY regularly scan the child name servers of
unsecured delegations for CDS records in order to bootstrap DNSSEC,
and are advised to do so."
I have mixed feelings about the "are advised to do so." part for various
reasons.
While I can understand your intent, it seems to come out of the blue here,
even more so as this point is not the core of the document and even further than
that since you stipulate that if they were doing as advised the whole protocol
described in the document would not be needed, except one point.
If you really want to discuss that practice I believe you would need more data
or recommendations like on timings (minimum/maximum periods, hardcoded at
registry
or depending on zone TTL, etc.)
Also, multiple registries do DNS checks after each change and go forward only
if everything returns OK (from their very specific local list of tests).
There may be a merit to discuss what happens when the child does some
CDS/CDNSKEY
changes that get automatically picked up by registry (for the one doing it
like you advise) but then the DNS checks fails for whatever reason (example
among many other possible cases: the child publishes a new CDS without
publishing
the corresponding DNSKEY in its zone), so no changes happen.
How the third party/registrant get notified of that (besides not seeing its
wanted change appearing on the registry level)?
* 3.3 same problem, you are adding something (the registry having to regularly
scan the child zone for CDS records) that is not really part of this protocol
* 3.4
I was thinking about the signatures lifetime of the records, maybe that should
be checked by the parent, so that they do not expire "too soon" ?
* 3.5 You suddenly use "Registration Entities" in plural for no reason as it was
singular before. Maybe it should be consistently singular in the whole document.
I find the test to be a little harsh: if I read it correctly if even one query
timeouts among all of them done each 2 hours during a week (so 84*2 per
nameserver
to check both TCP/UDP) everything is reset back to its beginning. But network
outages can happen and not necessarily under control of the DNS provider, and
also
the DNS service is available globally through the constellation of nameservers,
not necessarily for one of them all the time.
* 4 "It is up to the child to monitor the parent
for completion of the operation"
While probably obvious to anyone I think it would not be bad to be even more
explicit to re-iterate that this part is outside of the protocol you design
here, as it is based only on DNS queries.
Also: "This protocol is partially synchronous" I do not think this is a valid
term here.
You could maybe say that the server can decide to handle the requests either
synchronously or asynchronously: in the first case it keeps the connection open
during the time it processes the request, and in the second case it replies
immediately
telling the process is ongoing.
In fact I doubt how it could be synchronously: when setting the trust
relationship
you imagine delays of a week for a registry to do its test, delay which is
course
incompatible with maintaining an HTTP connection open; but even in the other
cases
the registry may not be fully automated in real time for all its DNS publication
so even if all the tests are successful the showing of the new DNS/DNSKEY
records
in registry zonefile may happen minutes or hours later, which again will prove
difficult for synchronous operations, but even more than that probably
unnecessary,
as a simple signaling protocol, it can be purely asynchronous.
In short what does having the two cases offer to the protocol?
* 4.1 "or VPN"
I am against these two words. I see no need for them and in the contrary their
presence
gives false promises by putting two things on the same level where they are
not: even if using a VPN, the access would still need to use TLS. So it is
clearly not an "or".
Also there is some logical problems in your suite of explanations: you say the
protocol
does not need any unique authentication, and that TLS would be enough for that.
Then you say people can use TLS _or_ VPN: so if using VPN what about the needed
features
of authentication? You do not say.
In short, remove "or VPN" and all problems are solved.
* 4.2.1.1.1
I believe a PUT would be more REST-like in this case
(kind of "creating" DS data at the registry for the object being the domain)
than a generic POST (see my discussion previously)
(side note purely aesthetic: it is "strange" to have a so deep
nomenclature with 5 levels for a document not so long, especially since other
"top" section are only one or two sentences long, so it is unbalanced)
* 4.2.1.1.2
Right now 401 cover registry lock based on your earlier explanation.
However a domain can also be in multiple other states that would deny changes
on it,
either temporarily or definitively, among others: other pending update operation
(EPP status pendingUpdate), client has locked the domain
(clientUpdateProhibited),
domain is in some kind of blocked state due to a procedure on it (could be EPP
status
serverUpdateProhibited but contrary to the registry lock case this would be a
case
where the client can not change anything)
It can also cover all cases if the registry adds authentication features like
you describe in 4.1
So I believe you should put the definition of 401 in only one case, like
alongside
other status codes, but then it is kind of a shortcoming that a single code
covers so many cases.
Even more so as the reply has no body, so the server has no chance to provide
more details to the client on what has failed, what the client could change,
etc.
So something maybe to think about?
Maybe 451 error code should apply to some of these cases?
(of course this applies in the same way to further descriptions of 401 below)
* 4.2.1.2
Is there a specific reason to separate the case of removing all DS records
from the case of generic DS records update detailed after?
* 4.2.1.3.1
Nitpick: you use this form "CDS/CDNSKEY" and "CDS/CDSKEY RRset" here, while
previously
you said "CDS or CDNSKEY record in the child zone" where all of these points to
the exact same concept so can you choose one case and apply it consistently in
all
the document. Also in the introduction you said you are using CDS but CDNSKEY
could
be swapped, so if that is true, why repeating the duality CDS/CDNSKEY later in
the document?
* 4.2.2.1.1
"_delegate.@ domain name"
This can not be a domain name as those, like hostnames, can not have _ in their
labels.
It is "just" a resource record.
Also for:
"Note that the _delegate TXT record is publicly available and not a
secret token."
Maybe rephrase that as I understand your intent would be to say that no secret
value should be used as token for the _delegate TXT record since it is
publicly available.
* on status codes, is there really a difference between 409 and 412?
You use 409 for establishing the trust, and 412 for removing/updating it, in
all 3 cases when there is an invalid situation (already DS when starting the
trust, no DS to remove when asked, etc.)
Wouldn't it be more logical to use 409 or 412 in all 3 cases?
* 4.2.2.1.2
" A token is included in
the body of the response, as a valid TXT record"
This does look underspecified to me.
Does that mean that in the body we find the token formatted as a DNS TXT record?
In zonefile format or wire format?
Or is just the token transmitted, in HTML? JSON? pure text?
In the later case, with or without pre and post padding?
Also, you specify previously that the token may expire.
Wouldn't be nice if in this reply also the expiration would be transmittend
back to client?
Either as part of the body response (but then you even more need to define it
precisely)
or an the HTTP level like with Cache headers?
For this specific operation, why no 401 case, nor 409/412, nor 429?
They should apply also here I believe.
* 4.3. Customized Error Messages
This is clearly underspecified. How it is formatted in the body of the response?
Especially since you later say that it is a protocol for machine to machine
communications, so these communications must be framed inside
specific structures.
* 5. Security considerations
You speak about drawbacks without explaining what they would be.
* 7.
" This protocol is designed for machine to machine communications.
Clients and servers SHOULD use punycode [RFC3492] when operating on
internationalized domain names."
Why do you reference IDNA2003 instead of IDNA2008?
Others open point I have not seen and maybe useful to think about:
* I believe there should be some kind of recommendation (a SHOULD?) that
the registry should notify the registrar of such changes to the domain it may
have been instructed to do by third parties, like with service messages in EPP.
For at least 2 reasons: internally for the registrar to have locally a relevant
state of the domain it manages in its own database, and specially because it
could have been an error by the third party/registrant, and also externally
because registrars may publish data about domain names they publish (like
whois, rdap, escrow exports, etc...) and this often includes DNSSEC data,
even if sometimes only a flag enabled/disabled but this still means the
registrar
needs to be notified of changes it did not start itself.
* You advise more than once that the registry should monitor its child zones
for their CDS records regularly.
What happens if it detects a NS change? Because this may cover two complete
differente cases: one where the current DNS hoster just does technical changes
and completely manage correctly the DNSSEC setup on both the old and new server,
or the second being a change of DNS operator, and the new one not being DNSSEC
aware,
hence maybe dropping at once all DS/DNSKEY/RRSIG/CDS/CDNSKEY records.
What should the registry do? In general, and if it receives a ping through
your protocol to update things (a cronjob could have been left running at the
old
provider for example)
* Similar cases if there is a transfer of the domain name... should the trust
relationship be reset to its beginnings since in some of these cases this also
has the consequence of changing the DNS provider.
You in fact barely touch on client authentication in your protocol
and saying to me it is outside of the scope seems a little too quick.
What happens when the DNS provider changes? How can old accesses be revoked?
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
