Internet DRAFT - draft-dougotis-srv-caa
draft-dougotis-srv-caa
Internet Draft Douglas Otis
Category: Standards Track Mail Abuse Prevention System
draft-dougotis-srv-caa-00.txt May 2004
Expires: December 2004
DNS Extension for SRV-Client Address Authorization (SRV-CAA)
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire in December 2004.
Abstract
Typical use of DNS records enables resolving a server address, but
this record extension authorizes clients to initiate a specific
protocol. This document simply extends definitions for fields of a
DNS SRV record as defined in [RFC2782] and appends '_c' to the label
in the Proto field. This extension enables administrative control of
a domain referenced by a client as it enables verification of
permitted client addresses. This record extension is useful to
authorize a client for a specific protocol and possibly useful for
confirming veracity of a return path also referenced by a client.
Although an in-addr.arpa IP address reverse DNS query may assert a
domain, the domain referenced within client identification may be an
alias and thus not match. In addition, specific protocol
authorization for the client can not be deduced and reverse DNS
information is optional, typically administered separately or not
Otis [Page 1]
RFC Draft May 2004
delegated, and thus often providing information of limited value.
Introduction
The SRV-CAA record relates protocols with addresses authorized by the
domain to act as a client. How this information is utilized depends
on the protocol. The published SRV-CAA record should be stable,
concise, and narrow in scope. Use of SRV-CAA allows publishing of
protocol/client/domain relationships as a means of adopting a
strategic solution for exigent situations where client domain
spoofing threatens network integrity.
Definitions
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
used in this document are to be interpreted as specified in [BCP 14].
Other terms used in this document are defined in the DNS
specification, RFC 1034.
Applicability Statement
In general, it is expected that SRV-CAA records will be used by
servers for applications where the relevant protocol specification
indicates use of these records. Such specification MUST define the
symbolic name to be used in the Service field of the SRV record as
described below. It also MUST include security considerations.
Service SRV-CAA records SHOULD NOT be used in the absence of such
specification.
Introductory Example
If an SRV-CAA cognizant SMTP server wants to verify the authorization
of an SMTP client using TCP protocol for the domain example.com., it
does a lookup of:
_smtp._tcp_c.example.com
The example zone file near the end of this document contains
answering RRs for an SRV query.
Note: SMTP is chosen as an example for illustrative purposes only,
and examples used in this document should not be considered a
definitive statement on the recommended way for SMTP to use SRV-CAA
records. As described in the earlier applicability section,
consult the appropriate SMTP documents for the recommended
procedures.
Otis [Page 2]
RFC Draft May 2004
Client/Server
A client/server relationship is typically established when a client
discovers a server by means of a DNS query with the server name and
then initiates a connection. Using the SRV-CAA record of the domain
referenced by client identifications, the server is now able to
perform an analogous operation to determine if the address of the
client is valid for this domain referenced in the client
identification. Use of this method offers weaker identifications
than certificate based schemes, but provides a light-weight domain
assurance for existing protocols lacking an otherwise sufficient
mechanism.
Format of the SRV-CAA RR
The format of SRV and (SRV-CAA) RR, whose DNS type code is 33:
_Service._Proto(_c).Name TTL Class SRV Priority Weight Port Target
(There is an example near the end of this document.)
Service
Service is the symbolic name of the desired service, as defined in
Assigned Numbers [STD 2] or locally. As per RFC2782, an underscore
'_' is prepended to the service identifier to avoid collisions with
DNS labels used to locate hosts. If Assigned Numbers names the
service, that name is the only legal name for SRV-CAA lookups. The
Service is case insensitive.
Proto
Proto is the symbolic name of the desired protocol, with an
underscore '_' prepended to prevent collisions with DNS labels used
to locate hosts and '_c' is appended the Proto identifier to avoid
collisions with labels used to discover services. _tcp_c, _udp_c,
and _sctp_c are at present the most useful values for this field,
though any name defined by Assigned Numbers, or locally, may be
used (as for Service). The Proto is case insensitive.
Name
Name is the domain this RR refers to. As with other SRV RR
queries, the SRV-CAA RR name used for queries is composed from the
domain name obtained from client identification; the example near
the end shows this clearly.
Otis [Page 3]
RFC Draft May 2004
TTL
Standard DNS meaning [RFC 1035].
Class
Standard DNS meaning [RFC 1035]. SRV-CAA records occur in the IN
Class.
Priority
The meaning of Priority differs from [RFC2782]. Priority is
generally used to indicate the nature of the client list as defined
by the protocol, for example whether the list is complete or open-
ended. Priority should be the same for all SRV-CAA records
accessed by the same label.
Weight
The meaning of Weight differs from [RFC2782]. Weight is generally
used to indicate the nature of the client as defined by the
protocol, for example whether information is being relayed or is
originating at the client.
Port
The meaning of Port differs from [RFC2782]. Port indicates the
allowed server port accessed by the client to initiate
communications. The range is 0-65535. A port value of 0 indicates
all server ports are allowed. This is a 16 bit unsigned integer in
network byte order. This value is often as specified in Assigned
Numbers, but need not be. If more than a single port is to be
allowed, the value of port should be zero.
Target
The meaning of Target differs from [RFC2782]. Target is the domain
name of the client. There MUST be one or more address records for
this name, the name MUST NOT be an alias (in the sense of RFC 1034
or RFC 2181). Implementors are urged, but not required, to return
the address record(s) in the Additional Data section. Unless and
until permitted by future standards action, name compression is not
to be used for this field.
Domain Administrator Advice
Expecting everyone to update their server applications when the first
Otis [Page 4]
RFC Draft May 2004
client publishes a SRV-CAA RR is futile (even if desirable).
Therefore SRV-CAA would have to coexist with other means used to
authorize the client.
Where clients within a domain are spread over several hosts, it seems
advisable to have a list of address records at the same DNS node as
the SRV-CAA RR.
Currently there's a practical limit of 512 bytes for DNS replies.
Until all resolvers can handle larger responses, domain
administrators are strongly advised to keep their SRV replies below
512 bytes.
A reply packet has a 30-byte overhead plus the name of the service
("_smtp._tcp_c.example.com" for instance); each SRV-CAA RR adds 20
bytes plus the name of the target host; each NS RR in the NS section
is 15 bytes plus the name of the name server host; and finally each A
RR in the additional data section is 20 bytes or so, and there are
A's for each SRV and NS RR mentioned in the answer.
This size estimate is approximate, but shouldn't underestimate the
actual answer size by much. If an answer may be close to the limit,
using a DNS query tool (e.g. "dig") to look at the actual answer is a
good idea.
Usage rules
A SRV-CAA cognizant server SHOULD use this procedure to verify the
address of the client has been authorized:
Do a lookup for QNAME=_service._protocol_c.name, QCLASS=IN,
QTYPE=SRV.
If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV-
CAA RR which specifies the requested Service and Protocol in the
reply.
If there is precisely one SRV-CAA RR, and its Target is "." (the
root domain), the client authorization is not valid.
If there were no SRV-CAA RR matching the requested Service and
Protocol, the client authorization is unknown.
Else, for all such RR's, do a lookup for QNAME=target, QCLASS=IN,
QTYPE=A and check for an address matching that of the client.
If the Priority indicated an open list, and there was no match,
then the client authorization is not confirmed.
Otis [Page 5]
RFC Draft May 2004
If an address match is discovered, and the port information
indicates an authorized port is in use, then client authorization
is confirmed. The protocol must then indicate how to process the
Priority and Weight information.
Notes:
If a truncated response comes back from an SRV-CAA query, the rules
described in [RFC 2181] shall apply.
If the Additional Data section doesn't contain address records for
all the SRV-CAA RR's, the server MUST look up the address
record(s). (This happens quite often when the address record has
shorter TTL than the SRV-CAA or NS RR's.)
Fictional Example
This example uses fictional service "foobar" as an aid in
understanding SRV-CAA records. If ever service "foobar" is
implemented, it is not intended that it will necessarily use SRV-CAA
records. This is (part of) the zone file for a fictitious
example.com:
$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
_foobar._tcp_c SRV 0 0 0 fred.example.com.
SRV 0 0 0 sam.example.com.
fred A 172.30.79.11
sam A 172.30.79.12
accounting A 172.30.79.13
server A 172.30.79.14
; clients are not authorized for other services
*._tcp_c SRV 0 0 0 .
*._udp_c SRV 0 0 0 .
In this example, a client of the "foobar" service in the
"example.com." domain needs an SRV lookup of
"_foobar._tcp_c.example.com." and possibly A lookups of
"fred.example.com.", and/or the other hosts named. The size of the
SRV reply is approximately 268 bytes:
Otis [Page 6]
RFC Draft May 2004
30 bytes general overhead
27 bytes for the query string, "_foobar._tcp_c.example.com."
58 bytes for 2 SRV-CAA RR's, 20 bytes each plus the lengths of
"fred", "sam", - "example.com" in the query section is quoted
here and doesn't need to be counted again.
73 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
"ns1" and "ns2" - again, "ip-provider.net." is quoted and only
needs to be counted once.
80 bytes for the 4 address records (assuming IPv4 only) mentioned
by the SRV and NS RR's.
IANA Considerations
No IANA services are required by this document.
Security Considerations
The author believes this RR to not cause any new security problems.
Some problems become more visible, though.
There is no way a site can keep its hosts from being referenced as
servers. This could lead to denial of service.
With SRV, DNS spoofers can supply false addresses. Because this
vulnerability exists already with names and addresses, this is not
a new vulnerability, merely a slightly extended one, with little
practical effect.
SRV-CAA Labeled TXT Records
A TXT record associated with the same label used to access the SRV-
CAA may be used to provide information related to error reporting as
determined by the protocol specification.
Otis [Page 7]
RFC Draft May 2004
References
STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
RFC 1035: Mockapetris, P., "Domain names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
RFC 974: Partridge, C., "Mail routing and the domain system", STD
14, RFC 974, January 1986.
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997.
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2782: Gulbrandsen, A., P. Vixie, and L. Esibov, L.,"A DNS RR for
specifying the location of services (DNS SRV)" February
2000.
Author's Address:
Douglas Otis
Mail Abuse Prevention System (MAPS)
1732 North First St. #680
San Jose, CA 95112
dotis@mail-abuse.org
Otis [Page 8]
RFC Draft May 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Otis [Page 9]
