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.