[DNSOP] Creating a query/record for A and AAAA

[Michael Sheldon <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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  <[e-mail]>  http://dotat.at
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>_______________________________________________
>DNSOP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsop