Paul Wouters p...@cypherpunks.ca writes:
Comments:
Sorry for the late response; working no too many drafts at once.
2.1.1.1 talks about the serial in the CSYNC record. Why did you prefer a
soft link between that and the SOA serial, instead of a hard link?
Or why is there is a need for a serial? Shouldn't it directly relate to
the SOA serial? You seem to think one would need a minimal SOA serial
to process the CSYNC record, but wouldn't the CSYNC record always be
correctin the _current_ zonefile? I don't see how prepublishing a CSYNC
with a current serial + 1 would be of any benefit.
Because I was envisioning tools that manage the CSYNC record
independently of the zone itself being managed. EG, for zones that
update their SOA regularly (say hourly) for data additions and removal,
they don't need to be concerned with always making sure the CSYNC SOA is
updated too. They can if they want, but using a clause means the
site-specific data management tools don't need to be rewritten. Only
the CSYNC tool and/or signing tools need to deal with that.
The following CSYNC RR shows an example entry for example.com that
indicates the NS, A and records should be processed for the zone
using a minimum SOA serial number of 66.
example.com. 3600 IN CSYNC 73 1 A NS
Did you mean to write 66 in the RRDATA? Or did I misunderstand
something? Since you later write 0x42, I think you mean 66 here.
Yep. Thanks.
(huh; I had already fixed it in my text. And here I didn't think I had
edited it since publication!)
2.2.1 talks about fetching the SOA, CSYNC, data and again SOA record. I
think you need to state that you should also aboard if the CSYNC/SOA
serial obtained is lower then a previously processed CSYNC/SOA action.
Good point; added and thanks.
This will prevent flipflopping when one NS server is out of sync and
presenting old data.
Note that there is a state-keeping choice on behalf of the parental
agent, though... So choose a parental agent that advertises themselves
as keeping state.
This section should also indicate processing MUST be aborted if there
was no full path of trust from the parent to the child (ie. we need
DNSSEC authenticated data)
Added that all data needs to be validated as secure.
2.2.2.1. The NS type
It should note that parent policy might result in rejecting the proposed
change at the child, for example if only 1 NS record would be left.
Added:
tParental agents MAY refuse to perform NS updates if the
replacement records fail to meet NS record policies required
by the parent zone (e.g. every child zone must have at least
2 NS records)./t
2.2.2.4. The DS type
I kinda lost track here. It's pretty confusing. Also because the DS
type would really need to query DNSKEY, as the child is not publishing
DS records. (eg Queries should be sent to the child zone for all the DS
records is wrong)
Actually, no it's right. If you notice above that it says the child has
published DS records for their own zone below the cut point. It's
functionally CDS without the C because there is an external bit
saying to look for real DS records in the child. Obviously, these
records are never used during normal processing.
Although, that brings up a good point to people that were considering
wanting to use DS records in the child at the first place: if the
authoritative child zone server is also a recursive server for some
clients behind it (heavily discouraged, but still seen very commonly in
practice), there is no way for a validating stub resolver using the
recursive resolver to get the real DS records signed by the parent. So
I don't think we can actually do what the draft states at this point.
(but then, I'm not sure that doing DS/DNSKEY bits is the right choice
when compared to CDS)
In some sense, perhaps to facilitate parents that insist on creating
the DS from DNSKEY, and parents that insist on getting a DS RRdata
from child, to split the DS type here into CDS and DNSKEY type, where
the latter means create DS from DNSKEY. Although that would mean
large parts of the CDS draft would not really be used, if the CSYNC
scheduling part is used.
Well, the CSYNC draft does exactly that: splits the choice between two
bits so parents and children can get the job done using either DS or
DNSKEY. You're right, however, that we could use the CSYNC DS bit to
indicate do CDS instead. However, the existence of the CDS record
alone, since it's special, doesn't really require an external bit to
indicate go forth and copy like the other record types. The existence
of the CDS record is the go forth and copy bit.
2.3.3. support at parent.
If it is important that we know if the parent supoprts CSYNC and with
what parameters, should be define a RRtype for that which the parent
can publish? I'm hesitant to state in a protocol document that we need
something and suggest adding a human/manual procedure for that, when it
