Re: [DNSOP] Batch Multiple Query Packet

[Shane Kerr <[e-mail]>]

John,

On Wednesday, 2012-02-29 16:47:16 -0000, 
"John Levine" <[e-mail]> 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