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

From: Alfred Hönes <[email-masked]>
Date: Fri, 2 Oct 2009 13:14:48 +0200 (MESZ)

--On 01 Oct 2009 12:16:05 +0100 Alex Bligh <[email-masked]> wrote:

> --On 1 October 2009 12:12:41 +0100 Alex Bligh <[email-masked]> wrote:
>
>        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.
>
>
> Um, my turn to get stuff wrong:
> s/5060/53/g
>
> --
> Alex Bligh

Why not going one step further for the forward zone?

I suggest filing these SRV RRs for the domain being served,
not for the specific name server(s); that would more closely
correspond to the spirit (and text!) of the SRV specification,
reduce the number of queries needed when collection info about
all authoritative name servers for a domain, and it might also
help escape certain administrative/authority conflicts:

   example.com.         IN  NS ns1.example.com.
                        IN  NS ns2.example.com.
   ns1.example.com.     IN  A 192.0.2.5
   ns2.example.com.     IN  A 192.0.2.101
   _dns._tcp.example.com. 86400 IN SRV 0 5 53 ns1.example.com.
                          86400 IN SRV 1 5 53 ns2.example.com.
   _dns._udp.example.com. 86400 IN SRV 0 5 53 ns1.example.com.
                          86400 IN SRV 1 5 53 ns2.example.com.

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: Alex Bligh <[email-masked]>
Date: Fri, 02 Oct 2009 13:07:46 +0100

>                           86400 IN SRV 1 5 53 ns2.example.com.

Indeed. I had mistakenly thought this would complicate zone cut issues,
but it doesn't. I note "_domain" is already used for some form
of DNS discovery, though it is not immediately clear to me quite what.

-- 
Alex Bligh

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 2 Oct 2009 14:26:48 +0200 (MESZ)

Alex Bligh just wrote:

> --On 2 October 2009 13:14:48 +0200 <[email-masked]> wrote:
>

Ah!  You got me!  Back to square 1!

Indeed, the IANA Port Numbers registry lists the Service Name
"domain" for the registered service offered at the well-known
port 53 over UDP and TCP.

If we get enough support for
 http://tools.ietf.org/id/draft-gudmundsson-dns-srv-iana-registry-03.txt,
"_domain" would be a canonical candidate for Service Label
registration under the SRV Service Prefix IANA registry proposed
therein.  (Comments on that draft would be welcome as well!)

Kind regards,
  Alfred.

--

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 02 Oct 2009 13:52:00 +0100

> If we get enough support for

	Count me in as a supporter.

> therein.  (Comments on that draft would be welcome as well!)

	I've scanned it quickly; It looks useful to me.
	I'll try to make some less trivial comment after a careful
	reading.

	0,02
	/Niall

---

From: Alex Bligh <[email-masked]>
Date: Fri, 02 Oct 2009 14:31:45 +0100

> port 53 over UDP and TCP.

It should be "_domain", however Stuart Cheshire's document here
  http://www.dns-sd.org/ServiceTypes.html
suggests it might be already be used (possibly for something else),
hence I suggested "_dns". An extract from his document is appended below.

I'm interest to know what "Now advertised and browsed-for by
numerous independent server and client implementations" means.
As far as I know, RFC2782 does not specify how "_domain" should
work - i.e. is this advertising a recursive or an authoritative
DNS server, or something else?

-- 
Alex Bligh

dns-llq         DNS Long-Lived Queries
                Kiren Sekar <kiren at apple.com>
                Protocol description: DNS Long-Lived Queries
                Primary Transport Protocol: UDP
                Discovery Protocol: RFC 2782

dns-sd          DNS Service Discovery
                Stuart Cheshire <cheshire at apple.com>,
                Marc Krochmal <marc at apple.com>
                Not a service type. Special name reserved for DNS-SD
                meta queries.

dns-update      DNS Dynamic Update Service
                Kiren Sekar <kiren at apple.com>
                DNS Dynamic Update Service for a given domain may not
                necessarily be provided by the principal name servers
                as advertised by the domain's "NS" records, and may not
                necessarily always be provided on port 53.
                The "_dns-update._udp.<domain>." SRV record gives
                the target host and port where DNS Dynamic Update Service
                is provided for the named domain.
                Protocol description: RFC 2136, RFC 3007, and others.
                Primary Transport Protocol: UDP
                Discovery Protocol: RFC 2782

domain          Domain Name Server
                Service name originally allocated for Paul Mockapetris
                <PVM at ISI.EDU>
                Now advertised and browsed-for by numerous independent
                server and client implementations.
                Protocol description: RFC 1034, RFC 1035, and others.
                Primary Transport Protocol: UDP
                Discovery Protocol: RFC 2782

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 2 Oct 2009 15:53:29 +0200 (MESZ)

Alex Bligh just wrote:

> --On 2 October 2009 14:26:48 +0200 <[email-masked]> wrote:
>

The front-up investigations Olafur had performed for the
srv-iana-regitry draft did not provide evidence of "_domain"
being used in the wild.  Therefore, this Service Label has been
omitted from the proposed initial content for the registry.
The other three entries you have mentioned below, however,
have found their way into our draft (preferring the "-tls"
variant of "dns-llq", which had been observed in the wild.

> DNS server, or something else?

Good question(s), and perhaps another reason for _not_ including
this (potential) use of SRV in our proposal for the initial content
of the SRV Servcie Prefix registry, without enough unambiguous
documentation to ensure interoperability!

This is a very good example for one of the reasons I have opposed
to the attempt in draft-ietf-tsvwg-iana-ports-02 to automatically
and blindly register all present entries in the Port Number registry
for DNS SRV use as well, cf.
  <http://www.IETF.ORG/mail-archive/web/tsvwg/current/msg09423.html>

Kind regards,
  Alfred.

--