Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00.txt - WG item

From: Florian Weimer <[email-masked]>
Date: Sun, 04 Oct 2009 08:13:26 +0000

* George Barwood:

> I have updated the draft to try to reflect the comments made.
>
> http://www.ietf.org/id/draft-barwood-dnsext-dns-transport-signal-01.txt

| The TPORT record for a domain, if it exists, SHOULD be added to the
| Additional Section of a DNS response whenever an A or AAAA record for
| the domain is sent.

This is likely to break backwards compatiblity.

Could you make TPORT a special DS algorithm instead, extend the
algorithm number to 16 bits, and add some per-server parameters?

That is, the following data would be stored in the digest part of a
DS:

  +-----------------------------------------+
  | name server domain (variable length)    |
  +-----------------------------------------+
  | transport protocol 1 (16 bit)           |
  +-----------------------------------------+
  | transport parameter length 1 (16 bit)   |
  +-----------------------------------------+
  | transport parameter 1 (variable length) |
  +-----------------------------------------+
  | transport protocol 2 (16 bit)           |
  +-----------------------------------------+
  | transport parameter length 2 (16 bit)   |
  +-----------------------------------------+
  | transport parameter 2 (variable length) |
  +-----------------------------------------+
  :                                         :

For TCP and UDP, the transport parameter shall be the IP addresses of
the servers if glue record is present.  The transport parameter length
is used to disambiguate IPv4 and IPv6 addresses.  If present, this
information overrides the (unsigned) glue, but only for the owner name
of the DS record.  (Perhaps the name server name should be omitted to
force this behavior.)

A future Dnscurve-like transport would put the server's public key
into the transport parameter.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 06 Oct 2009 17:09:56 +0000

* George Barwood:

> Florian explained to me off-list that following the introduction of
> the AAAA record, some operational problems were encountered, 
> and apparently these broken resolvers are still deployed quite widely
> in parts of Europe. This sems odd, considering that AAAA
> records are sent in response to the priming query and many TLDs
> now have AAAA records. In view of this, I don't expect such problems
> to be serious, but will include something in the security section when
> I update the draft.

AAAA is a bad example.  But the original DNSSEC records were causing
problems, eventually leading to the DO flag.  It seems that resolvers
which send DO=1 queries can be expected to be more tolerant (NSEC3
proves that for the authority section at least).

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Oct 2009 17:25:21 +0200

On Sat, 2009-10-03 at 21:02 +0100, George Barwood wrote:
> I have not changed the resource record name (TPORT), because I think the
> current name is best, and any allusion to ports is not damaging - transport
> and port are closely related concepts in any case.

Okay, this mystifies me and for the record I think it is unnecessarily
confusing, but it's your baby. :)

> I have also not included any means by which name servers can dynamically
> advertise the DNS transport protocols they support. While acknowleging that
> static configuration mistakes can occur, I don't think that name servers attempting
> to dynamically ascertain their own capability is wise. For example even if the
> capability exists in the software, firewalls may not have been configured to
> allow incoming requests, or there may be operational or policy reasons why a
> transport is not to be used. IMO, the decision on which transports are to be used
> should rest with the domain owner (zone administrator), not the server software.
> There is the principle "Data belongs in the database".  I have included a note in
> the security section on this topic.

Sorry if I missed the discussion, but why use a separate registry for
TPORT protocol numbers? We already have a registry of such things:

http://www.iana.org/assignments/protocol-numbers/

One less piece of information to maintain and track, I think.

Also, maybe it should be mentioned that this changes DNS from explicitly
requiring UDP (and probably TCP, although not everyone agrees) to a
protocol that supports any arbitrary set of transports.

Finally, maybe it should be mentioned that if a client wants to be sure
than it can use DNSSEC to query for the TPORT record directly? It's an
extra query, so probably not useful in all cases, but possibly
worthwhile mentioning.

--
Shane

---

From: Paul Vixie <[email-masked]>
Date: Wed, 14 Oct 2009 18:20:32 +0000

> From: "George Barwood" <[email-masked]>
> Date: Wed, 14 Oct 2009 18:30:57 +0100
> 

> Well I would like it to be the IETF's baby, ...

-1.