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

From: Tony Finch <[email-masked]>
Date: Mon, 2 Jul 2018 10:53:34 +0100

Paul Vixie <[email-masked]> wrote:
>
> for QTYPE=A, add AAAA as a desired additional data type.
>
> for QTYPE=AAAA, add A as a desired additional data type.

How does the server signal to a client that made an A query that there
are no AAAA records so the client does not need to make a followup AAAA
query? My answer: use DNSSEC :-)

What are the incentives to implement this? The current state of the art is
happy eyeballs version 2, which specifies concurrent AAAA and A queries;
the client has already made both queries before it finds out it only
needed to make one. I'm not sure how a client could know in advance that
it only needs to make one query.

I think there would be some benefit to this between auth and recursive,
provided the recursive server eagerly validates additional records and
promotes them to the authoritative answer level of RFC 2181 trust.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
partnership and community in all areas of life

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 2 Jul 2018 12:27:40 +0200

Hi,

> On 2 Jul 2018, at 11:53, Tony Finch <[email-masked]> wrote:
> 

This really isn’t about incentives, but not making the situation worse.

A single query without signalling (opportunistic) and without state will
double the latency compared to dual A + AAAA query fired at the same
time.

> promotes them to the authoritative answer level of RFC 2181 trust.

So, instead of adding additional complexity of validating and storing the
unsolicited information in additional section, the “prefetch” code in resolvers
could be enhanced to pre-fill the cache with additional records when specific
RTYPE is requested…

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Jared Mauch <[email-masked]>
Date: Mon, 2 Jul 2018 09:34:36 -0400

> On Jun 29, 2018, at 12:38 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Michael Sheldon wrote:
>> 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.
> 
> that seems like the long way around.
> 
> advantages:
> no fork-lifts. incremental. opportunistic. no protocol changes. start today.
> 
> any server which does it will give better time-to-first-ad benchmarks, and will therefore outcompete any server who doesn't do it in all bakeoffs.
> 

I guess this depends on how the vendors implement the various minimal response bits.  I’ve turned this on because in ye olden days (I think it was the 2nd half of the 90s) you could poison a cache by dumping in additional data, sometimes even out of the zone additional and cause this trouble.

This is also documented as a performance gain, either due to less time packing the response or other wins.

As a longtime ANY (ab)user, I welcome an approach where we get AAAA + A at the same time.  This can be done by just returning the additional but it really depends on if the clients or stubs will use it.

- Jared

---

From: Paul Wouters <[email-masked]>
Date: Mon, 2 Jul 2018 10:39:31 -0400 (EDT)

> As a longtime ANY (ab)user, I welcome an approach where we get AAAA + A at the same time.  This can be done by just returning the additional but it really depends on if the clients or stubs will us…

If you are trusting an unsigned A record in the answer section, you might
as well trust the unsigned AAAA record in the additional section too.

I think minimum responses should still always just include this.

Paul
(although doing this only for DNSSEC would be a good motivator :)

---

From: Ray Bellis <[email-masked]>
Date: Tue, 3 Jul 2018 17:12:56 +0100

> I think minimum responses should still always just include this.

As others have pointed out, the problem is that if you don't get the
AAAA you can't be sure it doesn't exist (unless there's also an NSEC
record proving it).

I've just refreshed my multi-qtypes draft because it was about to expire
anyway, but also because it does include signalling to allow the client
to differentiate between a second QTYPE that doesn't exist vs one that
the server just doesn't have right now.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Tue, 03 Jul 2018 09:26:13 -0700

> AAAA you can't be sure it doesn't exist (unless there's also an NSEC

that's a cop-out. given negative caching both for names and rrsets, plus 
a lazy sweep-hand to semi-persistently determine the content or 
nonexistence of the rrset that wasn't available as additional data, this 
problem sorts itself at the recursive layer. and it is a non-problem for 
the authority layer.

> the server just doesn't have right now.

please, please, please make a document that advises authority and 
recursive server implementors to do this as additional data. do not add 
a new code-point.

-- 
P Vixie

---

From: Ray Bellis <[email-masked]>
Date: Tue, 3 Jul 2018 17:31:09 +0100

> recursive server implementors to do this as additional data. do not add

This is almost that document.  You're credited in it, since we had a
long talk about it in Prague in Spring '11.

Rather than a code point it uses an EDNS option from stub or recursor to
tell the server which additional QTYPEs to include in the response,
albeit it puts them in the Answer Section rather than the Additional
Section.

Ray

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 9 Jul 2018 03:51:19 -0500

Anthony Eden <[email-masked]>于2018年6月20日周三 上午12:06写道：

> On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan <[email-masked]> wrote:
>
>>
>>
>> Petr Špaček <[email-masked]>于2018年6月19日周二 下午9:19写道：
>>
>>> Hello dnsop,
>>>
>>> beware, material in this e-mail might cause your head to explode :-)
>>>
>>> This proposal is based on following observations:
>>> - It seems that DNS protocol police lost battle about CNAME at apex,
>>>    is is deployed on the Internet.
>>> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>>>    already have code to cope with the "impossible" case of CNAME at the
>>>    apex and deal with it in ways which do not break stuff on resolver
>>>    side.
>>> - Authoritative servers of vendors named above refuse to serve CNAME at
>>>    apex.
>>> - There are CDNs etc. which allow users to create CNAME at apex
>>>    no matter what the standards and "normal" servers say and do.
>>> (We have found out this because Knot Resolver is missing hacks for CNAME
>>> at apex and users complain that "it works with every other resolver".)
>>>
>>>
>>> Take a deep breath!
>>>
>>>
>>> Given that resolver side somehow works already ...
>>> could we standardize this obvious violation of RFC 1035?
>>>
>>> It is very clear violation of the standard, but almost everyone found
>>> his way around it using different hacks. These hacks are not going away
>>> because all the CDNs just don't care about standards so we will have
>>> to maintain this code no matter what a great solution we will invent for
>>> future. I.e. adding ANAME will just increase complexity because CNAME at
>>> apex will be there for a long time (if not forever).
>>>
>>> I personally do not like this but it seems better to think though
>>> corner cases in code we already have in production (i.e. think through
>>> current hacks for CNAME at apex) instead of inventing new things like
>>> ANAME (or whatever else).
>>>
>> I think ANAME RR is hard to compatible with many old version resolvers.
>> If there are mutiple ANAME RR at compatible resolvers, authoritatives may
>> not know that resolvers will choose which A RR for client response.
>>
>> ANAME can ease apex CNAME configuration, maybe a work round is that
>> authoritatives directly return A RR to resolvers (but not ANAME RR).
>>
>
> This is essentially what those of us who implemented ANAME in
> authoritative name servers do right now. The original draft I started about
> ALIAS records also spelled out only this solution with some operational
> guidance on best practices.
>

Section 4. Recursive Server Behavior:  send client subnet  when query ANAME
target ?
Would it be simpler director send client subnet when first query ?

Anyway, one of ANAME's benefits is that it can return both AAAA and A in
one response.

>
>>
>>> Opinions? Tomatoes? Can it work? If not, why not?
>>>
>>> --
>>> Petr Špacek  @  CZ.NIC
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> --
>> 致礼  Best Regards
>>
>> 潘蓝兰  Pan Lanlan
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
>
> --
> DNSimple.com
> http://dnsimple.com/
> Twitter: @dnsimple
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan