On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters <p...@nohats.ca> wrote:
> 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. > Agreed, thanks for taking time commenting. > 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? > > That's an example 5.3 > 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. > The proposal is opt-in, if the authoritative decides to throw in AAAA addresses then client should accept them. If it doesn't then it should requery. This is of course going to reduce the effectiveness in the transition period for names that have A, but don't have AAAA which is something I expect to change. The rationale is not to carry unnecessary payload when most authoritatives support it, but you make a good point that it might be better to mandate denial of non-existence proof now, and amend the draft later. > What is SNAME? Did you mean QNAME? > SNAME as in RFC1034, either QNAME or CNAME chain terminal name. 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. > Fair enough! 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 > The CNAMEs should be covered by the SNAME part, owner has to either match QNAME or terminal of CNAME chain just as a direct answer would. Maybe it needs a clarification. Thanks! Marek
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
