It appears that John C Klensin <john-ietf@xxxxxxx> said: >> However, in this modern time, I think that it might make sense to >> reference RFC9499 first and RFC1035 second. ... I'm with jck here, the benefits of changing this very old text seem less than the risk of screwing up a possible change. >> Non-DNS question: why is the "SHOULD NOT" in paragraph 2 of 4.1.1.1 >> not a MUST NOT? What is the exception? > >I'll like to hear from others in the WG, but there was a certain >reluctance to invalidate (i.e., render completely non-conforming) >existing conforming implementations without clear evidence of harm. I don't think I've ever seen an ENLO with extra data. I looked at the code for my mail server (mailfront) and it doesn't anticipate extra data in EHLO at all. So I think we can say MUST NOT now. As you note, MTAs are always free to make their own decisions about what to accept but this seems very low risk. >> Section 5.1 doesn't say what to do with chained CNAMEs. ... I read it as saying it starts the process over and follows the CNAME chain. >I _think_ the WG's conclusion was that, if a more extensive >discussion on this subject was needed at all, it should be in the >Applicability Statement. I do think there was some concern about >CNAME loops, e.g., > A IN CNAME B > B IN CNAME C > C IN CNAME A >especially if A, B, and C were in different domains. Again, this is >unchanged text from RFC 5321 and essentially unchanged from RFC 2821, >so we have gone a very long time without evidence of confusion or >other harm. It is my impression that in practice the CNAMEs are usually handled by DNS libraries including breaking loops and limiting chain lengths. I agree that nobody seems confused by the current language. >> Does section 5.1 need to talk about the NULL MX? This was discussed >> earlier, but isn't mentioned here. > >No opinion. I don't think it would be either hard or dangerous to >add a sentence there, perhaps as a second sentence in paragraph 2, >indicating that, if one of those is encountered, the lookup is over >and include a reference to those earlier discussions. WG? A reference to 4.2.4.2 would be OK, which is where it says to send back a 556 if it tries to relay to a Null MX. >> I found this text in 5.1 to be a bit more obscure than necessary: >> >> Any other >> response, specifically including a value that will return a CNAME >> record when queried, lies outside the scope of this Standard. >> >> Why not just say that any other response, including a CNAME even if >> it ultimately points to an A or AAAA record, is not a valid >> response and MUST be ignored? > >Don't remember. We might have been concerned about possible further >DNS extensions or the advent of IPvX and AAAAAAAAA records. While I could imagine some sort of SVCB response that provided, s.g., the equivalent of A, AAAA, and TLSA, that would need an explicit update. So I agree it makes sense to say any response other than A and AAAA is invalid. On the third hand, DNS libraries will typically follow CNAME chains automatically and give you both the CNAME and the A/AAAA it points to, but I don't think we need to go there. R's, John -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
