On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org> wrote: > > If this was a MUST NOT, then at the point that the RFC is published, would > that not mean that all DNS stub (and maybe recursive) resolvers immediately > become non complaint with the new standard?
That is exactly right. My bigger concern is the recursive resolvers you have in parentheses. The more new things that we say they must or should do, the more fragmented the DNS becomes because some will and some won't and many won't ever. Equally important: adding these new fragmenting rules have absolutely no effect on DNS users. > E.g., if I try and access https://somedomain.alt in my browser today then it > attempts to lookup the domain and fails because it doesn't exist. > My interpretation of Paul's comment is that nothing bad happens if a client > does attempt to resolve .alt names in the DNS because they will just fail in > the same way as any other domain that doesn't exist in the DNS, and that is > okay. Exactly right. The definition of the .alt SUDN is that it will not appear in the root zone, so that lookups will always just fail in the normal failure fashion. No new rules on resolvers are needed. > Possibly, the draft could have some text that allows stub resolves to filter > out DNS requests for .alt names if they wish. I.e., filtering does no harm, > performing the DNS lookup also does no harm, and the implementations can > decide if they want to add a special code path for this case or just follow > the standard code path. Decades of experience with RFCs has shown that MAY-level text like that confuses some implementers. Implementers that understand the protocol might already put in such a rule, possibly behind a configuration switch, as some do for names that they consider special. Implementers that don't understand the protocol are more likely to make mistakes if we say "you MAY $action", and in this case, $action will have no effect on DNS users. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
