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

From: Olaf Kolkman <[email-masked]>
Date: Thu, 1 Oct 2009 12:59:32 +0200

On Oct 1, 2009, at 12:39 PM, George Barwood wrote:

>>
>> example.com. NS ns1.example.com.
>> example.com. A    192.0.2.5
>> example.com. TPORT UDP TCP QRP SCTP
>
> Of course that should be
>
> ns1.example.com. NS ns1.example.com.
> ns1.example.com. A    192.0.2.5
> ns1.example.com. TPORT UDP TCP QRP SCTP

That still does not make sense.

example.com. NS ns1.example.com.
ns1.example.com. A    192.0.2.5
ns1.example.com. TPORT UDP TCP QRP SCTP

is most probably what you mean.

You also wrote:
> The normal situation where you are using a name server not under
> your direct control is for the name server to be out-of-zone, and  
> therefore
> glue A, AAAA and TPORT records do not apply. The parent zone has

The naming of machines does not really tell anything about who has  
them under control (as an example a-m.root-servers.net, are all  
servers).

My point is really about making the coupling between provisioning and  
serving stronger than it already is. The information we are talking  
about is in essence control plane data and while we are used to  
putting some control plane data in the DNS (NS, SOA, DNSSEC data) we  
also know from operational experience that that leads to problems  
(lameness).

Having to put machine capabilities in the parent DNS will most  
probably give rise to similar problems (capability lameness).

I believe that if we have to signal capabilities we should try to do  
that in a way where the machine operator has direct and instant  
control over what data is communicated (EDNS does this) and preferably  
not use an indirection through 3 parties (2 in this case: zone owner  
and parent).

--Olaf

________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Alex Bligh <[email-masked]>
Date: Thu, 01 Oct 2009 12:12:41 +0100

> ns1.example.com. TPORT UDP TCP QRP SCTP

I think it should actually be:

example.com.     IN NS ns1.example.com.
ns1.example.com. IN A    192.0.2.5
ns1.example.com. IN TPORT UDP TCP QRP SCTP

(1st line has no 'ns1', plus "IN").

All this aside, to the extent that there is a requirement for
signaling transport support for DNS (making it clear UDP and
TCP are compulsory would appear to minimise this requirement
given current transport deployments), is there not an equal if not
greater need for such signaling between stub resolvers
and recursive caching servers? Given these are normally
known by IP address only to start off with, how are these
meant to be supported? TPORT in in-addr.arpa.? Reverse
lookup then forward lookup?

But if you really want to do this, why not just do:

example.com.         IN  NS ns1.example.com.
ns1.example.com.     IN  A 192.0.2.5
_dns._tcp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com.
_dns._udp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com.

And for a recursive server:

6.2.0.192.in-addr.arpa.    IN   PTR  rdns.example.com.
rdns.example.com.          IN   A 192.0.2.6
_dns._tcp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com.
_dns._udp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com.

(note this gives you a slight chicken and egg problem in establishing
how to query your recursive server to determine what protocols it
supports, but we know UDP is compulsory)

No new records needed. The absence of the _udp record indicates
no SRV records are there (i.e. that the absence of a _tcp record
does not indicate a lack of support for TCP).

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Thu, 01 Oct 2009 12:16:05 +0100

> _dns._udp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com.

Um, my turn to get stuff wrong:
 s/5060/53/g

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Thu, 01 Oct 2009 12:21:18 +0000

> From: "George Barwood" <[email-masked]>
> Date: Thu, 1 Oct 2009 13:14:00 +0100
> 

agreed.  i think it's a bad idea, but if we're going to have it then we
should put it next to the A/AAAA RRs not next to the delegation NS RRsets.

> I should say that I don't propose to put "capabilities" in general in.
> The new DNS Transport protocols should be very limited in number.
> Actually just 1 more would be ideal, but maybe 2 is ok.

i'm against anything like this.  initiators should self-discover, always.
not just because of inevitable "capability lameness" but also because not
all protocols will work from all locations (firewalls, middleboxes, host
network stacks).

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 1 Oct 2009 11:52:31 -0700

> lookup then forward lookup?

Why can't clients get this information through DHCP (or whatever
they're using) just like how they get the name servers' IP addresses
already?

---

From: Alex Bligh <[email-masked]>
Date: Fri, 02 Oct 2009 00:25:56 +0100

> they're using) just like how they get the name servers' IP addresses

Presumably they could if there were a DCHP option to specify it. Right
now, they assume UDP.

-- 
Alex Bligh

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 2 Oct 2009 00:45:45 -0700

On Fri, Oct 2, 2009 at 12:43 AM,  <[email-masked]> wrote:
> Those gateways almost always point the client at the home gateway's own
> (usually disfunctional) DNS proxy.  Almost all such proxies _only_ support
> UDP.

Right.  So those broken gateways don't have any extra capabilities to
advertise, so clients that don't receive extra capability
notifications fallback to current behavior.

---

From: [email-masked]
Date: Fri, 2 Oct 2009 08:43:01 +0100

> they're using) just like how they get the name servers' IP addresses

Because the vast majority of consumers get their DNS settings from their 
home gateway.

Ray