Subject: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt

From: Ray Bellis <[email-masked]>
Date: Mon, 3 Jul 2017 18:47:23 +0100

This is just a "keep alive" so as to keep this draft in consideration as
one of the multiple solutions in this problem space while DNSOP decides
whether this is a problem worth solving.

I still think it's the most elegant of those proposed ;-)

Ray

-------- Forwarded Message --------

A new version of I-D, draft-bellis-dnsext-multi-qtypes-04.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:		draft-bellis-dnsext-multi-qtypes
Revision:	04
Title:		DNS Multiple QTYPEs
Document date:	2017-07-03
Group:		Individual Submission
Pages:		7
URL:
https://www.ietf.org/internet-drafts/draft-bellis-dnsext-multi-qtypes-04.txt
Status:
https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
Htmlized:
https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-bellis-dnsext-multi-qtypes-04
Diff:
https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsext-multi-qtypes-04

Abstract:
   This document specifies a method for a DNS client to request
   additional DNS record types to be delivered alongside the primary
   record type specified in the question section of a DNS query.

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 3 Jul 2017 20:20:53 -0400

> I still think it's the most elegant of those proposed ;-)

I whole-heartedly agree, as Ray's idea was the basic conclusion I'd
arrived at independently.  I was going to propose something very
similar (with only minor differences in details) until I found out
that I'd somehow overlooked his previous draft.

Note that I'm saying this even though I am also now working with
Warren and Wes on the multiple-response draft, which I suspect is one
of the other proposed solutions that Ray implies above.

I believe that multiple-response and multi-qtypes solve similar but
somewhat different problems.  As Wes observed during a conversation
last week, the former is for when the authoritative server believes it
knows what records you're going to want next (and even then can't
effectively signal the absence of any particular record).  The latter
is driven by the client knowing just types it'll want to know about
for a given qname, and indicates explicitly what the existence of each
is.

Multi-qtypes is also far easier to implement and will be much more
useful much more quickly.  It can roll out in resolvers and
authorities incrementally without depending on DNSSEC and with far
fewer security concerns.  At a recent industry meeting I announcement
my intention to ask Ray to revive it and was met with fairly
widespread support from both authoritative and recursive operators.

I'm strongly behind multi-qtypes and will be proselytizing for it as
well as contributing text.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Jul 2017 06:13:30 -0400 (EDT)

On Mon, 3 Jul 2017, Dave Lawrence wrote:

> arrived at independently.

I agree.

> widespread support from both authoritative and recursive operators.

Good!

And I think any ANAME/ALIAS record should be used in combination with
these, and of itself not define any new special handling.

Although, we should also be a bit careful not to create a new ANY type
query that will get abused for amplification, so it should really all
have source verified IP transports (DNS-COOKIES, TCP, etc)

Another issue to look at is returning any prefix special records,
such as TLSA records which do not match the QNAME, but are strongly
related to the QNAME and would benefit from being returned along.

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 4 Jul 2017 06:40:21 -0400

>> arrived at independently.

I remember we discussed the various drafts in a meeting (city of which 
escapes me) and the sense of the people in the room, and the folks I 
talked to afterward was that the preference was for a client to *ask* 
for extra things, rather than the server *forcing* extra answers back.

I think Ray's qtype draft fits this.   The chairs should finally discuss 
having a Call for Adoption on this after we've heard the updates

> these, and of itself not define any new special handling.

Well that's an interesting way to approach it.

> have source verified IP transports (DNS-COOKIES, TCP, etc)

The is good guidance, and some wording like this would be useful in the 
qtypes draft.

> related to the QNAME and would benefit from being returned along.

Excellent idea.  One reason we know why SRV records are not used by many 
is no one wants to do additional lookups.

tim

---

From: Ray Bellis <[email-masked]>
Date: Tue, 4 Jul 2017 12:55:23 +0100

On 04/07/2017 11:40, Tim Wicinski wrote:
>> Although, we should also be a bit careful not to create a new ANY
>> type query that will get abused for amplification, so it should
>> really all have source verified IP transports (DNS-COOKIES, TCP,
>> etc)
> 
> The is good guidance, and some wording like this would be useful in
> the qtypes draft.

I'd rather not constraint this to source verified transports.

There's a limit of 7 additional QTYPEs in the draft, which could be
trivially reduced to 3 (with little effect on the functionality) if that
would mitigate concerns about amplification.

Ray

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 4 Jul 2017 13:34:18 -0400

On 7/4/17 6:13 AM, Paul Wouters wrote:
>> really all have source verified IP transports (DNS-COOKIES, TCP, etc)

> would mitigate concerns about amplification.

I very much agree with Ray about not constraining it like this.

While for my own imagined use cases three is adequate, such as for
querying MX, A and AAAA simultaneously, I also don't see any
compelling reason to drop it from his proposed seven.  In my own
scheme I had planned on using a NSEC-like type bitmap, but having
spoken with Ray about this a while ago I know he's not keen on that.

To me the focus on answer size amplification is misdirected.  I am far
more concerned about packet count than packet size, and in any event
constraining this option to only verified channels makes it
immediately less useful.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Jul 2017 15:25:37 -0400 (EDT)

> spoken with Ray about this a while ago I know he's not keen on that.

I think the bitmap would be great. Limiting it to some artificial
special record types just causes people to avoid new records and
abuse existing records.

> constraining this option to only verified channels makes it

Yes, reducing packet count and roundtrips is the obvious goal we all
want, but we also want to avoid paying a DDOS price for it.

Paul

---

From: Ray Bellis <[email-masked]>
Date: Tue, 4 Jul 2017 21:29:53 +0100

> special record types just causes people to avoid new records and

My proposed option just uses the QTYPE number directly, so there's no
limitation on record types except that they can't be for META RRs (i.e.
OPT, and 128 - 255).

My argument against using an NSEC style bitmap was that in the vast
majority of cases it would result in a longer record (and one that's
more complicated to decode) than a simple list of QTYPEs.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Jul 2017 21:02:36 +0000

> more complicated to decode) than a simple list of QTYPEs.

not only that, but the nsec bitmap is currently uncompressed, which makes 
large rrtypes pretty dangerous to dnssec's deployment. until that's fixed, 
noone should be using that bitmap as an example of how to do other things.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Jul 2017 11:50:22 +1000

> noone should be using that bitmap as an example of how to do other things.

While it isn't compressed it is windowed.  It's where the type fits
in the window and how many windows that are active that control the
size of the map not whether the type code is large or not.  Yes, using
a generic compression algorithm would probably result in less bits.

11:36:33.535473 IP 127.0.0.1.53 > 127.0.0.1.59788: 64667$ 1/0/0 NSEC (85)
	0x0000:  4500 0071 3553 0000 4011 0000 7f00 0001  E..q5S..@.......
	0x0010:  7f00 0001 0035 e98c 005d fe70 fc9b 81a0  .....5...].p....
	0x0020:  0001 0001 0000 0000 0369 7363 036f 7267  .........isc.org
	0x0030:  0364 6c76 0369 7363 036f 7267 0000 2f00  .dlv.isc.org../.
	0x0040:  01c0 0c00 2f00 0100 000d a500 2407 6973  ..../.......$.is
	0x0050:  632d 736e 7303 6f72 6703 646c 7603 6973  c-sns.org.dlv.is
	0x0060:  6303 6f72 6700 0006 0000 0000 0003 8001  c.org...........
	0x0070:  40                              

isc.org.dlv.isc.org.	3493	IN	NSEC	isc-sns.org.dlv.isc.org. RRSIG NSEC DLV

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]