Apple's DNS Long-Lived Queries Protocol
draft-sekar-dns-llq-06

draft-sekar-dns-llq has been presented for publication as an Informational RFC in the Independent Submissions Stream.

The document describes an implemented and widely deployed mechanism for learning about changes to DNS information without being required to poll the server.

However, the authors recognise (and support) the replacement of this protocol with the IETF's DNS Push Notification that will be an RFC soon. The document is very clear that the correct implementation step is to transition to the IETF work.

The purpose of this document is to provide a record of what has been implemented, present the operational experience that helped to shape the work on DNS Push Notification, and describe the transition to the IETF Standards Track approach.



We had some debate about whether this document should be published as Historic or Informational. It is currently marked as Informational because of the description of the transition, but I could easily be persuaded that Historic was more appropriate.



idnits shows three trivial issues. Two are bigus warnings...
  == Line 215 has weird spacing: '...in name    emp...'
  == Line 352 has weird spacing: '...esponse  clie...'
One is an outdated reference that will be fixed (hopefully with a
pointer to an RFC).
  == Outdated reference: A later version (-24) exists of
    draft-ietf-dnssd-push-15


There are two IANA actions described in section 10 of this document.
- EDNS0 Option Code 1 has already been assigned to this draft, and is accordingly marked as "on hold". This document requests IANA to update the entry to refer to the published RFC and to change the marking to 'Optional'.
- Port 5352 has already been assigned for LLQ. This document requests IANA to add a reference to this document.


The document was reviewed for me by Ted Lemon and by the ISE. The reviews are included below for information. The -04 version of this document addressed all of the points raised.

== Ted Lemon

> - Would publication of this document be harmful to the Internet?

I think the answer is no.  There's no particular reason that anybody would implement this protocol other than for backward compatibility with older Apple products, so it's unlikely to see significant deployment.

> - Is there any value in publication?

My personal opinion on this is that it's useful to document stuff that might be seen in the wild, so in that sense, definitely.  This protocol has been deployed and in use for quite a long time, and there are a lot of devices that can in principle use it.

I doubt that this specification will result in any significant new implementation work, but it will help people to understand what they are seeing in the wild, and may be useful for debugging. 

The document has been available on non-IETF web sites for many years, but having a stable reference for historical purposes would be better than just hoping that the site where it's been available in the past will remain available, something I consider fairly unlikely since it's a personal web site.

An additional reason to publish the document is so that it can be referred to by its successors.

> - Does this document adequately describe the protocol it documents?

|  DNS message format [RFC1035] in conjunction with an ENDS0 OPT

Should be EDNS0

This is incorrect:
  Encoding the LLQ request in an OPT RR allows for implementation of
  LLQ with minimal modification to a name server's front-end, and will
  cause servers that do not implement LLQ to automatically return an
  appropriate error (NOTIMPL).

According to RFC6891:
  Any OPTION-CODE values not understood by a responder or requestor
  MUST be ignored.

IOW, what will happen if an LLQ is sent to a server that doesn't implement LLQ is that it will be handled as a regular DNS question, not that it will return NOTIMPL.

However, in practice this probably isn't an issue, since it would be an operator error to configure a dns-llq.udp.* SRV record pointing to a server that doesn't implement LLQ.

In section 4:

  DNS caches not implementing LLQ proxying will return a NOTIMPL or
  FORMERR error to the client in the DNS message header -- the
  intermediate cache will not forward the request, as [RFC2671]
  specifies that OPT-RRs are not to be forwarded.

Once again, this is not true: the cache will simply look up the queried name and
return a normal response.  The current Apple open source implementation appears to
go directly to querying the SRV record and does not attempt to probe the local cache
to see if it supports LLQ.

Minor nit (section 4.1):

  The SRV target and the SOA mname SHOULD be identical.

There is no reason for this requirement.  mname is the name of the primary, but there's no reason an LLQ can’t go to a secondary.  I don't think this SHOULD causes any harm, but I mention it in case the authors want to clarify.

In 5.2.1:

  The request MAY contain multiple questions to set up multiple LLQs.

This means that an LLQ isn't a regular DNS message, and a non-LLQ-supporting cache won't know what to do with it.  On that basis, I would suggest that support for LLQs where no dns-llq._udp SRV record exists should just be dropped, and the document shouldn't mention sending queries to a local cache.

I think the local cache behavior in the presence of multiple questions is undefined, because there's no way to say to which question the message-wide RCODE refers.

Alternatively, the text could simply say that when using a local cache, only one query per message is permitted.

In 5.2.2:

                  To reduce server load, an
                  administrator MAY return this error for all records
                  with types other than PTR and TXT as a matter of
                  course.


I don't understand why A, AAAA and SRV records are expected to be static.  I guess this is based on the idea that the server is not a discovery proxy, but in that case, why are PTR and TXT records expected to be more dynamic?  I would suggest just leaving this up to the operator.

In 5.2.2:
  unique for the requested name/type/class.  The LLQ-ID SHOULD be an
  unguessable random number.  A possible method of allocating LLQ-IDs

Probably should say "unpredictable" rather than "unguessable."  "Unguessable" appears in other places in the document and should be changed there as well.

In 5.2.3:
  If the Setup Request fails with an error other than STATIC or
  SERV-FULL, or the server is determined not to support LLQ (i.e., the
  client receives FORMERROR or NOTIMPL in the DNS message header), the
  client MAY poll the server periodically with standard DNS queries,

This doesn't account for the case where the server doesn't support LLQ but does support EDNS(0).  In this case, the server will respond by answering the question (or with some failure RCODE).  The response will not contain a Setup Challenge.  The client should use the response with no Setup Challenge as an indication that LLQ isn't supported.

In practice, in existing implementations, this will never happen except as the result of a misconfiguration, since current LLQ implementations do not attempt to submit LLQs to the local cache.

Given that this is a historical document, it's not clear to me that the suggestions I've provided here are actually necessary, but I mention them because I think making these changes would bring the document closer to what is actually implemented than it is at present.  I would not object to the document being published as is, or to these suggestions being documented in section 9.


== ISE

Intended Status

You currently ave "Informational".  That's OK, but depending on the
answer you give to my comment on the Abstract, it may be that "Historic"
is more appropriate.

---

Abstract

Need a second paragraph to say why this is being published. It could be
for Historic reasons, or it could be to enable interop with legacy
implementations, or it could be to let previous experience inform future
work. Or something else.

In your original email you said...

  To facilitate clients and servers making the transition from LLQ to
  DNS Push it would be appropriate and helpful for implementers to have
  a stable published archival description of LLQ.

That might be fine text to include here, and suggests "Historic" for the
document status.

---

Section 1

I think the historic acuracy of a couple of paragaphs is broken. I
suggest:

OLD
  There is currently no equivalent in traditional unicast DNS.  Queries
  are "one-shot" -- a name server will answer a query once, returning
  the results available at that instant in time.  Changes could be
  inferred via polling of the name server.  This solution is not
  scalable, however, as a low polling rate could leave the client with
  stale information, and a high polling rate would have an adverse
  impact on the network and server.

  Therefore, an extension to DNS is required that enables a client to
  issue long-lived queries.  This extension would allow a DNS server to
  notify clients about changes to DNS data.
NEW
  This document defines an extension to DNS that enables a client to
  issue long-lived queries that allow a DNS server to notify clients
  about changes to DNS data.  This is a more scalable and practical
  solution than can be achieved by polling of the name server because
  a low polling rate could leave the client with stale information
  while a high polling rate would have an adverse impact on the network
  and server.

  The mechanism defined in this document is now being replaced by DNS
  Push Notifications [Push] as explained in Section 1.1.
END

---

1.1

I think that the four instances of "encouraged" in this section can
become "RECOMMENDED".  There is also a lowercase "recommended" that
could be made uppercase.

---

RFC 2671 has been obsoleted by RFC 6891. Should references in this
document be updated?

---

Section 3

s/format proposed here./format defined here./

---

Section 3

You have...

  Note that this protocol is designed for moderate data set sizes, and
  moderate change rates.

The term "moderate" is subjective and there is no way for the reader to
guess what you have in mind. Would it be possible to give some guidance
or scoping to the term in this sentence? Or is the subsequent sentence
intended to do that?

---

Section 3.1

Could you add a sentance or two of context?

I think you are noting values that have been assigned in a number of
registries.

|  EDNS0 Option Code:
|        LLQ 1

This is discussed in Section 10

|  LLQ-PORT 5352

This port number shows assignment to Kiren, which is fine. But would you
like to have the RFC number added to the registry? If so, you need a
note in Section 10.

|  Error Codes:
|        NO-ERROR    0
|        SERV-FULL  1
|        STATIC      2
|        FORMAT-ERR  3
|        NO-SUCH-LLQ 4
|        BAD-VERS    5
|        UNKNOWN-ERR 6

I can't find these in a registry. I'm not that is important if the codes
are totally specific to LLQ. But 5.2.2 seems to have this covered, so
why list them here?

|  LLQ Opcodes:
|        LLQ-SETUP    1
|        LLQ-REFRESH  2
|        LLQ-EVENT    3

Similarly, I don't find these in a registry, but they appear to be
specific to LLQ.

---

Section 5.2.1

I see how most of the error processing works, but...

  A client MUST NOT request multiple identical LLQs (i.e., containing
  the same qname/type/class) from a single source IP address and port.

Seems to me that this is "because to do so would gum up the works", but
I'm not sure the server can detect or protect against this.  If there is
a mechanism I missed, then call it out. If not then no need to fix
because the document is a description of what is deployed.

---

Section 9

OLD
9.  Problems with the LLQ protocol
NEW
9.  Problems with the LLQ Protocol
END

---

Section 9

This text...

  In the course of using LLQ since 2007, some problems were discovered.
  Since no further work is being done on the LLQ protocol, this LLQ
  specification will not be updated to remedy these problems.

...is really valuable.
I wonder if you could also put it in Section 1.1 (or even Section 1)
with a forward pointer to Section 9.

---

Section 10

Currently the registry entry says
1  LLQ  On-hold  [http://files.dns-sd.org/draft-sekar-dns-llq.txt]

Do you want the IANA registry to be updated to point to this RFC?

You probably also want the entry to be flagged as "Optional" not "On-
hold".

If so, you need to scribble a few words in this section and specifically
name the "DNS EDNS0 Option Codes (OPT)" registry.