Subject: [dnsop] draft-ietf-dnsop-ipv6-dns-issues-07.txt and service names vs SRV records

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Jun 2004 17:25:31 +0300 (EEST)

Hi,

During the IESG evaluation of this document, there was one comment 
(there are probably more to come yet) from Steve Bellovin which I 
think deserves to be discussed in the WG:

Steve said:
======
4.1 advocates service names in the DNS.  Is this our official 
position, as opposed to SRV records?  I thought we wanted to 
discourage such things.  If SRV records are meant, this should be 
clarified.  (This is similar to one of my comments on 
draft-ietf-v6ops-application-transition, and should be resolved in the 
same way.)
======

(See at the bottom for what section 4.1 says.)

How do you feel about this?

My perception of the DNS *operational* situation is that:

 - yes, SRV records could be used, to the same outcome as described in 
section 4.1,
 - no, SRV records are not being used for these purposes for whatever
reasons (I don't know of those, but I guess they haven't reached 100%
penetration etc. so you can't only rely on them)
 - yes, most people do use service names instead of node names 
instead, so that's an established operational practice.

So, my own reaction to this comment is that we should just add a 
paragraph to describe that the same outcome is possible with SRV 
records but that might not always be a feasible option, and that the 
section deals with non-SRV situation.

But I'm interested in hearing what the others think about this, i.e., 
whether my perception about the DNS ops issue is right or wrong.  

The document says:
=====
4.1  Use of Service Names instead of Node Names

   When a node includes multiple services, one should keep them
   logically separate in the DNS.  This can be done by the use of
   service names instead of node names (or, "hostnames").  This
   operational technique is not specific to IPv6, but required to
   understand the considerations described in Section 4.2 and Section
   4.3.

   For example, assume a node named "pobox.example.com" provides both
   SMTP and IMAP service.  Instead of configuring the MX records to
   point at "pobox.example.com", and configuring the mail clients to
   look up the mail via IMAP from "pobox.example.com", one should use
   e.g.  "smtp.example.com" for SMTP (for both message submission and
   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
   Note that in the specific case of SMTP relaying, the server itself
   must typically also be configured to know all its names to ensure
   loops do not occur.  DNS can provide a layer of indirection between
   service names and where the service actually is, and using which
   addresses.  (Obviously, when wanting to reach a specific node, one
   should use the hostname rather than a service name.)

   This is a good practice with IPv4 as well, because it provides more
   flexibility and enables easier migration of services from one host to
   another.  A specific reason why this is relevant for IPv6 is that the
   different services may have a different level of IPv6 support -- that
   is, one node providing multiple services might want to enable just
   one service to be IPv6-visible while keeping some others as
   IPv4-only.  Using service names enables more flexibility with
   different IP versions as well.
====

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: David Kessens <[email-masked]>
Date: Mon, 21 Jun 2004 18:20:30 -0700

Pekka,

> section deals with non-SRV situation.

Yes, we would like to see a bit more discussion on the issues
involved, possibly a reference to why we (normally) don't like people
to use service names, and maybe some text why it is acceptable to
actually do this here (if that is the case) or make it clear that you
document existing practise (and I have used this practise as well :-))
but that SRV records are really better.

David Kessens
---
.