Hi all,
I have read draft-dnsop-deleg-00 and have some comments. It seems premature to
offer actual text as well as commentary but I can definitely do that if the
authors would like. I am fully enthusiastic about updating delegations and
referral responses, and anything negative below should not be accidentally
interpreted as some kind of objection, because far from it.
I wrote a vaguely similar draft to this one a while back (except not as good,
and it's expired, and nobody got particularly excited about it, which was
surely entirely fair). That draft contains a number of problem statements that
might be reusable here. The privacy motivation in particular seems pertinent,
but maybe the others too.
https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer-00
I understand the motivation for the text relating to the DNS operator not being
part of the Registry/Registrar/Registrant gang (clearly it's because the DNS
operator does not start with R, for a start) but I think the text that is there
is inadequate to cover the full breadth of that idea. There's a neat shortcut
there to put nameserver configuration in the hands of DNS operators, but
there's more to that story. I think this deserves more thought, if it is to be
mentioned in the base draft. Perhaps this means it doesn't belong in the base
draft.
The question of whether DNSSEC might be necessary in the use case where a
delegation involves a secure transport is perhaps best thought about as a
potential downgrade attack. A secure delegation coupled with validation of the
DELEG response when it arrives is a protection against that attack. While it
seems very sensible to warn about the attack and to suggest a mitigation, I
don't think it's useful to require that DNSSEC be used. That seems like a sure
fire way to make sure DELEG is not used, for a lot of people. Unless we are
certain that there is no benefit from DELEG without DNSSEC, perhaps DNSSEC
should not be mandatory.
The document is not very vocal on the question of whether a parent should
install both NS and DELEG RRSets above the zone cut, or whether there is an
opportunity for nameservers to use a DELEG if present to synthesise a
conventional referral with NSes. If DELEG doesn't mask NSes then there's the
question of what to do when the instructions in both delegations are different.
The draft says DELEG should be preferred, but to me this is just taking an
existing problem of parental and child NS sets being irritatingly different in
the wild and making the problem worse. If an authority server is capable of
loading a DELEG RRSet and generating referral responses accordingly, it's
surely also possible of synthesising an unsigned NS set?
Related, what to do when the ipv4hints are not the same as the corresponding A
RRSet?
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
