Skip to content

Instantly share code, notes, and snippets.

@miekg

miekg/grpc-dns.txt

Created December 29, 2015 21:21
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save miekg/00312222a3f98a4c2a99 to your computer and use it in GitHub Desktop.
Save miekg/00312222a3f98a4c2a99 to your computer and use it in GitHub Desktop.
Download ZIP
gRPC based DNS protocol
Raw
grpc-dns.txt
Network Working Group R. Gieben
Internet-Draft December 20, 2015
Intended status: Standards Track
Expires: June 22, 2016
gRPC based DNS protocol
draft-gieben-grpc-dns-00
Abstract
The Domain Name System (DNS) has existed for a long time and has
served the Internet well.
There are however some rough spots in the protocol. Because its main
transport is UDP, it is susceptible to reflection attacks. And there
is no way to update cached records, other than waiting for a TTL to
expire, to name a few.
This document specifies a protocol that is very similar to DNS, but
it uses gRPC (protocol buffer for the on-the-wire encoding, and
HTTP/2 as the transport) that adds extra features such as the
possibility to set watches to get notified on changes.
Because of the new encoding some elements in the new protocol have
changed. It does away (for instance) with the notion of classes. On
the other hand it will still resemble the DNS of old.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 22, 2016.
Gieben Expires June 22, 2016 [Page 1]
Internet-Draft gRPC DNS December 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Changes from the DNS . . . . . . . . . . . . . . . . . . . . 3
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Header Flags . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Sections . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Text Representation . . . . . . . . . . . . . . . . . . . 6
6. Watches . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Setting a Watch . . . . . . . . . . . . . . . . . . . . . 7
6.2. Replying to a Watch . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. TODO . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix B. Editorial Notes . . . . . . . . . . . . . . . . . . 10
B.1. Change History . . . . . . . . . . . . . . . . . . . . . 10
B.1.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Terminology
This document uses terminology specific to the Domain Name System
(DNS), descriptions of which can be found in [RFC7719].
Gieben Expires June 22, 2016 [Page 2]
Internet-Draft gRPC DNS December 2015
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The term "protobuf(s)" is used as short hand for Protocol Buffers
version 3 [proto3].
2. Introduction
The new protocol is based on the DNS protocol [RFC1033] [RFC1034]
[RFC1035] and the DNSSEC specification [RFC4033] [RFC4034] [RFC4035].
It is defined on top of gRPC [gRPC] and Protocol Buffers version 3
[proto3]. The transport being used is HTTP/2 ([RFC7540]).
DNS domain names are encoding in the format as specific in [RFC1035]
Section 3.1. Note that message compression is ([RFC1035],
Section 4.1.4) is not used. Also note that 255 octet limit for
domain names is gone as well.
As the transport layer now used is HTTP/2, the message limit of 64K
octets is gone as well.
3. Changes from the DNS
As this specification does not need to be fully backwards compatible
with the DNS, we can define a number of new elements and extends some
well known concepts.
The following new (or changed) elements are specified in this
document:
Limits are lifted: Domain name are no longer limited to 25 octets.
The message itself is no longer limiteed to 64K octets.
Message ID: The message ID is extended to 64 bits.
Version: A version field is added to the message header.
Extended question section: As said above (Section 4) the question
section contains a full resource record.
Message compression: Message compression (as specified in [RFC1035])
is not used.
Section counters: Section counters in the message header are removed
from the specification.
Watches are added: The ... bla bla added. See Section 6.
Gieben Expires June 22, 2016 [Page 3]
Internet-Draft gRPC DNS December 2015
Extension Mechanisms for DNS: The EDNS extension mechanism [RFC6891]
is not used in this specification.
The resources records are defined to have a similar look and feel and
the text representation of resource records is identical to those
specified in the original specification.
4. Message Format
The message format still adheres to one specified in [RFC1035], and
consists out of a header and then 4 sections: question, answer,
authority and additional section.
The question section now contains a full resource record, instead of
just a name and a type. A server MAY use that extra information.
The section counters in message header are not used.
4.1. Header
The header is defined as follows:
message MsgHeader {
uint32 version = 1;
uint64 id = 2;
uint32 opcode = 3;
uint32 status = 4;
MsgFlags flags = 5;
}
The header contains the following elements:
Version: An uint32, the current version is defined as 1. An
implementation that support version 1 MUST implement the
specification as provided in this document.
ID: An uint64 that is the identifier for this message. This value
MUST be randomly generated.
Opcode: All defined opcodes are defined for use in this
specification. It howevers adds one new one: WATCH with the value
TBD.
Status: All defined status codes are included in this specification.
Flags: See the section below (Section 4.2) for the flags that are
defined.
Gieben Expires June 22, 2016 [Page 4]
Internet-Draft gRPC DNS December 2015
4.2. Header Flags
There are seven flags defined:
message MsgFlags {
bool qr = 1;
bool aa = 2;
bool rd = 3;
bool ra = 4;
bool cd = 5;
bool ad = 6;
bool do = 7;
}
Note that the TC flag does not exist anymore because this condition
can not arise with gRPC DNS. The flags defined retain their original
meaning. Also some flags (the DO flag) have moved from the EDNS OPT
RR [RFC6891] to the header.
4.3. Sections
The rest of the message consists out of four section each container
zero or more RRs (see Section 5) for the definition of these.
message Msg {
MsgHeader header = 1;
RRs question = 2;
repeated RRs answer = 3;
repeated RRs authority = 4;
repeated RRs additional = 5;
}
Note that the question section always contains one resource record.
5. Resource Records
Resource records are redefined for this specification in protobuf
format. As classes are not used in this specification the RR header
only consists out of a domain name and TTL:
message Name {
bytes name = 1;
}
message Header {
Name name = 1;
uint32 ttl = 2;
}
Gieben Expires June 22, 2016 [Page 5]
Internet-Draft gRPC DNS December 2015
Because gRPC's smallest integers is a uint32 all uint16 values (or
smaller) are extended to uint32. Take for instance the definition of
the SRV [RFC2782] record:
message SRV {
Header header = 1;
uint32 priority = 2;
uint32 weight = 3;
uint32 port = 4;
Name target = 5;
}
The SRV record in protobuf format.
A [RFC1035] and AAAA [RFC3596] records are defined as follows:
message A {
Header header = 1;
bytes a = 2;
}
message AAAA {
Header header = 1;
bytes aaaa = 2;
}
A and AAAA RRs in protobuf format.
5.1. Text Representation
gRPC DNS can read [RFC1035] zone files. It just ignores the class
when parsing the data. When converting resource records the class is
omitted.
6. Watches
Watches are a way for a client to tell the upstream server (or
resolver) that they are interested in updates to this particular name
and at least one type. When such an update happens the client gets a
notification from the server that there was a change. It is up to
the client to re-query the server for the updated information. A
watch has a lifetime after which the server SHOULD discard it.
A watch contains:
ID: This is the ID of the watch.
Gieben Expires June 22, 2016 [Page 6]
Internet-Draft gRPC DNS December 2015
Index: Watch events from this index on. Initially the clients sets
this index to 0.
Name: The domain name the watch is for.
Types: An list of types. There should be at least one specified.
When does a watch fire? A watch fires when a domain name plus
type(s) change. A change constitutes the following:
(i) A new RR is added to the domain name. This can either be a
new type or an existing one.
(ii) An RR is removed removed from the domain name. This includes
removing the name in its entirety.
(iii) Changes in the rdata of one of the existing RRs.
When the server discovers a change it sends a ping message back to
the client. This ping message only contains the watch ID and the
index.
6.1. Setting a Watch
TODO
WATCH <id> <index> example.org A AAAA
PING <id> <index>
Re-enabling a watch.
6.2. Replying to a Watch
TODO
7. IANA Considerations
TODO
8. Security Considerations
TODO
Gieben Expires June 22, 2016 [Page 7]
Internet-Draft gRPC DNS December 2015
9. Acknowledgements
Your name here, etc.
The "source code" of this draft is written in mmark [mmark] and its
source can be found on GitHub [1].
10. References
10.1. Normative References
[gRPC] "gRPC: Protocol Buffers", 2015,
<https://developers.google.com/protocol-buffers/>.
[proto3] "Protocol Buffers Language Guide version 3", 2015,
<https://developers.google.com/protocol-buffers/docs/
proto3/>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
DOI 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
Gieben Expires June 22, 2016 [Page 8]
Internet-Draft gRPC DNS December 2015
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
10.2. Informative References
[mmark] Gieben, R., "Mmark git repository", December 2014,
<http://github.com/miekg/mmark>.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
10.3. URIs
[1] https://github.com/miekg/i-d.grpc-dns/
Appendix A. TODO
Further improvements:
o Add ADDR question type so a client can request A _and_ AAAA
records with one query?
o When connecting to a nameserver you'll need a TLS certificate,
those certificates are currently "name only"?
Gieben Expires June 22, 2016 [Page 9]
Internet-Draft gRPC DNS December 2015
Appendix B. Editorial Notes
This section (and sub-sections) to be removed prior to publication.
B.1. Change History
B.1.1. 00
Initial draft circulated for comment.
Author's Address
R. (Miek) Gieben
Email: miek@miek.nl
Gieben Expires June 22, 2016 [Page 10]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment