1 |
|
2 |
|
3 |
|
4 |
DNSEXT Working Group M. Graff |
5 |
Internet-Draft P. Vixie |
6 |
Obsoletes: 2671 (if approved) Internet Systems Consortium |
7 |
Intended status: Standards Track July 28, 2009 |
8 |
Expires: January 29, 2010 |
9 |
|
10 |
|
11 |
Extension Mechanisms for DNS (EDNS0) |
12 |
draft-ietf-dnsext-rfc2671bis-edns0-02 |
13 |
|
14 |
Status of this Memo |
15 |
|
16 |
This Internet-Draft is submitted to IETF in full conformance with the |
17 |
provisions of BCP 78 and BCP 79. |
18 |
|
19 |
Internet-Drafts are working documents of the Internet Engineering |
20 |
Task Force (IETF), its areas, and its working groups. Note that |
21 |
other groups may also distribute working documents as Internet- |
22 |
Drafts. |
23 |
|
24 |
Internet-Drafts are draft documents valid for a maximum of six months |
25 |
and may be updated, replaced, or obsoleted by other documents at any |
26 |
time. It is inappropriate to use Internet-Drafts as reference |
27 |
material or to cite them other than as "work in progress." |
28 |
|
29 |
The list of current Internet-Drafts can be accessed at |
30 |
http://www.ietf.org/ietf/1id-abstracts.txt. |
31 |
|
32 |
The list of Internet-Draft Shadow Directories can be accessed at |
33 |
http://www.ietf.org/shadow.html. |
34 |
|
35 |
This Internet-Draft will expire on January 29, 2010. |
36 |
|
37 |
Copyright Notice |
38 |
|
39 |
Copyright (c) 2009 IETF Trust and the persons identified as the |
40 |
document authors. All rights reserved. |
41 |
|
42 |
This document is subject to BCP 78 and the IETF Trust's Legal |
43 |
Provisions Relating to IETF Documents in effect on the date of |
44 |
publication of this document (http://trustee.ietf.org/license-info). |
45 |
Please review these documents carefully, as they describe your rights |
46 |
and restrictions with respect to this document. |
47 |
|
48 |
Abstract |
49 |
|
50 |
The Domain Name System's wire protocol includes a number of fixed |
51 |
fields whose range has been or soon will be exhausted and does not |
52 |
|
53 |
|
54 |
|
55 |
Graff & Vixie Expires January 29, 2010 [Page 1] |
56 |
|
57 |
Internet-Draft EDNS0 Extensions July 2009 |
58 |
|
59 |
|
60 |
allow requestors to advertise their capabilities to responders. This |
61 |
document describes backward compatible mechanisms for allowing the |
62 |
protocol to grow. |
63 |
|
64 |
This document updates the EDNS0 specification based on 10 years of |
65 |
operational experience. |
66 |
|
67 |
|
68 |
Table of Contents |
69 |
|
70 |
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
71 |
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 |
72 |
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 |
73 |
4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 |
74 |
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 |
75 |
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 |
76 |
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 |
77 |
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 |
78 |
6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4 |
79 |
6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4 |
80 |
6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 |
81 |
6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6 |
82 |
6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6 |
83 |
6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7 |
84 |
6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7 |
85 |
6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7 |
86 |
6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8 |
87 |
7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8 |
88 |
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 |
89 |
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 |
90 |
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 |
91 |
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
92 |
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 |
93 |
11.2. Informative References . . . . . . . . . . . . . . . . . . 10 |
94 |
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 |
95 |
|
96 |
|
97 |
|
98 |
|
99 |
|
100 |
|
101 |
|
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
|
108 |
|
109 |
|
110 |
|
111 |
Graff & Vixie Expires January 29, 2010 [Page 2] |
112 |
|
113 |
Internet-Draft EDNS0 Extensions July 2009 |
114 |
|
115 |
|
116 |
1. Introduction |
117 |
|
118 |
DNS [RFC1035] specifies a Message Format and within such messages |
119 |
there are standard formats for encoding options, errors, and name |
120 |
compression. The maximum allowable size of a DNS Message is fixed. |
121 |
Many of DNS's protocol limits are too small for uses which are or |
122 |
which are desired to become common. There is no way for |
123 |
implementations to advertise their capabilities. |
124 |
|
125 |
Unextended agents will not know how to interpret the protocol |
126 |
extensions detailed here. In practice, these clients will be |
127 |
upgraded when they have need of a new feature, and only new features |
128 |
will make use of the extensions. Extended agents must be prepared |
129 |
for behaviour of unextended clients in the face of new protocol |
130 |
elements, and fall back gracefully to unextended DNS. [RFC2671] |
131 |
originally proposed extensions to the basic DNS protocol to overcome |
132 |
these deficiencies. This memo refines that specification and |
133 |
obsoletes [RFC2671]. |
134 |
|
135 |
|
136 |
2. Requirements Language |
137 |
|
138 |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
139 |
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
140 |
document are to be interpreted as described in RFC 2119 [RFC2119]. |
141 |
|
142 |
|
143 |
3. EDNS Support Requirement |
144 |
|
145 |
EDNS support is manditory in a modern world. DNSSEC requires EDNS |
146 |
support, and many other featres are made possible only by EDNS |
147 |
support to request or advertise them. |
148 |
|
149 |
|
150 |
4. Affected Protocol Elements |
151 |
|
152 |
4.1. Message Header |
153 |
|
154 |
The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full |
155 |
16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a |
156 |
number of 1-bit flags. The original reserved Z bits have been |
157 |
allocated to various purposes, and most of the RCODE values are now |
158 |
in use. More flags and more possible RCODEs are needed. The OPT |
159 |
pseudo-RR specified below contains subfields that carry a bit field |
160 |
extension of the RCODE field and additional flag bits, respectively. |
161 |
|
162 |
|
163 |
|
164 |
|
165 |
|
166 |
|
167 |
Graff & Vixie Expires January 29, 2010 [Page 3] |
168 |
|
169 |
Internet-Draft EDNS0 Extensions July 2009 |
170 |
|
171 |
|
172 |
4.2. Label Types |
173 |
|
174 |
The first two bits of a wire format domain label are used to denote |
175 |
the type of the label. ,section 4.1.4 [RFC1035] allocates two of the |
176 |
four possible types and reserves the other two. More label types |
177 |
were proposed in [RFC2671] section 3. |
178 |
|
179 |
4.3. UDP Message Size |
180 |
|
181 |
DNS Messages are limited to 512 octets in size when sent over UDP. |
182 |
While the minimum maximum reassembly buffer size still allows a limit |
183 |
of 512 octets of UDP payload, most of the hosts now connected to the |
184 |
Internet are able to reassemble larger datagrams. Some mechanism |
185 |
must be created to allow requestors to advertise larger buffer sizes |
186 |
to responders. To this end, the OPT pseudo-RR specified below |
187 |
contains a maximum payload size field. |
188 |
|
189 |
|
190 |
5. Extended Label Types |
191 |
|
192 |
The first octet in the on-the-wire representation of a DNS label |
193 |
specifies the label type; the basic DNS specification [RFC1035] |
194 |
dedicates the two most significant bits of that octet for this |
195 |
purpose. |
196 |
|
197 |
This document reserves DNS label type 0b01 for use as an indication |
198 |
for Extended Label Types. A specific extended label type is selected |
199 |
by the 6 least significant bits of the first octet. Thus, Extended |
200 |
Label Types are indicated by the values 64-127 (0b01xxxxxx) in the |
201 |
first octet of the label. |
202 |
|
203 |
This document does not describe any specific Extended Label Type. |
204 |
|
205 |
In practice, Extended Label Types are difficult to use due to support |
206 |
in clients and intermediate gateways. Therefore, the registry of |
207 |
Extended Label Types is requested to be closed. They cause |
208 |
interoperability problems and at present no defined label types are |
209 |
in use. |
210 |
|
211 |
|
212 |
6. OPT pseudo-RR |
213 |
|
214 |
6.1. OPT Record Behavior |
215 |
|
216 |
One OPT pseudo-RR (RR type 41) MAY be added to the additional data |
217 |
section of a request. If present in requests, compliant responders |
218 |
which implement EDNS MUST include an OPT record in non-truncated |
219 |
responses, and SHOULD attempt to include them in all responses. An |
220 |
|
221 |
|
222 |
|
223 |
Graff & Vixie Expires January 29, 2010 [Page 4] |
224 |
|
225 |
Internet-Draft EDNS0 Extensions July 2009 |
226 |
|
227 |
|
228 |
OPT is called a pseudo-RR because it pertains to a particular |
229 |
transport level message and not to any actual DNS data. OPT RRs MUST |
230 |
NOT be cached, forwarded, or stored in or loaded from master files. |
231 |
The quantity of OPT pseudo-RRs per message MUST be either zero or |
232 |
one, but not greater. |
233 |
|
234 |
6.2. OPT Record Format |
235 |
|
236 |
An OPT RR has a fixed part and a variable set of options expressed as |
237 |
{attribute, value} pairs. The fixed part holds some DNS meta data |
238 |
and also a small collection of basic extension elements which we |
239 |
expect to be so popular that it would be a waste of wire space to |
240 |
encode them as {attribute, value} pairs. |
241 |
|
242 |
The fixed part of an OPT RR is structured as follows: |
243 |
|
244 |
+------------+--------------+------------------------------+ |
245 |
| Field Name | Field Type | Description | |
246 |
+------------+--------------+------------------------------+ |
247 |
| NAME | domain name | empty (root domain) | |
248 |
| TYPE | u_int16_t | OPT | |
249 |
| CLASS | u_int16_t | requestor's UDP payload size | |
250 |
| TTL | u_int32_t | extended RCODE and flags | |
251 |
| RDLEN | u_int16_t | describes RDATA | |
252 |
| RDATA | octet stream | {attribute,value} pairs | |
253 |
+------------+--------------+------------------------------+ |
254 |
|
255 |
OPT RR Format |
256 |
|
257 |
The variable part of an OPT RR is encoded in its RDATA and is |
258 |
structured as zero or more of the following: |
259 |
|
260 |
|
261 |
+0 (MSB) +1 (LSB) |
262 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
263 |
0: | OPTION-CODE | |
264 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
265 |
2: | OPTION-LENGTH | |
266 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
267 |
4: | | |
268 |
/ OPTION-DATA / |
269 |
/ / |
270 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
271 |
|
272 |
|
273 |
|
274 |
|
275 |
|
276 |
|
277 |
|
278 |
|
279 |
Graff & Vixie Expires January 29, 2010 [Page 5] |
280 |
|
281 |
Internet-Draft EDNS0 Extensions July 2009 |
282 |
|
283 |
|
284 |
OPTION-CODE |
285 |
Assigned by Expert Review. |
286 |
|
287 |
OPTION-LENGTH |
288 |
Size (in octets) of OPTION-DATA. |
289 |
|
290 |
OPTION-DATA |
291 |
Varies per OPTION-CODE. |
292 |
|
293 |
Order of appearance of option tuples is never relevant. Any option |
294 |
whose meaning is affected by other options is so affected no matter |
295 |
which one comes first in the OPT RDATA. |
296 |
|
297 |
Any OPTION-CODE values not understood by a responder or requestor |
298 |
MUST be ignored. Specifications of such options might wish to |
299 |
include some kind of signalled acknowledgement. For example, an |
300 |
option specification might say that if a responder sees option XYZ, |
301 |
it SHOULD include option XYZ in its response. |
302 |
|
303 |
6.3. Requestor's Payload Size |
304 |
|
305 |
The requestor's UDP payload size (which OPT stores in the RR CLASS |
306 |
field) is the number of octets of the largest UDP payload that can be |
307 |
reassembled and delivered in the requestor's network stack. Note |
308 |
that path MTU, with or without fragmentation, may be smaller than |
309 |
this. Values lower than 512 MUST be treated as equal to 512. |
310 |
|
311 |
Note that a 512-octet UDP payload requires a 576-octet IP reassembly |
312 |
buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. |
313 |
The consequence of choosing too large a value may be an ICMP message |
314 |
from an intermediate gateway, or even a silent drop of the response |
315 |
message. |
316 |
|
317 |
The requestor's maximum payload size can change over time, and MUST |
318 |
therefore not be cached for use beyond the transaction in which it is |
319 |
advertised. |
320 |
|
321 |
6.4. Responder's Payload Size |
322 |
|
323 |
The responder's maximum payload size can change over time, but can be |
324 |
reasonably expected to remain constant between two sequential |
325 |
transactions; for example, a meaningless QUERY to discover a |
326 |
responder's maximum UDP payload size, followed immediately by an |
327 |
UPDATE which takes advantage of this size. (This is considered |
328 |
preferrable to the outright use of TCP for oversized requests, if |
329 |
there is any reason to suspect that the responder implements EDNS, |
330 |
and if a request will not fit in the default 512 payload size limit.) |
331 |
|
332 |
|
333 |
|
334 |
|
335 |
Graff & Vixie Expires January 29, 2010 [Page 6] |
336 |
|
337 |
Internet-Draft EDNS0 Extensions July 2009 |
338 |
|
339 |
|
340 |
6.5. Payload Size Selection |
341 |
|
342 |
Due to transaction overhead, it is unwise to advertise an |
343 |
architectural limit as a maximum UDP payload size. Just because your |
344 |
stack can reassemble 64KB datagrams, don't assume that you want to |
345 |
spend more than about 4KB of state memory per ongoing transaction. |
346 |
|
347 |
A requestor MAY choose to implement a fallback to smaller advertised |
348 |
sizes to work around firewall or other network limitations. A |
349 |
requestor SHOULD choose to use a fallback mechanism which begins with |
350 |
a large size, such as 4096. If that fails, a fallback around the |
351 |
1220 byte range SHOULD be tried, as it has a reasonable chance to fit |
352 |
within a single Ethernet frame. Failing that, a requestor MAY choose |
353 |
a 512 byte packet, which with large answers may cause a TCP retry. |
354 |
|
355 |
6.6. Middleware Boxes |
356 |
|
357 |
Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. |
358 |
|
359 |
Middleware boxes which simply forward requests to a recursive |
360 |
resolver MUST NOT modify the OPT record contents in either direction. |
361 |
|
362 |
6.7. Extended RCODE |
363 |
|
364 |
The extended RCODE and flags (which OPT stores in the RR TTL field) |
365 |
are structured as follows: |
366 |
|
367 |
+0 (MSB) +1 (LSB) |
368 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
369 |
0: | EXTENDED-RCODE | VERSION | |
370 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
371 |
2: | DO| Z | |
372 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
373 |
|
374 |
EXTENDED-RCODE |
375 |
Forms upper 8 bits of extended 12-bit RCODE. Note that |
376 |
EXTENDED-RCODE value "0" indicates that an unextended RCODE is |
377 |
in use (values "0" through "15"). |
378 |
|
379 |
VERSION |
380 |
Indicates the implementation level of whoever sets it. Full |
381 |
conformance with this specification is indicated by version |
382 |
``0.'' Requestors are encouraged to set this to the lowest |
383 |
implemented level capable of expressing a transaction, to |
384 |
minimize the responder and network load of discovering the |
385 |
greatest common implementation level between requestor and |
386 |
responder. A requestor's version numbering strategy MAY |
387 |
ideally be a run time configuration option. |
388 |
|
389 |
|
390 |
|
391 |
Graff & Vixie Expires January 29, 2010 [Page 7] |
392 |
|
393 |
Internet-Draft EDNS0 Extensions July 2009 |
394 |
|
395 |
|
396 |
If a responder does not implement the VERSION level of the |
397 |
request, then it answers with RCODE=BADVERS. All responses |
398 |
MUST be limited in format to the VERSION level of the request, |
399 |
but the VERSION of each response SHOULD be the highest |
400 |
implementation level of the responder. In this way a requestor |
401 |
will learn the implementation level of a responder as a side |
402 |
effect of every response, including error responses and |
403 |
including RCODE=BADVERS. |
404 |
|
405 |
DO |
406 |
DNSSEC OK bit as defined by [RFC3225]. |
407 |
|
408 |
Z |
409 |
Set to zero by senders and ignored by receivers, unless |
410 |
modified in a subsequent specification. |
411 |
|
412 |
6.8. OPT Options Type Allocation Procedure |
413 |
|
414 |
Allocations assigned by expert review. TBD |
415 |
|
416 |
|
417 |
7. Transport Considerations |
418 |
|
419 |
The presence of an OPT pseudo-RR in a request should be taken as an |
420 |
indication that the requestor fully implements the given version of |
421 |
EDNS, and can correctly understand any response that conforms to that |
422 |
feature's specification. |
423 |
|
424 |
Lack of presence of an OPT record in a request MUST be taken as an |
425 |
indication that the requestor does not implement any part of this |
426 |
specification and that the responder MUST NOT use any protocol |
427 |
extension described here in its response. |
428 |
|
429 |
Responders who do not implement these protocol extensions MUST |
430 |
respond with FORMERR messages without any OPT record. |
431 |
|
432 |
If there is a problem with processing the OPT record itself, such as |
433 |
an option value that is badly formatted or includes out of range |
434 |
values, a FORMERR MAY be retured. If this occurs the response MUST |
435 |
include an OPT record. This MAY be used to distinguish between |
436 |
servers whcih do not implement EDNS and format errors within EDNS. |
437 |
|
438 |
If EDNS is used in a request, and the response arrives with TC set |
439 |
and with no EDNS OPT RR, a requestor SHOULD assume that truncation |
440 |
prevented the OPT RR from being appended by the responder, and |
441 |
further, that EDNS is not used in the response. Correspondingly, an |
442 |
EDNS responder who cannot fit all necessary elements (including an |
443 |
OPT RR) into a response, SHOULD respond with a normal (unextended) |
444 |
|
445 |
|
446 |
|
447 |
Graff & Vixie Expires January 29, 2010 [Page 8] |
448 |
|
449 |
Internet-Draft EDNS0 Extensions July 2009 |
450 |
|
451 |
|
452 |
DNS response, possibly setting TC if the response will not fit in the |
453 |
unextended response message's 512-octet size. |
454 |
|
455 |
|
456 |
8. Security Considerations |
457 |
|
458 |
Requestor-side specification of the maximum buffer size may open a |
459 |
new DNS denial of service attack if responders can be made to send |
460 |
messages which are too large for intermediate gateways to forward, |
461 |
thus leading to potential ICMP storms between gateways and |
462 |
responders. |
463 |
|
464 |
Announcing very large UDP buffer sizes may result in dropping by |
465 |
firewalls. This could cause retransmissions with no hope of success. |
466 |
Some devices reject fragmented UDP packets. |
467 |
|
468 |
Announcing too small UDP buffer sizes may result in fallback to TCP. |
469 |
This is especially important with DNSSEC, where answers are much |
470 |
larger. |
471 |
|
472 |
|
473 |
9. IANA Considerations |
474 |
|
475 |
The IANA has assigned RR type code 41 for OPT. |
476 |
|
477 |
[RFC2671] specified a number of IANA sub-registries within "DOMAIN |
478 |
NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option |
479 |
Codes", "EDNS Version Numbers", and "Domain System Response Code." |
480 |
IANA is advised to re-parent these subregistries to this document. |
481 |
|
482 |
RFC 2671 created an extended label type registry. We request that |
483 |
this registry be closed. |
484 |
|
485 |
This document assigns extended label type 0bxx111111 as "Reserved for |
486 |
future extended label types." We request that IANA record this |
487 |
assignment. |
488 |
|
489 |
This document assigns option code 65535 to "Reserved for future |
490 |
expansion." |
491 |
|
492 |
This document expands the RCODE space from 4 bits to 12 bits. This |
493 |
will allow IANA to assign more than the 16 distinct RCODE values |
494 |
allowed in RFC 1035 [RFC1035]. |
495 |
|
496 |
This document assigns EDNS Extended RCODE "16" to "BADVERS". |
497 |
|
498 |
IESG approval should be required to create new entries in the EDNS |
499 |
Extended Label Type or EDNS Version Number registries, while any |
500 |
|
501 |
|
502 |
|
503 |
Graff & Vixie Expires January 29, 2010 [Page 9] |
504 |
|
505 |
Internet-Draft EDNS0 Extensions July 2009 |
506 |
|
507 |
|
508 |
published RFC (including Informational, Experimental, or BCP) should |
509 |
be grounds for allocation of an EDNS Option Code. |
510 |
|
511 |
|
512 |
10. Acknowledgements |
513 |
|
514 |
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, |
515 |
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas |
516 |
Narten were each instrumental in creating and refining this |
517 |
specification. |
518 |
|
519 |
|
520 |
11. References |
521 |
|
522 |
11.1. Normative References |
523 |
|
524 |
[RFC1035] Mockapetris, P., "Domain names - implementation and |
525 |
specification", STD 13, RFC 1035, November 1987. |
526 |
|
527 |
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", |
528 |
RFC 2671, August 1999. |
529 |
|
530 |
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", |
531 |
RFC 3225, December 2001. |
532 |
|
533 |
11.2. Informative References |
534 |
|
535 |
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
536 |
Requirement Levels", BCP 14, RFC 2119, March 1997. |
537 |
|
538 |
|
539 |
Authors' Addresses |
540 |
|
541 |
Michael Graff |
542 |
Internet Systems Consortium |
543 |
950 Charter Street |
544 |
Redwood City, California 94063 |
545 |
US |
546 |
|
547 |
Phone: +1 650.423.1304 |
548 |
Email: mgraff@isc.org |
549 |
|
550 |
|
551 |
|
552 |
|
553 |
|
554 |
|
555 |
|
556 |
|
557 |
|
558 |
|
559 |
Graff & Vixie Expires January 29, 2010 [Page 10] |
560 |
|
561 |
Internet-Draft EDNS0 Extensions July 2009 |
562 |
|
563 |
|
564 |
Paul Vixie |
565 |
Internet Systems Consortium |
566 |
950 Charter Street |
567 |
Redwood City, California 94063 |
568 |
US |
569 |
|
570 |
Phone: +1 650.423.1301 |
571 |
Email: vixie@isc.org |
572 |
|
573 |
|
574 |
|
575 |
|
576 |
|
577 |
|
578 |
|
579 |
|
580 |
|
581 |
|
582 |
|
583 |
|
584 |
|
585 |
|
586 |
|
587 |
|
588 |
|
589 |
|
590 |
|
591 |
|
592 |
|
593 |
|
594 |
|
595 |
|
596 |
|
597 |
|
598 |
|
599 |
|
600 |
|
601 |
|
602 |
|
603 |
|
604 |
|
605 |
|
606 |
|
607 |
|
608 |
|
609 |
|
610 |
|
611 |
|
612 |
|
613 |
|
614 |
|
615 |
Graff & Vixie Expires January 29, 2010 [Page 11] |
616 |
|