Sounds like an AORAAAA record with flag bits would help there, too, so long as
the authoritative server returned it in the addition section. The client asks
for the MX, and gets the AORAAAA so it doesn't have to do A or AAAA requests
separately.
Doesn't solve the problem, because you can't infer anything about the
existence of a record based on it not appearing in an additional section.
Alternate grosse hackque: some way to return an anti-result in the additional
section that says there are no records of this type for this name, that can be
negative cached.
New improved hackque: the AORAAAA record contains two fields, which
contain the number of A and AAAA records at that name. The server tries
to put the A and AAAA records in the additional section, if the number of
A or AAAA records is less than the count, the client knows they were
truncated and has to ask for them explicitly, but in most cases won't.
The cache is allowed to synthesize a NODATA answer for A or AAAA if the
AORAAAA value was zero, although I admit that the interaction with DNSSEC
could be unpleasant. Of course, the NSEC record also tells you what kind
of records are present at a name, so it can equally well synthesize NODATA
from that.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
