./DS is NOERROR NODATA. This is RFC described behaviour to handle legacy servers and to handle the “grandparent problem”. “.” is not special here. If you get a query for DS at an apex of the zone you return NOERROR NODATA. The validator will then look the the cut point by using NS queries chopping off labels.
> On 22 Jul 2025, at 18:11, Petr Špaček <[email protected]> wrote: > > Hi all. > > I wonder how to interpret '. DS'/'. DELEG' queries and welcome opinions! > > First problem: > I did not find algorithm update for RFC 1034 5.3.3. Algorithm which would > clearly show that QTYPE=DS is special. > > Secondly it's unclear if RFC 4035 4.3. Determining Security Status of Data > somehow should applies to DS responses from root. I guess it should, but how? > > > With strict interpretation of 'DS lives at parent' I would argue '. DS' > should result in SERVFAIL: No parent for . can be contacted. > > If that does not fly and we don't like SERVFAIL, . DS answer should probably > get AD=0 in answer as security status would be Indeterminate - no way to > validate and no trust anchor for parent-of-root? > > Needless to say implementations vary in their responses. > > > I don't think this is operationally relevant, but it is sorta related to > DELEG protocol design which has the same property as DS - it is authoritative > at the parent side. > > If there are undefined corner cases for DS we might as well not repeat the > same mistakes for DELEG (or we can even fix it in one go ...). > > Thank you for your time. > > -- > Petr Špaček > > -- > dd mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
