Subject: [dnsext] Re: I-D Action:draft-li-dnsext-ipv4-ipv6-00.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jul 2009 11:51:44 +0200

On Mon, Jul 06, 2009 at 01:15:01AM -0700,
 [email-masked] <[email-masked]> wrote 
 a message of 53 lines which said:

> There are two kinds of TYPE for host IP address: one is A, the other
> is AAAA, which records IPv4 and IPv6 addresses respectively. This
> document defines a new TYPE, which is mainly used in queries in
> order to get both IPv4 and IPv6 addresses.

Certainly a good idea and I applaud the effort. But I vaguely remember
there was a long time ago a project to have a query type ADDR and that
it failed, so you may research history of this project to see what was
the problem.

There are many more details to address, your document is just a
start. For instance, you write "A BOTH query for a specified domain
name in the Internet class returns _all_ associated A and AAAA
resource records..." but this raises response size issues (see
draft-ietf-dnsop-respsize) so you may soften your requirment.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Shane Kerr <[email-masked]>
Date: Mon, 06 Jul 2009 14:29:11 +0200

All,

> draft-ietf-dnsop-respsize) so you may soften your requirment.

The main problem I see with this approach is that this will turn the two
queries that most applications do into three queries. If you sent a
query for the BOTH type to any server on the Internet today, it would
fail. Then the client would go  back to doing things the way it works
today (separate AAAA and A queries). This means 50% more load for years
and years to come, not 50% less load as we actually want.

I do agree that something like this would be very helpful. Apparently
multiple queries in a single packet are not allowed (not sure what the
reasons are, as 9 years ago I was not on namedroppers). Perhaps an EDNS0
flag or some other special-case hackery is the best way forward?

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jul 2009 14:38:02 +0200

On Mon, Jul 06, 2009 at 02:29:11PM +0200,
 Shane Kerr <[email-masked]> wrote 
 a message of 37 lines which said:

> Apparently multiple queries in a single packet are not allowed (not
> sure what the reasons are, as 9 years ago I was not on
> namedroppers).

My guess: because fields like Answer Count or Response Code are
global, not per-query. So, what to do if one query succeeds and the
other nxdomains?

---

From: Shane Kerr <[email-masked]>
Date: Mon, 06 Jul 2009 15:27:06 +0200

Stephane,

> global, not per-query. So, what to do if one query succeeds and the

If that is the concern then we have no worries, because we can restrict
the query to a single ownername, right? At least, we only care about A
and AAAA records for a single ownername in a single query (*).

But we still have the same problem of lack of support causing extra
queries. I wonder what different servers do if they see QCOUNT more than
1 today...

--
Shane

(*) And possibly HIP or other new address styles that show up.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Jul 2009 15:22:58 +0000

> Date: Mon, 6 Jul 2009 11:51:44 +0200
> From: Stephane Bortzmeyer <[email-masked]>
> 

i think the best we can do at this late date is to define additional data
rules for queries type A as including AAAA, and rules for queries of type
AAAA as including A.  so a query for either type would cause responses to
include that type in the answer section and include the other type in the
additional data section.

> start. For instance, you write "A BOTH query for a specified domain name
> in the Internet class returns _all_ associated A and AAAA resource
> records..." but this raises response size issues (see

the purpose of such additional data would be to forestall a second query
by prepopulating a cache with the the other kind of address record.  the
normal rules of "if additional data won't fit, don't add it" would apply,
so truncation wouldn't be an issue.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Jul 2009 16:06:38 +0000

> From: Shane Kerr <[email-masked]>
> Date: Mon, 06 Jul 2009 15:27:06 +0200
> 

a long, long time ago in a code base far away (BIND 4.9), i had to decide
this issue.  if all QNAMEs were identical, then the RCODE and the AA flag
would be unambiguous.  i actually considered responding with FORMERR if
QDCOUNT>1 and not all QNAMEs matched, but i had not yet been to an IETF
meeting nor written an RFC and i felt that conservatism would be better.

it's too late now, unless we wanted to link this behaviour to an EDNS
version number change, or unless we wanted to try QDCOUNT>1 first and then
fall back to multiple queries under the no-doubt-bizarre set of ways that
remote servers and their middleboxes and our middleboxes can muddy things.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 08 Jul 2009 08:59:11 +0000

> it failed, so you may research history of this project to see what was

Hmm.  I don't think I got the original message, and I think I might
already have replied to your message.  Oh well.

Would it help if there was some sort of EDNS0 flag/option which
instructed the server to include an NSEC(3) record for the QNAME, to
reveal which other RR types exist at that name?  Which type to query
first could be based on past performance.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Jim Reid <[email-masked]>
Date: Wed, 8 Jul 2009 10:21:19 +0100

On 8 Jul 2009, at 09:59, Florian Weimer wrote:

> reveal which other RR types exist at that name?

No. If some client wants to get an NSEC(3) RR in a response, it should  
explictly ask for one.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 08 Jul 2009 09:22:58 +0000

> No. If some client wants to get an NSEC(3) RR in a response, it should

Ahem, and how is AAAA different?

---

From: Jim Reid <[email-masked]>
Date: Wed, 8 Jul 2009 10:27:19 +0100

> Ahem, and how is AAAA different?

Please define what you mean by "different" here. Your question makes  
no sense.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 08 Jul 2009 09:38:15 +0000

> Please define what you mean by "different" here. Your question makes

The proposed draft attempts to reduce the number of queries during
transition to IPv6.  You say that you should just send more than one
query.  This could mean that you think the proposed protocol
improvement is unnecessary, or that the situation is somewhat
different there.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Jul 2009 20:40:07 +1000

> No. If some client wants to get an NSEC(3) RR in a response, it should  

	You can't ask for NSEC3 records.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Wed, 8 Jul 2009 11:45:51 +0100

On 8 Jul 2009, at 10:38, Florian Weimer wrote:

> query.

No. I said in reply to your question about revealing "which other RR  
types exist at that name" that a client could/should construct a query  
to which will yield precisely that response.

> This could mean that you think the proposed protocol

That's your interpretation. And it's somewhat incorrect.

IMO, I don't think there's much to be gained operationally by having  
some meta QTYPE return both A and AAAA records. An extra query to  
explicitly retrieve the A (or AAAA) records for some domain name will  
largely be lost in the noise of the other overheads when resolving  
that domain name. That said, it's always a nice idea to get as much  
DNS payload in as few packets as possible, particularly on mobile  
networks. Saving an extra DNS query/response with a BOTH QTYPE is all  
very well, but I think it raises much more subtle and possibly more  
serious operational/protocol concerns.

When the ideas in this I-D were floated 7 years ago as the ADDR QTYPE,  
Rob Austein explained quite clearly why this was a bad idea. In http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01334.html 
  he said:
"if there's more than one distinct RRset that can satisfy a particular  
query, you can't predict which RRset(s) you're going to get back in  
the response unless you're talking to the authoritative server.  
Additional section processing doesn't count, since in all but a few  
(reasonably well-understood) cases the additional section is just an  
efficiency hack and one can just query explictly for whatever one  
might have wished to find there."

I think the operational benefits from this latest draft are outweighed  
by other considerations. Section 3 of the I-D says "All existing query  
types that perform type A and AAAA processing must be redefined to  
perform type A, type AAAA and BOTH processing.". That's rather scary.  
What are the protocol and operational impacts of this on (say) glue  
handling and resolution of NS records? Will resolvers have to make  
BOTH queries as well as (or instead of) explicit A or AAAA queries?  
Also, what happens if/when IETF invents another address record or  
exhumes A6? These questions also apply to your suggestion of an extra  
EDNS flag.

---

From: Jim Reid <[email-masked]>
Date: Wed, 8 Jul 2009 11:49:02 +0100

> 	You can't ask for NSEC3 records.

dig @a0.org.afilias-nst.info org nsec3 +dnssec seems to work  
reasonably well even though the NSEC3 RR is in the Authority  
Section. :-)

---

From: Florian Weimer <[email-masked]>
Date: Wed, 08 Jul 2009 10:56:24 +0000

* Jim Reid:

> Rob Austein explained quite clearly why this was a bad idea. In
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01334.html
> he said:

The NSEC(3) hint I mentioned doesn't suffer from that.  We already
know that it works.  We only need to figure out if it is good enough
for the task at hand.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Jul 2009 14:30:46 +0200

On Wed, Jul 08, 2009 at 11:49:02AM +0100,
 Jim Reid <[email-masked]> wrote 

> reasonably well even though the NSEC3 RR is in the Authority

It should not :-) RFC 5155, 7.2.8, "Responding to Queries for NSEC3
Owner Names"

---

From: Florian Weimer <[email-masked]>
Date: Wed, 08 Jul 2009 08:59:11 +0000

---

From: Jim Reid <[email-masked]>
Date: Wed, 8 Jul 2009 11:49:02 +0100

---

From: Florian Weimer <[email-masked]>
Date: Wed, 08 Jul 2009 09:38:15 +0000

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Jul 2009 14:30:46 +0200

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2009 12:54:42 +1000

In message <[email-masked]>, Florian Weimer writes:
> >  [email-masked] <[email-masked]> wrote=20

So you want NXRRSET synthesis in caches?

> --=20
> Kriegsstra=DFe 100              tel: +49-721-96201-1

---

From: Florian Weimer <[email-masked]>
Date: Fri, 10 Jul 2009 07:15:06 +0000

> So you want NXRRSET synthesis in caches?

Sure.  It's the only way to throttle junk queries.