On Fri, Nov 10, 2023 at 11:30 AM Denny Watson <wat...@spamhaus.org> wrote:
> On 11/10/2023, Stephane Bortzmeyer wrote: > > On Fri, Nov 10, 2023 at 02:45:08PM +0000, > > Denny Watson <wat...@spamhaus.org> wrote > > a message of 50 lines which said: > > > >> One thing that is of interest to me; There appears to be no way for > >> the owner of the dataset being queried (they should understand what > >> exists in their zones better than anyone else) to signal that > >> beneath this domain cut you should just request the full QNAME. > > > > It does not seem a good idea, politically. It would enable any > > registry to shutdown QNAME minimisation for the zones it is > > authoritative for. > > > > This seems weird to me. Registries are not normally in the DNS path > _unless_ they control the full zone. > > Are there many instances where that someone registers a domain, point > that domain NSs to the registry and then create a number sub-zones and > point NSs to systems that they control? If they wish to control DNS do > they not they normally instruct the registry to publish NS records to > the TLD?.. and if the registry does have the full zone, they can see the > full QNAME that the user is attempting to reach. > > .. or perhaps I am missing something. > > It's relatively subtle: the TLD is normally not in the path when QNAME minimization exists. Putting something at the TLD level to disable QNAME minimization, would affect all queries for all names in that TLD. Which would basically trigger full QNAME queries for delegations to second-level domains, the exact behavior that 9156 seeks to avoid. Brian > -- > Denny Watson > Lead Investigator > The Spamhaus Project > > _______________________________________________ > 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
