Subject: [DNSOP] AAAA4Free

From: Ray Bellis <[email-masked]>
Date: Fri, 8 Apr 2016 11:28:12 -0300

May I please remind the WG of draft-bellis-dnsext-multi-qtypes-01
(expired, but seems eminently applicable in this case as a signalling
mechanism, and is more general purpose)

Ray

---

From: Shane Kerr <[email-masked]>
Date: Mon, 11 Apr 2016 15:54:05 +0200

Ray,

At 2016-04-08 11:28:12 -0300

> mechanism, and is more general purpose)

Thanks for reminding us about this. I agree that a general-purpose
solution does seem a lot better.

I note that your idea was about 3 years ago. When it was mentioned,
Alfred Hönes noted his ideas about his presented 3 years before that.
My guess is that we could probably go back and every 3 or 4 years find
a similar proposal. :)

It seems like there might be appetite now to work on a fuller solution?
Certainly I am in favor of this, perhaps using your packet format as a
starting point.

Cheers,

--
Shane

---

From: Rob Austein <[email-masked]>
Date: Mon, 11 Apr 2016 15:00:37 -0400

At Mon, 11 Apr 2016 15:54:05 +0200, Shane Kerr wrote:
> At 2016-04-08 11:28:12 -0300 Ray Bellis <[email-masked]> wrote:
> 

Going back at least to the mid '90s, yes.  Don't recall whether this
came up in the '80s. :)

As I recall, the thing that stopped this every time was lack of
consensus on pesky details such as "to which QNAME does the RCODE
apply when this fails" and "to which QNAME does the AA bit apply?"

It's possible that DNSSEC-aware stub resolvers would provide some
leverage here, since fields like RCODE and the AA bit are somewhat
redundant if one can just check the freaking signatures.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 11 Apr 2016 21:13:42 +0000

I think this approach would really hamper adoption.

If we simply added a new QTYPE which permitted a server to respond with 
all matching A and AAAA records then that would solve a lot of problems. 
  "fixing" multiple queries per message by an extension option may fail 
on every DNS inspection firewall out there.

A new QTYPE approach would mean DNS server admins would need to do 
nothing except update their server to one that supports it.

Probably there are some more subtle issues that haven't come to mind 
that someone can think of.  like what happens when a new client sends a 
request to an old server, it could just make it worse (have to do 3 
lookups instead of 2).

Shame it wasn't put in from the start.

Alternatively, we could allow servers to respond with AAAA records in 
additional section if the QTYPE was for A?

Adrien

------ Original Message ------
From: "Rob Austein" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 12/04/2016 7:00:37 a.m.
Subject: Re: [DNSOP] AAAA4Free

>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ray Bellis <[email-masked]>
Date: Tue, 12 Apr 2016 00:12:42 +0100

> apply when this fails" and "to which QNAME does the AA bit apply?"

My draft attempts to avoid that by only having one QNAME - the EDNS
option just contains a list of extra QTYPEs that should be returned
alongside the primary QTYPE from the question.

Ray

---

From: Evan Hunt <[email-masked]>
Date: Tue, 12 Apr 2016 00:01:20 +0000

> all matching A and AAAA records then that would solve a lot of problems. 

As far as I've seen, all of these suggestions share the same problem:
No matter how the multiple-QTYPE query is implemented, EDNS option or
meta-type or whatever, you can't know in advance whether an authoritative
server will support it, and you won't want to waste a whole RTT waiting to
find out, so you're going to send simultaneous A and AAAA queries *anyway*.

So, unless I'm missing something (certainly more than possible), I don't
see server workloads or client latency being significantly reduced by the
deployment of a mechanism like this.

I agree it's a sensible idea to combine queries when possible, and I wish
a meta-type of the sort you describe had been included when the DNS was
designed originally.  But at this point, if we want to change the way
lookups work, the early adopters need to see a real benefit.  At this
point, I mostly only see costs.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Rob Austein <[email-masked]>
Date: Mon, 11 Apr 2016 20:08:10 -0400

> deployment of a mechanism like this.

Bingo.

Also keep in mind that A and AAAA for the same QNAME are in the same
zone, so by the time you've fetched (and validated, I hope) the chain
all the way down to one of them, you've done almost all of the work
involved in fetching (...) the other one.

I remain skeptical of the claim that the round trip time to the
iterative resolver is the critical factor.  Or, to put it another way,
if that's the critical factor, you almost certainly have other
problems that a multiple query hack isn't going to solve.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 12 Apr 2016 01:05:34 +0000

sure

the whole point of doing anything is to try and avoid mutliple lookup 
hacks, like the existing concurrent A and AAAA lookups.

What about allowing the AAAA responses in an A query?  Even if only in 
additional.

Adrien

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Apr 2016 11:25:24 +1000

> find out, so you're going to send simultaneous A and AAAA queries *anyway*.

Now, Yes.  In x years time, No.  It is possible to get reasonably
high levels of support quickly.  It is also possible to cache whether
a remote server supports functionality in the interim.

> point, I mostly only see costs.

The costs are minimal.  A bit of developement cost on the part of
nameserver and stub server developers then you just wait for
components to be updated.  We will waste more developer time arguing
over this than just doing it.

The key things needed are 1) a way to determine if the server
supports the extension and 2) defining the extension such that you
get a response for all types both positive and negative.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 Apr 2016 13:01:11 +0200

Evan,

At 2016-04-12 00:01:20 +0000

> point, I mostly only see costs.

There are two or three answers for this concern.

The first is that the main driver that *I* see is in the stub to
recursive scenario. As we know, recursive resolvers are the only
servers today that are currently suffering any kind of serious load
(excepting of course attack traffic).

A stub resolver can send a single probe query to each recursive
resolver that it knows about and then use that for follow-up queries
(with periodic re-checks, etc, etc.). This won't affect latency much,
but it will cut the number of queries significantly.

This is a HUGE WIN. It has the potential to remove almost half of the
queries that recursive resolvers have to answer. Half!

The second answer is that this capability will have to be one more bit
of data about authority servers that recursive resolvers have to
track. If they do so, then it is a big win for authoritative servers
that are authoritative for lots of zones. So my old employer, Dyn,
which hosts hundreds of thousands (or maybe millions) of zones on only
a handful of servers would have reduced traffic and load as would any
resolver sending it queries.

Whether this is actually true can really only be solved by measurement.
I should get off my lazy butt and make some instrumented resolver code
for this kind of thing... :(

A third answer which falls outside of any of the current proposals is
that there should be a way to document what the capabilities of an
authority server are explicitly. If only there was a way to store
meta-data about hosts in some sort of distributed database... ;)

Cheers,

--
Shane

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Apr 2016 12:06:25 +0100

> meta-data about hosts in some sort of distributed database... ;)

If only NAT and load-balancers didn't break the assumption that a single
IP address refers to a unique host with consistent behaviour... :p

[I'm aware of at least one major DNS operator that runs heterogenous DNS
clusters behind a single IP]

Ray

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 Apr 2016 13:57:20 +0200

Ray,

At 2016-04-13 12:06:25 +0100

> clusters behind a single IP]

Sure, it's quite common.

This could cause problems as people upgraded software in their cluster
where some of the servers support the multiple QTYPE option and others
do not.

Probably a sentence in the specification should warn about that, and
release notes from implementors should warn operators about this case.
Something like:

   "If a single IP address sometimes answers without support for the
   option, then this option should be disabled for all servers
   answering from that IP address. Implementors SHOULD have a way to
   disable the option, to support this case."

Since nobody is perfect, on the resolver side one would need to detect
the single-IP-mixed-capabilities case and downgrade the capabilities
tracked for the authority server. This implies that authority servers
MUST include some sort of option to indicate support for multiple QTYPE
in every reply, even if there is a single QTYPE.

(Note that this is orthogonal to how the resolver learns about the
support, whether it infers it from EDNS signaling or gets it from an RR
or whatever.)

Cheers,

--
Shane

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Apr 2016 12:32:37 +1000

In message <[email-masked]>, Shane Ker
> where some of the servers support the multiple QTYPE option and others

Not really provided you can determine if the query was answered by
a server that supported the extension or not.  The client can just
retry with multiple queries if the response indicates that the
extension is not supported.

Whats difficult is determining if a extension is supported or not
when DNS vendors do not follow the RFCs which are designed to make
the determination of whether a extension is supported or not easy.

If your servers fail any of the tests in draft-ietf-dnsop-no-response-issue
you are part of the problem.  If you are a vendor with a product
that fails any of the tests in draft-ietf-dnsop-no-response-issue
please issue a CVE for that product so that users can be informed
that they need to upgrade.