In message <[email protected]>, Viktor Dukhovni writ es: > On Fri, May 08, 2015 at 11:08:00AM +1000, Mark Andrews wrote: > > > > 2.1. Example TLSA record > > > > > > In the example TLSA record below: > > > > > > _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( > > > E8B54E0B4BAA815B06D3462D65FBC7C0 > > > CF556ECCF9F5303EBFBB77D022F834C0 ) > > > > Which is a invalid TLSA record. "PKIX-TA", "Cert" and "SHA2-256" > > should all be numbers. > > I have no problem with that. What do we make of the text in RFC > 7218: > > https://tools.ietf.org/html/rfc7218#section-1 > > It is expected that DANE parsers in applications and DNS > software can adopt parsing the acronyms for each field. > > > This is how named parses TLSA records. Note there is *no* handling of > > non numbers. There is *no* intention to change this. > > Should 7218 have an erratum filed to clarify that the acronyms are > not intended to be used in zone files? Acronyms are not portable at the record level. Additionally almost no one constructs TLSA records by hand. They all use tools. Emitting acronyms just means the records are not maximally readable.
> Given that DNS software does not support non-numbers today, I am > fine with numbers in the document, so I'm just curious about the > apparent conflict with 7218. > > -- > Viktor. > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
