On Sat, Apr 11, 2020 at 3:12 AM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> On Fri, Apr 10, 2020 at 6:46 AM Shumon Huque <shu...@gmail.com> wrote: > >> Hi folks, >> >> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for >> consideration: >> >> https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 >> >> Comments/discussion welcome. >> > > There is one issue not addressed (here or anywhere else) that is > operationally relevant. > > If a domain's delegation NS set includes name servers that no longer act > as authoritative servers for the zone, there is no adequate mechanism to > signal to the parent zone or to resolvers that this is a permanent > situation. > True, but is the DNS protocol the right place to perform this function? And how would one know that this is a permanent situation or just a temporary misconfiguration ? I assume only the child zone operators would know that. My feeling is that these are configuration problems that are best handled outside the protocol (e.g. via proactive monitoring by the parent/child parties involved). The delegation (re)validation might be a reasonable place to implement > something to detect this and adjust the choice of NS on the resolver's > cache. > I think most resolvers do a bit of this today already. If they detect a broken delegation, they will mark that server as lame, and remove it from the candidate nameservers for the zone (for a certain period of time), and try another one. They don't however systematically query the entire NS set to identify all of the lame ones. (Part of the problem maybe be a "catch 22": the server receiving the query > isn't authoritative for the zone, so technically it can't/shouldn't return > anything authoritatively.) > Right. This might also be viewed (correctly) as a corner case in the RRR model > that doesn't get addressed; it seems to happen most frequently if a > registrant changes registrars or if a domain lapses, where the previous > registrar also acted as DNS operator for the zone. > I've heard proposals in the past that TLDs should routinely scan all their delegations to identify such problems, but I gather this is a challenging requirement to impose on them for various reasons. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
