> On 7 Dec 2018, at 7:59 am, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Thu, Dec 06, 2018 at 10:26:55AM -0300, Hugo Salgado-Hernández wrote: > >> On 18:54 05/12, Viktor Dukhovni wrote: >>> No idea why people would just "make up" (non-)random DS records for >>> their domains, but for some reason some do. These made-up DS RRs >> >> Could it be a bad (or nonexistent) validation in user input? >> >> I've seen customers putting hostnames, google validation tokens >> and even ftp passwords in DS fields. > > Well, the questionable values are well formed, they just have a > surprising "entropy deficit", which one would not expect in a SHA-1 > or SHA256 output. So syntactic input validation is unlikely to > catch this. > > To prevent crappy DS records, the registrar or registry would need > to check that the zone contains a matching key (matching key tag > and hash value) before publishing the DS record. In the examples > I posted, it seems clear that the values were accepted as-is, > without confirmation via the zone's DNSKEY RRset. > > IIRC some registrars don't support direct input of DS records, > rather they accept DNSKEY RRs, and compute the DS. That would > preclude some of the more creative junk values. Of course one can > still upload a junk RSA key. Junk keys are a bit more difficult > with ECDSA and EdDSA because keys have a fixed size and can be > validated as for correctness, here the worst one can do is use a > public key with a well known (example) or already leaked private > key.
Well if registries don’t care about checking NS and GLUE records for consistency why would they check DS/DNSKEY pairs? Garbage in - garbage out. Mark > -- > Viktor. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop