Breaking this out of the ANAME discussion, since it has wider use. I've been thinking on this one. If I was to create a record, I'd set aside a byte or two at the beginning to denote family, but I'm just paranoid and OCD that way.
But what about just creating a query type HOSTA with behavior like MAILA? Where a query type for HOSTA would return A and/or AAAA records for the requested name. This prevents a long (possibly infinite) time where both A/AAAA and a new type would have to be supported. And if we wanted to create the new record type anyway, that could also be returned with HOSTA. Willing to bet a lot of implementations already have something similar internally to deal with MX/SRV targets. -- Michael Sheldon On June 22, 2018 3:20:12 PM MST, Mark Andrews <ma...@isc.org> wrote: >We do what we should have done from the very beginning and have a rdata >type that combines A and AAAA records. Master servers automatically >generate the type and sign it from the A and AAAA resets. Address >family is determined from the rdata length. > >We have a EDNS option that tells the recursive server to construct this >type if not present in the zone or return the A or AAAA records in its >place if construction would be detected by DNSSEC. If this option is >set you return the new type in the additional section in preference to >A and AAAA records. This way one is not waiting for all the master >servers to be updated. > >We also have a option that says recurse to populate the additional >section before returning and set tr if the additional section is too >small. The recursive server would use this option to signal if the >additional section is complete or not. > >-- >Mark Andrews > >> On 23 Jun 2018, at 06:08, Tony Finch <d...@dotat.at> wrote: >> >> The problem with SRV (and MX) is that you can’t tell what an empty >additional section means. (By “you” I mean anything in the resolver >chain: app, stub, recursor, etc.) >> >> If the AAAA records are missing, does that mean there aren’t any? >Does it mean they were not cached? Does it mean the server chose not to >provide them for some other reason? >> >> If you want to find out, you have to make a follow-up query to get a >clear answer, so you have spent two round trips instead of one. And >hopefully your recursive server omitted the AAAA because it has an >ncache entry so you get a quick answer, but that’s unlikely if the auth >server didn’t provide AAAA and the resolver didn’t eagerly go chasing >(which they don’t) and you are an early adopter of SRV so no one else >filled the ncache for you. >> >> This can (in theory) be fixed with DNSSEC, but the additional section >processing rules have to be changed so that they require the >nonexistence proof when records are missing, and of course stubs and >apps have to be changed to understand the NSEC(3) records. >> >> Mail servers generally regard additional sections as too unreliable >to be useful, and take the simpler slower approach of making all the >queries explicitly. It works for them because they are not especially >worried about latency. >> >> Because of all this I can sympathize with browser authors to some >extent; on the other hand, if they had adopted SRV before it was too >late, we might have done more to fix these problems in the last 22 >years. (eg an EDNS option to disambiguate missing additional records, >maybe.) >> >> Tony. >> -- >> f.anthony.n.finch <d...@dotat.at> http://dotat.at >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
