On Mon, 21 Mar 2016, Marek Vavruša wrote:
there was an interest in reducing latency for address record lookups. Me and
Olafur wrote a draft on adding AAAA records to A answers and treating them as
authoritati
ve. This fixes latency issues with NS A/AAAA discovery in resolvers and
improves caching for clients (AAAA already cached by the time client comes
asking for it).
Comments, feedback and snarky remarks would be great!
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/
I think this draft is a good idea. It does need some more writing out of
the use case and the possible interaction with some of the answer
sections. And some additional guidance with CNAME's with and without
DNSSEC.
Some comments/questions:
What happens with the Answer Count for QTYPE=A when there are no A
records and only AAAA records? And can the examples also clarify this?
What is the logic behind:
However, if there is a direct answer to the original question, but no
records for other address protocols, the authoritative DNS server
SHOULD NOT prove their non-existence. In this respect, they are
treated as additional data.
Are you just afraid of packet size to include the proofs? Because now
a client cannot distinguish between an old auth server not supporting
this draft and a new server supporting this draft (when no additional
A/AAAA exist to add). So if it wants to know about the other QTYPE,
it will need to make another query, even for auth servers implementing
this draft. Which is exactly what this draft is trying to prevent.
What is SNAME? Did you mean QNAME?
I'm also a little confused that section 3 auth servers only talks about A
and section 4 recursive servers only talks about AAAA. I like short
documents but I think you need to write this out a bit more :)
and it MUST reject any such records if the validation
fails, and the zone is not provably secure.
That's awkwardly written. If the zone is not provably secure (which is a
term you should not use, and instead use Bogus, Indeterminate. Insecure
or Secure) then there is nothing to validate - if you meant Insecure. If
you meant Indeterminate or Bogus, other text is warranted.
I think you mean to say if the zone _is_ secure, then any records in it
must be proven secure too.
other IP address records
You mean other QTYPE's for IP addresses :P
I don't think the Security Considerations use case mentioned is worth
mentioning. What is worth mentioning is if this involves CNAMEs,
because that leads to out of bailiwick data. And complications with
DNSSEC (chains to other zones?) and without (free Kaminsky attack)
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
