In general, the resolver function and the authoritative function are best separated on different servers. When serving local data on a local network it is usually necessary to integrate serving authoritative data into the resolver function.
If the proposal if for public DNS servers I no not see a value of such recommendations. Keep those apart. --- Mats Dufberg mats.dufb...@internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ -----Original Message----- From: DNSOP <dnsop-boun...@ietf.org> on behalf of Ralf Weber <d...@fl1ger.de> Date: Tuesday, 16 June 2020 at 08:57 To: Davey Song <songlinj...@gmail.com> Cc: dnsop <dnsop@ietf.org> Subject: Re: [DNSOP] Hybird Resolver/ DNS invariants Moin! On 16 Jun 2020, at 4:23, Davey Song wrote: > I happened to run into a discussion of behaviors of Hybrid Resolver/ DNS > invariants where some of the non-typical uses of DNS are listed, especially > on the resolver. I'm encouraged to put them down as a requirement draft of > these uses of DNS and ask the mailing list whether it is a good idea. I > hope it is helpful to provide information including risk for people who are > doing or going to the same thing. > > There are some existing cases in the discussion: > 1. A resolver syncs (pull or receive server push) with an authoritative > server. It reduces the recursion and resolves the very-short TTL > requirement. RFC7706 provides an approach. Other resolveless approaches are > used as well.. > 2. A resolver can forward queries to another resolver if the load is high > to reduce the recursion. > 3. A resolver/authoritative server mode serving Apps via DoH or other > Application-level DNS. Operators of apps can edit each response on demand > and propagate the changes of DNS RR in seconds. It also provides a private > zone and names for each Apps. > 4. A Hybrid DNS which is used as a name server but cache and pull the > authoritative data from another authoritative server. It provides an > approach to easily scale the system without any change of existing > authoritative DNS. > > Do you think it is a useful effort for DNSOP WG? Any suggestions or > observed related discussions on the DNS invariants? Some of these are the same old combination of authoritative and recursive function. Mixing these has caused a lot of problems, please don’t suggest to do that again. How DoX (T, H, Q) changes the DNS landscape is yet to be seen, but I don’t understand how answering via a different network protocol makes a server different. The DNS tree still is the same. What you describe is mix of observed behaviour and local implementations, and IMHO not the best way to deploy DNS, but others may have different opinions here. So if you want to describe these deployments, so that we can discuss them go ahead. But I don’t think that we want to require DNS being build that way. So long -Ralf —-- Ralf Weber _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
