Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item

From: Alfred Hönes <[email-masked]>
Date: Tue, 29 Sep 2009 21:10:36 +0200 (MESZ)

George and all,
I generally sympathize with the transport signal draft and
would agree to say it's "worthwile for further study",
but I hesitate to push it so quickly.

Unless a draft has been fabricated "on order", it always has
proven useful to have it being discussed to some extent, and
perhaps cycled through a few updates, before approaching WG
work item status.

For instance, IMHO the proposed solution looks promising,
but it should be explored explicitely in advance and in the
draft, whether an EDNS option might be a reasonable alternate
vehicle for the desired semantics.  The very likely (sigh!)
trouble with middleboxes on the path counteracting the 'message'
of the proposed RR type might deserve particular consideration
as well, maybe in the ("TDB" anyway!) security considerations.
I would appreciate such topics being mentioned and weighed in
the draft before WG adoption.

I'm interested in related discussions, but I have to share
responsibly my spare cycles available for IETF work between
new items and ongoing work, and I hesitate spending expeditely
too much cycles for the former if doing so might defer due
follow-up work that has some realistic chance of contributing
to ongoing efforts being completed.

The WG already has quite a couple of work items that are due
(or arguably over-due) for being completed and shipped to the
IESG.  I therefore would appreciate if we could try to not
feed the pipeline too quickly and too heavily.

George, could you agree on postponing the question for adoption
until, say, after the upcoming IETF, and some degree of evolution
of the draft?  Many thanks for your patience in advance!

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Sep 2009 14:24:56 -0700

> of the draft?  Many thanks for your patience in advance!

This seems like good advice.  This draft limits itself to describing 
transports, but transport protocols might be created that operate over 
existing transports such as UDP.  It seems to be flexible in how to 
signal the supported transport modes, this might require its own 
registry without reliance upon simple transport protocol numbers.

-Doug

---

From: "George Barwood" <[email-masked]>
Date: Tue, 29 Sep 2009 23:29:52 +0100

Doug wrote:
> This draft limits itself to describing transports, but transport protocols
> might be created that operate over existing transports such as UDP.  

Yes, it is intended that any DNS transport protocol should be possible,
including new protocol(s) operating over UDP. In fact I'm working on 
such a protocol http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport.
I will try to make this clearer in the next version of the draft.

> It seems to be flexible in how to 

Yes, indeed the draft describes such a registry in the IANA considerations section :

<<
5.  IANA Considerations

The TPORT resource record type, with a sub-registry for DNS transport 
protocols, initialized to

TCP                1     [RFC1035]
UDP                2     [RFC1035]

There is a mild naming problem here. There is no short name that distinguishes
between "DNS/UDP as per RFC1035" and "The UDP protocol,RFC768". 
I think we have to live with this, the context should make it clear.
New protocols will have new names, if they happen to operate over UDP, 
that will be an incidental detail.

Regards,
George

---

From: Shane Kerr <[email-masked]>
Date: Wed, 30 Sep 2009 11:52:17 +0200

Alfred,

> the draft before WG adoption.

I thought the way to proceed in the IETF was to write a draft, so we
know what is actually being discussed? I am thankful that George has
taken the time to put such a thing together! (Thanks George)

I don't think that an EDNS option is useful because this information
only helps after you have reached the server you are trying to get to.
Ideally you want information about acceptable protocols before you try
them.

I think we should push for putting even information into such a record.
I'd like to see all kinds of useful information published about servers,
including: 

      * DNSSEC capabilities (NSEC, NSEC3, algorithms)
      * EDNS options supported
      * Perhaps transport-specific options (UDP buffer size)

My reasoning is that such a record is most useful at the parent - like
NS or DS records, they help the resolver to reach the correct name
server. However, since getting records from the child to the parent is
currently a clumsy, non-automated process, it is not something we want
to do often.

Alternately we could use RR types that publish specific information,
like the useful-but-poorly-named(*) TPORT, but then look at defining an
automated way to get information from the child into the parent. I think
Secure64 already has a proprietary protocol like this to get DS records
from children into parents. With a secured zone, it should be possible
to get all kinds of useful stuff from child into parent.

Or we could do both: define a single meta-NS record *and* a way to get
this into the parent.

--
Shane

(*) Sorry, when I see "port" I think "port number". Perhaps "TPROT" is 
    better?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Sep 2009 12:27:37 +0000

> From: Shane Kerr <[email-masked]>
> Date: Wed, 30 Sep 2009 11:52:17 +0200
> ...

since this information is about a server and not about a delegation, if we
put it into "the parent" we would gain the ability to describe the same
server in many and incompatible ways, which is a power i do not think we
have the discipline to avoid using.

> Or we could do both: define a single meta-NS record *and* a way to get

information about the server's capabilities should be part of the server,
like its A and AAAA are today -- so, EDNS capabilities or other transport
metadata like protocols and buffer sizes.  only information about the
delegation or the zone should be part of that zone's parent -- so, NSEC(3)
and algo's and key hashes (DS).

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 30 Sep 2009 10:31:57 -0700

> and algo's and key hashes (DS).

Is your concern that these newly suggested records shouldn't be stored
under example.com but instead under ns{1,2,3,...}.example.com, or that
parent servers should not need to know about or serve these new
records?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Sep 2009 17:53:27 +0000

> Date: Wed, 30 Sep 2009 10:31:57 -0700
> From: Matthew Dempsky <[email-masked]>
> 
> > information about the server's capabilities should be part of the
> > server, like its A and AAAA are today -- so, EDNS capabilities or other
> > transport metadata like protocols and buffer sizes. only information
> > about the delegation or the zone should be part of that zone's parent
> > -- so, NSEC(3) and algo's and key hashes (DS).
> 
> parent servers should not need to know about or serve these new records?

both, though i'd say that if we have a new NSCAP RR located adjacent to
the A/AAAA RRs, then this should be returned as glue in delegations, so
as to prevent anybody from having to look up these new RRsets.  in that
sense, there is a change in behaviour at the parent, even though it's in
the nameserver behaviour and not in the zone content itself.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 30 Sep 2009 11:06:24 -0700

> the nameserver behaviour and not in the zone content itself.

Okay, I concur with this then.