Moin! On 6 Oct 2024, at 0:16, Watson Ladd wrote:
> Dear dnsop, > > In the course of discussing implementations of ECH I and Stephen > Farrel arrived at opposite conclusions about whether or not RFC 9460 > prohibits or allows the following kind of configuration. > > The zone puzzle.test.defo.ie has the following contents: > > puzzle.test.defo.ie. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd1 > puzzle.test.defo.ie. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd2 > puzzle.test.defo.ie. 60 HTTPS 1 . > ech=AEP+DQA/TwAgACANGCk5QZ0GWrmu1p7U3L2M73gyADqZkxhSy8x2/EIBLAAEAAEAAQAQY2QyLnRlc3QuZGVmby5pZQAA > puzzle.test.defo.ie. 60 HTTPS 1 . > ech=AEP+DQA/BAAgACCW2/dfOBZAtQU55/py/BlhdRdaauPAkrERAUwppoeSEgAEAAEAAQAQY2QxLnRlc3QuZGVmby5pZQAA > (Apologies for small listing errors: DNS is not a technology I know > nearly as much as I should) > > This is two different incompatible HTTPS records for the same > TargetName. My view is that this is not permissible: a server that > operates this way must expect either AAAA to receive a connection > configured with either ECH record, as outlined in section 2.4.3. There > is not an explicit prohibition on having two different HTTPS records > for the same target name, but I think this should be addressed > explicitly as it raises the question of which to use for a client and > makes a lot of text not make sense. DNS wise this is totally fine. You can always have multiple resource records of the same type for a name node. I don’t know a lot about ECH, but wouldn’t it also make sense to have multiple keys there when you e.g roll the backend keys and can not do that atomically? So long -Ralf --- Ralf Weber _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
