Keith Moore <moore(_at_)network-heretics(_dot_)com> wrote:
On 10/8/19 7:34 AM, Tony Finch wrote:
The DNS protocol has to have special logic for every RRtype that appears
at a delegation, so you would need some kind of signalling to indicate
that this is OK for all the parties involved. (I have not thought about
the details of what would be required...)
I'm curious about this. I thought all of the logic required was on the
server end.
The DOTNS spec has decide if the records are like NS (appear both below
and above the cut) or like DS (above the cut only) so that resolvers are
able to know where to ask for them. For this to make sense from a DNSSEC
point of view the above-the-cut DOTNS records should probably be signed by
the parent zone (like DS) rather than being an unsigned non-authoritative
hint (like NS), so validators have to handle the zone cut correctly when
checking the RRSIG(DOTNS) signer name. There are probably other things
that need careful thought.
You also need to upgrade EPP so that registrars can get the extra records
into the registry database so that the registry can put them in the TLD.
Ah, that makes sense.
But I've been convinced for at least 20 years that the DNS protocol needed an
upgrade path anyway, and that having new kinds of "NS" records was the only
good way to do it. So to me the effort required to add support for new
delegation records seems like a necessary investment.
You are right. Sadly the experience of adding DS records has not been at
all successful: there hasn't been enough carrot/stick to implement the
upgrade on a sensible timescale. There would need to be quite a big change
of attitude for it to be worth trying something similar again.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
Shetland Isles: South or southwest 4 to 6. Rough or very rough, but moderate
in shelter. Rain or showers. Good, occasionally poor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp