Splitting certificates in DNS could be done for example: 0.certificate.mydomain.com = first part of cert 1.certificate.mydomain.com = second part of cert and so on.
Or even a separate zonefile: 0.certificate.invalid = first part 1.certificate.invalid = second part as your application/web servers does directly know the IP of the DNS server and can do a direct query. But if the DNS client of the servers support very long records, you could aswell put the whole certificate there. My tought was that since its only used internally to distribute certificates out of you DNS server to your web/application servers without incurring additional server software (and additional security risks), it does not need to be the "correct" RRTypes (as some DNS clients does not support TLSA or CERT records). You could even hide these records from the public and only allow the IPs of the web/application servers in question to lookup them, if you don't want lots of "unneccessary" TXT records confusing the public. -----Ursprungligt meddelande----- Från: Jim Reid [mailto:[email protected]] Skickat: den 16 januari 2018 17:58 Till: Sebastian Nielsen <[email protected]> Kopia: [email protected] Ämne: TXT records for storing certificates in the DNS [invalid signature!] > On 16 Jan 2018, at 16:14, Sebastian Nielsen <[email protected]> wrote: > > Then you have a script that publishes the certificate. You could ACTUALLY publish the certificate in the DNS zone as a TXT. That would be a *remarkably* bad thing to do. More so when there already are RRtypes for storing certificates in the DNS (TLSA and CERT). TXT records get (mis)used for all sorts of things and it doesn't make sense to heap even more on to that existing babble. Or figuring out how to separate certificate favoured TXT records from any other TXT records that are floating about. > Each TXT record may only contain up to 255 characters, but you could easily split it up to multiple records. Nope. A TXT record can hold up to 65535 bytes. The name of the TXT record is limited to 255 characters. Splitting a certificate into multiple TXT records is another very bad idea. How would something know which TXT records need to be sorted/merged to reassemble the original string? Now suppose one of those TXT records got dropped from the Additional Section of a response. How would a client (know how to) recover from that? These are rhetorical questions BTW.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
