There's nothing prohibiting this in RFC 9460 and there may be reasonable operational use-cases for this, but operationally if you do it that way then all servers in the TargetName need to support the ech value. If they don't, then this would be a misconfiguration.
If you have different pools of servers with separate ech configurations then you need to use distinct TargetNames. For cases such as with Multi-CDN it's important to make sure that distinct TargetNames get used. This may be worth an explicit example in draft-ietf-tls-svcb-ech? For example, if you actually have two different servers with different ECH keys then you'd need to do something like: 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-1.test.defo.ie <http://puzzle.test.defo.ie>. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd1 puzzle-2.test.defo.ie <http://puzzle.test.defo.ie>. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd2 puzzle.test.defo.ie. 60 HTTPS 1 puzzle-1.test.defo.ie <http://puzzle.test.defo.ie>. ech=AEP+DQA/TwAgACANGCk5QZ0GWrmu1p7U3L2M73gyADqZkxhSy8x2/EIBLAAEAAEAAQAQY2QyLnRlc3QuZGVmby5pZQAA puzzle.test.defo.ie. 60 HTTPS 1 puzzle-2.test.defo.ie <http://puzzle.test.defo.ie>. ech=AEP+DQA/BAAgACCW2/dfOBZAtQU55/py/BlhdRdaauPAkrERAUwppoeSEgAEAAEAAQAQY2QxLnRlc3QuZGVmby5pZQAA (Note that Google Chrome's implementation doesn't fully support RFC 9460 yet and would ignore these and not use ECH, but that's a bug in Chrome which really needs to get fixed.) Erik On Sat, Oct 5, 2024 at 6:17 PM Watson Ladd <watsonbl...@gmail.com> 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. > > Sincerely, > Watson Ladd > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
