Subject: Re: [DNSOP] Batch Multiple Query Packet

From: Shane Kerr <[email-masked]>
Date: Thu, 1 Mar 2012 12:09:24 +0100

John,

On Wednesday, 2012-02-29 16:47:16 -0000, 
"John Levine" <[email-masked]> wrote:
> >The main (only?) advantage of doing it with EDNS is that you can work
> >with existing name servers. It means adding more logic to our already
> >fabulously complicated resolvers to get full benefit, but nobody ever
> >said DNS was easy.
> 
> If you're adding logic to servers and clients, why couldn't some of
> that logic listen on a different port?

Of course it could, but we would like old and new services to live
together happily.

What we don't want is for new servers to send a packet and have to go
through a timeout if old servers do not support the service.

In principle we could signal somehow that new servers are available
without sending a packet. The obvious way to do this - a new RR type -
is suboptimal, because if the new RR type does not live above the zone
cut then old style packets will still have to be used to figure out the
status of the servers.

Perhaps we could use a hack like the DNSCurve folks do, and encode in
the name of the delegation that it is a new-style server:

    waycool.example.com NS w--waycool-new-ns-1.waycool.example.com
			NS w--waycool-new-ns-2.waycool.example.com
			NS old-school-ns-1.waycool.example.com
			NS old-school-ns-2.waycool.example.com

If a hack like this makes sense, then a new port also makes sense.

> But honestly, I don't see what problem is being solved here.  The
> original motivation was to ask for SPF and TXT records at the same
> time, rather than sending two queries.  You don't need a new version
> of DNS to handle that, all you need is a kludge in your server that
> knows that when it gets a query for one, it can return the other in
> the additional section. MX queries already have their kludge,
> returning A and AAAA records.

I'm pretty sure MX queries do NOT have a kludge. I don't believe that
the additional section is actually used by any servers these days, so
MX queries (and their grown-up cousins, the SRV queries) are a great
example of where putting multiple queries in a single packet would be
helpful. While multiple queries in a single packet would not eliminate
all extra traffic, at least it would mean you could do all A/AAAA
queries in one follow-up packet:

  what is MX for xxx.example.com? ->
      <- a.example.com and b.example.com
  what are the A and AAAA for a.example.com and b.example.com?
      <- 192.0.2.1, 192.0.2.2

So we save 3 queries, although to be honest mail is the least
interesting since it all happens in the background and the traffic for
DNS is minimal compared to the traffic for the actual mail. :)

My personal goal is to improve resolution times for A/AAAA lookups by
collecting them into a single query. Perhaps it makes more sense to
simply add Yet Another DNS Hack and add a special QTYPE like ANY
meaning "any address", that is actually well-defined and usable.

There are possibly (probably?) other use cases, which is why I asked
what the use cases are. :)
 
> The meta-reason for doing two queries is that it's still so hard to
> provision new RR types that people fake them with TXT.  If we're going
> to hack on our DNS software, I'd rather work on that.

It will always be easier to simply use a TXT record. I can do pretty
much anything with a TXT record and my own software today... I just
start coding and a couple hours later there it is.

Even if the process is as simple as going to a web page on IANA and
filling in a 3-field form and waiting for the automatically-generated
confirmation e-mail, it will *still* be easier just to hack my own
stuff and not worry about it.

Having said that, it can't be extremely hard to get a new RR type.
There are tons of RR types that have been issued and never even had a
complete specification proposed. (You can see Ed's
draft-lewis-dns-undocumented-types for a list of these.)

So I think the meta-reason for doing multiple queries is because
sometimes you have related lookups and it would be handy to, you know,
do them at the same time.

Cheers,

--
Shane

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2012 09:08:55 -0500

> the additional section is actually used by any servers these days,

Really?  Caches throw away additional sections even when they're 
authoritative?  I find that rather surprising.

Why would it be a productive use of time to add all this new mechanism, 
rather than fix caches to use the exact same data that they're already 
getting?

I know about cache poisoning, but the logic to deal with it is exactly the 
same logic you'd have to use to decide which of multiple answers to 
accept.

> meaning "any address", that is actually well-defined and usable.

Add a new RR called AORAAAA that returns both with a field that has flag 
bits to say which is valid.  And, of course, the A and AAAA records in the 
additional section.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 1 Mar 2012 06:43:07 -0800

On Mar 1, 2012, at 6:08 AM, John R Levine wrote:

> Really?  Caches throw away additional sections even when they're authoritative?  I find that rather surprising.
> 
> Why would it be a productive use of time to add all this new mechanism, rather than fix caches to use the exact same data that they're already getting?
> 
> I know about cache poisoning, but the logic to deal with it is exactly the same logic you'd have to use to decide which of multiple answers to accept.
 
Yes, the logic should be "NEVER cache anything you didn't directly ask for, absent DNSSEC validation".  

Which means you (IMO) MUST throw away non-authoritative information in the additional section, and most resolvers will only even attempt to cache additional records when they are the records associated with the authority section.

It is the caching of non-asked-for data, be it Auth, Additional, CNAME chains, etc, which enables race-until-win attacks like the Kaminski attack.

Thus a resolver MUST NEVER cache data that wasn't specifically asked for if it can't DNSSEC validate this information.  It can use the additional data received to indicate that it SHOULD ask for the information, but it shouldn't ever cache it in a general context.

Or, if it does cache it, it should validate that the entry would be valid by performing an independent lookup, a'la Unbound and replace the information with the new version.

> Add a new RR called AORAAAA that returns both with a field that has flag bits to say which is valid.  And, of course, the A and AAAA records in the additional section.

Or don't bother.  As I mentioned earlier, this is a clear parallelization case, so the only thing you are saving in this optimization is ~100B of traffic, and the latency involved in transmitting an additional 100B through the network.

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Mar 2012 14:51:39 +0000

> authoritative?  I find that rather surprising.

It is also not very useful from the MTA point of view, since the MTA can't
tell if A or AAAA records are missing because they don't exist or there
wasn't enough space in the DNS reply etc. So in most cases (especially an
IPv6 aware MTA getting no AAAA records in reply) the MTA still has to
follow up an MX query with more queries to get address records.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: Cyclonic becoming north or northwest 5 or 6, veering east or southeast
4 or 5 later. Slight or moderate, occasionally rough. Occasional rain.
Moderate or good, occasionally poor.

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2012 10:02:16 -0500

> follow up an MX query with more queries to get address records.

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.

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.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Mar 2012 10:09:49 -0500

On Wed, Feb 29, 2012 at 10:22:55AM +0100, Shane Kerr wrote:
> Paul,
> 
> On Tuesday, 2012-02-28 18:40:30 +0000, 
> Paul Vixie <[email-masked]> wrote:

> > i'd start over with a new port number first. dns wire encoding is
> > already wildly complicated.

> fabulously complicated resolvers to get full benefit, but nobody ever

It seems to me that, from the point of view of "dns-ng" and
interoperation with dns, there are three possibilities:

    1.  End points use dns-ng.
    2.  End points use dns, but intermediate resolvers do dns-ng.
    3.  Everyone except authority servers do dns, and the authority
    server does dns-ng.

Your suggestion is, in effect, a way of doing (2).  But (3) isn't
interesting (if nobody else uses dns-ng, then the authority servers
aren't talking to anyone); and (1) is the actual goal we want, I
think.  

If dns-ng is a superset of useful dns functionality, but cleans up
certain issues with dns, then the intermediate resolvers in (2) can as
easily use a new port as they can use more complicated dns handling.
So I have to agree with Paul Vixie: if we're going to work on
replacing the protocol, let's replace it for real.  (FWIW, I think
this is a noble goal doomed to failure.  But I've been wrong before.
Probably three times just this morning.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Mar 2012 15:12:07 +0000

John R Levine <[email-masked]> wrote:
>
> 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.

That would help.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Westerly, backing southerly or southeasterly, 5 to 7,
perhaps gale 8 later. Rough or very rough. Wintry showers, occasional rain
later. Good, occasionally poor.

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2012 10:59:59 -0500

> Or, if it does cache it, it should validate that the entry would be valid by performing an independent lookup, a'la Unbound and replace the information with the new version.

This makes no sense.  Assuming you ignore records for which the server 
isn't authoritative (which we all do since Kashpureff), why wouldn't you 
use the records in the additional section?

Or to put it another way, if you're worried that the authoritative 
additional records are fake, why aren't the authoritative answer records 
equally fake?  Same server, same authority.

Regards,

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 1 Mar 2012 08:10:29 -0800

On Mar 1, 2012, at 7:59 AM, John R Levine wrote:

> This makes no sense.  Assuming you ignore records for which the server isn't authoritative (which we all do since Kashpureff), why wouldn't you use the records in the additional section?
> 
> Or to put it another way, if you're worried that the authoritative additional records are fake, why aren't the authoritative answer records equally fake?  Same server, same authority.

Because caching un-asked-for records is what allows "race until win": the ability of an attacker implementing blind cache poisoning to keep retrying the attack until successful.

If only the requested information is cached, an attacker targeting "www.victim.com" can only try to poison once per TTL, because after that, the resolver doesn't generate queries.

But if ANY sort of authoritatitive or additional information is cached unasked-for and unverified with a second request (INCLUDING the NS RRSET from the authoritative field), the attacker can start with "1.victim.com", with the additional information containing the poisoned record for "www.victim.com".  If success?  Great.  If failure?  Retry with "2.victim.com" and so-on.

Even with halfway-decent port randomization, Race Until Win can be a problem:  Poison the NS entry for .com on a major resolver using your botnet and, ohh, boy, can an attacker have some fun.

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2012 11:13:16 -0500

>> section that says there are no records of this type for this name, that can be

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,

---

From: Shane Kerr <[email-masked]>
Date: Thu, 8 Mar 2012 11:41:49 +0100

Ray,

On Wednesday, 2012-02-29 10:17:26 +0000, 
Ray Bellis <[email-masked]> wrote:
> 
> On 28 Feb 2012, at 18:40, Paul Vixie wrote:
> 
> if the EDNS option for this just had an array of additional QTYPE,
> such that the real QNAME and QCLASS pertained to all of these
> additional questions, then i could definitely see value in this. the
> response's OPT option would include the list of qtypes which were
> found to be non-empty. all of the rrsets would be in the answer
> section.
> 
> 
> Yes, that's pretty much what was in the draft I wrote (but didn't
> publish) and discussed with you during the last Prague IETF.
> 
> My rationale likewise was that having constant QNAME and QCLASS but
> multiple QTYPEs should eliminate the need for multiple RCODEs.
> 
> However further discussion with other folks revealed issues (ISTR
> around DNSSEC?) where it would be possible to get inconsistent RCODEs
> for different QTYPEs.
> 
> I've attached a copy of that document.  It could be resurrected if
> there's sufficient interest.

It looks reasonable to me. I'd support it moving forward.

An additional document that would complete the picture would be
describing recommended client & resolver behavior.

In the case of a stub resolver, this would simply be trying a query to
probe for support on the resolver, perhaps keeping this information
for a limited period of time.

In the case of a recursive resolver, then when a client query is
received that:

1. does not contain the EDNS0 option asking for multiple types, and
2. is for a RR type that usually involves a separate query for a
   related RR type

Then the resolver could add on the EDNS0 option when it tries to
resolve the name. That way the resolver could group A and AAAA queries,
or MX and A queries, or whatever, based on what users usually want. If
a subsequent query comes in while this is in process, then the resolver
is already busy looking up.

In order for this to work most effectively, the resolvers will need to
remember which authoritative servers support the EDNS0 option, so they
can break down queries with the option sent from clients if the server
does not support it. For lowest latency, probably the default should be
to assume that authoritative servers do not support the option.

Perhaps it makes sense to provide the server with a way to specify how
long it makes sense for a stub resolver or recursive resolver to cache
information about it (there is a lot of this kind of information, not
only this particular EDNS0 option).

--
Shane

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 29 Mar 2012 21:59:49 +0200

[cross-posting: dnsext readers please check the full thread on dnsop]
> Probably three times just this morning.)

On the other hand, it might be just the right time to do this.  With
dnsext closure we can start with clean table and redesign the underlying
mechanisms hopefully with lessons learned so far.

I like the idea very much and I would like to initiate BoF in Vancouver
if there is an interest to pursue this dns-ng thing.  And no it is not
meant as replacement for dnsext.  The WG should do it's job, produce WG
document(s) and close.  I am not trying to get mad, y'know :-).

O.
P.S.: I know I am responding to a month-old email, but better now than never...
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------