Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa
Erik Guttman <[email protected]> Mon, 25 Apr 2005 10:23:07 +0200
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Organization | Sun Microsystems - N1 Architecture & Strategy |
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--Boundary_(ID_ipR+FRpu4pjXHUo6CVyn+w)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Folks,
[This page should be viewed as HTML, sorry if this inconveniences you!]
I support the text proposed by Bernard with the changes by Rob.
- - -
Let's see if we have closure on all items. Going back over the email
sent in the past weeks, I believe the points made are the following. If
I have left anything out or misrepresented the dialog, please reply with
a revised version of the table.
If anyone has any concern with the final suggested resolution (24 Apr
05), please send email to the list by next Monday, May 1.
*Date
* *Who
* *Problem
* *Suggested Resolution
*
05 Oct 04
RFC Editor
Starts 48 hour last call on RFC 3927
06 Oct 04
Stuart Cheshire
Several changes requested.
03 Mar 05
Authors, RFC Editor, post-WG
The requested changes were reviewed and the resolution was agreed to by
all parties.
15 Mar 05
Margaret Wasserman
Concern was raised due to related work in the IPv6 WG related to
reverse lookup of local addresses.
Bernard suggested a straw man resolution:
Here is a strawman:
This text will be added to a new 'DNS Server Considerations' section:
"Reverse (address-to-name) queries for IPv4 Link-Local
addresses MUST NOT be sent to name servers for the global DNS.
The recommended way to avoid sending such queries to nameservers for
the global DNS is for recursive name server implementations to act as
if they were authoritative for an empty 254.169.in-addr.arpa zone and
return RCODE 3 for any such query. Implementations that choose this
strategy should allow it to be overridden, but returning an RCODE 3
response for such queries should be the default, both because this
will reduce the query load problem and also because, if the site
administrator has not set up the reverse tree corresponding to
IPv4 Link-Local addresses in use, returning RCODE 3 is in
fact the correct answer."
24 Mar 05
Stuart Cheshire
Counter proposal:
The DNS experts are the one who have alerted us to the issue. While I
>agree there is probably room for debate as to "how big a problem this
>really is in practice", I doubt any one will argue that PTR queries
>for these addresses should be forwarded off link. Seems a no-brainer
>to just state that in the document. That is all that is being asked.
At the high level I agree that there is no point sending these PTR
queries off-link. Where I disagree is in the details, particularly in
caching servers returning authoritative NXDomain answers.
This is what I propose, and would support in the document:
Mapping from IPv4 addresses to host names is conventionally done
by issuing DNS queries for names of the form,
"x.x.x.x.in-addr.arpa." When used for link-local addresses, which
have significance only on the local link, it is inappropriate to
send such DNS queries beyond the local link.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.
DNS caching servers receiving queries from non-compliant clients
for names within the "254.169.in-addr.arpa." domain MUST silently
ignore them. A caching server MUST NOT attempt to complete such
queries on behalf of the client, and MUST NOT send any DNS
response back to the client.
This leads to debate that has not yet been
resolved. The individual problems and
attempted resolutions are summarized
below.
The point of debate is whether recursive
DNS servers MUST silently drop queries
for reverse lookup of LL addressses
or whether they should return error code 3.
Stuart suggests that servers silently drop
requests. Thomas and Dan suggest that
returning an error would help with
diagnosing failure conditions at the client
and reduce time outs.
27 Mar 05
Rob Austein
Stuart Cheshire wrote:
> The ONLY DIFFERENCE between what I'm saying here and what you're saying
> is that I want the recursive name servers to provide this defense in a
> form that encourages end-system devices to be fixed to not issue the
> queries in the first place, rather than a form that encourages end-system
> devices to continue with the bad behaviour forever.
Rob Austein replied:
It was not at all clear to me from the earlier exchange that this was
the only point on which we disagreed, but if so, I'm glad to hear it.
We should probably take this one point to the zeroconf list, since
Bernard has started the discussion there, but, in brief, I see two
issues here:
a) Whether silently dropping bogons is more likely to cause buggy
clients to upgrade than supplying RCODE 3 answers. This is not
obvious to me. I would think that users would be about as likely
to figure out that something's broken from being told that names
don't exist as they would from having queries time out, but I'll
stipulate that this is a matter of opinion on which reasonable
people might disagree in the absence of empirical data.
b) *Which solution is easier on the recursive name servers. This is
slightly more complex than it might seem at first, since presumably
if there were a clear answer to (a) that caused buggy clients to
upgrade, that would be the right long term answer. As a short term
answer, however, and in the absence of a clear answer to (a),
sending RCODE 3 responses will cause the buggy clients to shut up
and go away more quickly. As a result, I'm pretty sure that this
is the path ISPs will choose regardless of what we tell them unless
we give them a really good reason why they should do otherwise.
Given my opinions on (a), I don't believe that such a reason
exists, but if one does, best make it blindingly obvious.*
23Apr 05
Bernard Aboba
This text will be added to a new 'DNS Server Considerations' section:
"Mapping from IPv4 addresses to host names is conventionally done
by issuing DNS queries for names of the form,
"x.x.x.x.in-addr.arpa." When used for link-local addresses, which
have significance only on the local link, it is inappropriate to
send such DNS queries beyond the local link.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.
Recursive name servers MUST NOT allow these queries to
escape the local scope. Recursive name servers MAY reply
with RCODE 3, or they MAY silently discard the request.
By default, recursive name server implementations SHOULD be
configured to act as if they were authoritative for an
empty 254.169.in-addr.arpa zone and return RCODE 3 for any
such query. Implementations SHOULD allow this default to
be overridden. Returning an RCODE 3 is the correct default
setting because it reduces the query load but also because if
the site administrator has not set up the reverse tree
corresponding to IPv4 Link-Local addresses in use,
returning RCODE 3 is in fact the correct answer."
24 Apr 05
Rob Austein
Er, s/SHOULD/MUST/ here. Hard wiring this into a recursive name
server with no way to override it is probably not wise.
The revised proposal is below, with the changes in bold face:
This text will be added to a new 'DNS Server Considerations' section:
"Mapping from IPv4 addresses to host names is conventionally done
by issuing DNS queries for names of the form,
"x.x.x.x.in-addr.arpa." When used for link-local addresses, which
have significance only on the local link, it is inappropriate to
send such DNS queries beyond the local link.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.
Recursive name servers MUST NOT allow these queries to
escape the local scope. Recursive name servers MAY reply
with RCODE 3, or they MAY silently discard the request.
By default, recursive name server implementations *MUST* be
configured to act as if they were authoritative for an
empty 254.169.in-addr.arpa zone and return RCODE 3 for any
such query. Implementations *MUST* allow this default to
be overridden. Returning an RCODE 3 is the correct default
setting because it reduces the query load but also because if
the site administrator has not set up the reverse tree
corresponding to IPv4 Link-Local addresses in use,
returning RCODE 3 is in fact the correct answer."
Best regards,
Erik
._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k G u t t m a n - Sun Microsystems - cell: +49 162 790 1116
--Boundary_(ID_ipR+FRpu4pjXHUo6CVyn+w)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Folks,<br>
<br>
[This page should be viewed as HTML, sorry if this inconveniences you!]<br>
<br>
I support the text proposed by Bernard with the changes by Rob.<br>
<br>
- - -<br>
<br>
Let's see if we have closure on all items. Going back over the email
sent in the past weeks, I believe the points made are the following.
If I have left anything out or misrepresented the dialog, please reply
with a revised version of the table.<br>
<br>
<big><big>If anyone has any concern with the final suggested resolution
(24 Apr 05), please send email to the list by next Monday, May 1.</big></big><br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top"><b>Date<br>
</b></td>
<td valign="top"><b>Who<br>
</b></td>
<td valign="top"><b>Problem<br>
</b></td>
<td valign="top"><b>Suggested Resolution<br>
</b></td>
</tr>
<tr>
<td valign="top">05 Oct 04<br>
</td>
<td valign="top">RFC Editor<br>
</td>
<td valign="top">Starts 48 hour last call on RFC 3927 <br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">06 Oct 04<br>
</td>
<td valign="top">Stuart Cheshire<br>
</td>
<td valign="top">Several changes requested.<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">03 Mar 05<br>
</td>
<td valign="top">Authors, RFC Editor, post-WG<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">The requested changes were reviewed and the
resolution was agreed to by all parties.<br>
</td>
</tr>
<tr>
<td valign="top">15 Mar 05<br>
</td>
<td valign="top">Margaret Wasserman<br>
</td>
<td valign="top">Concern was raised due to related work in the
IPv6 WG related to reverse lookup of local addresses.<br>
</td>
<td valign="top">Bernard suggested a straw man resolution:<br>
<br>
<pre wrap="">Here is a strawman:
This text will be added to a new 'DNS Server Considerations' section:
"Reverse (address-to-name) queries for IPv4 Link-Local
addresses MUST NOT be sent to name servers for the global DNS.
The recommended way to avoid sending such queries to nameservers for
the global DNS is for recursive name server implementations to act as
if they were authoritative for an empty 254.169.in-addr.arpa zone and
return RCODE 3 for any such query. Implementations that choose this
strategy should allow it to be overridden, but returning an RCODE 3
response for such queries should be the default, both because this
will reduce the query load problem and also because, if the site
administrator has not set up the reverse tree corresponding to
IPv4 Link-Local addresses in use, returning RCODE 3 is in
fact the correct answer."
</pre>
</td>
</tr>
<tr>
<td valign="top">24 Mar 05<br>
</td>
<td valign="top">Stuart Cheshire<br>
</td>
<td valign="top">Counter proposal:<br>
<br>
<pre wrap="">The DNS experts are the one who have alerted us to the issue. While I
<span class="moz-txt-citetags">></span>agree there is probably room for debate as to "how big a problem this
<span class="moz-txt-citetags">></span>really is in practice", I doubt any one will argue that PTR queries
<span class="moz-txt-citetags">></span>for these addresses should be forwarded off link. Seems a no-brainer
<span class="moz-txt-citetags">></span>to just state that in the document. That is all that is being asked.
</pre>
<pre wrap=""><!---->
At the high level I agree that there is no point sending these PTR
queries off-link. Where I disagree is in the details, particularly in
caching servers returning authoritative NXDomain answers.
This is what I propose, and would support in the document:
Mapping from IPv4 addresses to host names is conventionally done
by issuing DNS queries for names of the form,
"x.x.x.x.in-addr.arpa." When used for link-local addresses, which
have significance only on the local link, it is inappropriate to
send such DNS queries beyond the local link.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.
DNS caching servers receiving queries from non-compliant clients
for names within the "254.169.in-addr.arpa." domain MUST silently
ignore them. A caching server MUST NOT attempt to complete such
queries on behalf of the client, and MUST NOT send any DNS
response back to the client.</pre>
<br>
</td>
<td valign="top">This leads to debate that has not yet been<br>
resolved. The individual problems and <br>
attempted resolutions are summarized <br>
below.<br>
<br>
The point of debate is whether recursive<br>
DNS servers MUST silently drop queries<br>
for reverse lookup of LL addressses <br>
or whether they should return error code 3.<br>
<br>
Stuart suggests that servers silently drop<br>
requests. Thomas and Dan suggest that<br>
returning an error would help with <br>
diagnosing failure conditions at the client<br>
and reduce time outs.<br>
</td>
</tr>
<tr>
<td valign="top">27 Mar 05<br>
</td>
<td valign="top">Rob Austein<br>
</td>
<td valign="top">
<pre wrap="">Stuart Cheshire wrote:
> The ONLY DIFFERENCE between what I'm saying here and what you're saying
<span class="moz-txt-citetags">> </span>is that I want the recursive name servers to provide this defense in a
<span class="moz-txt-citetags">> </span>form that encourages end-system devices to be fixed to not issue the
<span class="moz-txt-citetags">> </span>queries in the first place, rather than a form that encourages end-system
<span class="moz-txt-citetags">> </span>devices to continue with the bad behaviour forever.
</pre>
<pre wrap=""><!---->Rob Austein replied:
It was not at all clear to me from the earlier exchange that this was
the only point on which we disagreed, but if so, I'm glad to hear it.
We should probably take this one point to the zeroconf list, since
Bernard has started the discussion there, but, in brief, I see two
issues here:
a) Whether silently dropping bogons is more likely to cause buggy
clients to upgrade than supplying RCODE 3 answers. This is not
obvious to me. I would think that users would be about as likely
to figure out that something's broken from being told that names
don't exist as they would from having queries time out, but I'll
stipulate that this is a matter of opinion on which reasonable
people might disagree in the absence of empirical data.
b) <b>Which solution is easier on the recursive name servers. This is
slightly more complex than it might seem at first, since presumably
if there were a clear answer to (a) that caused buggy clients to
upgrade, that would be the right long term answer. As a short term
answer, however, and in the absence of a clear answer to (a),
sending RCODE 3 responses will cause the buggy clients to shut up
and go away more quickly. As a result, I'm pretty sure that this
is the path ISPs will choose regardless of what we tell them unless
we give them a really good reason why they should do otherwise.
Given my opinions on (a), I don't believe that such a reason
exists, but if one does, best make it blindingly obvious.</b>
</pre>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">23Apr 05<br>
</td>
<td valign="top">Bernard Aboba<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">
<pre wrap="">This text will be added to a new 'DNS Server Considerations' section:
"Mapping from IPv4 addresses to host names is conventionally done
by issuing DNS queries for names of the form,
"x.x.x.x.in-addr.arpa." When used for link-local addresses, which
have significance only on the local link, it is inappropriate to
send such DNS queries beyond the local link.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.
Recursive name servers MUST NOT allow these queries to
escape the local scope. Recursive name servers MAY reply
with RCODE 3, or they MAY silently discard the request.
By default, recursive name server implementations SHOULD be
configured to act as if they were authoritative for an
empty 254.169.in-addr.arpa zone and return RCODE 3 for any
such query. Implementations SHOULD allow this default to
be overridden. Returning an RCODE 3 is the correct default
setting because it reduces the query load but also because if
the site administrator has not set up the reverse tree
corresponding to IPv4 Link-Local addresses in use,
returning RCODE 3 is in fact the correct answer."
</pre>
</td>
</tr>
<tr>
<td valign="top">24 Apr 05<br>
</td>
<td valign="top">Rob Austein<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">
<pre wrap="">Er, s/SHOULD/MUST/ here. Hard wiring this into a recursive name
server with no way to override it is probably not wise.
The revised proposal is below, with the changes in bold face:
This text will be added to a new 'DNS Server Considerations' section:
"Mapping from IPv4 addresses to host names is conventionally done
by issuing DNS queries for names of the form,
"x.x.x.x.in-addr.arpa." When used for link-local addresses, which
have significance only on the local link, it is inappropriate to
send such DNS queries beyond the local link.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.
Recursive name servers MUST NOT allow these queries to
escape the local scope. Recursive name servers MAY reply
with RCODE 3, or they MAY silently discard the request.
By default, recursive name server implementations <b>MUST</b> be
configured to act as if they were authoritative for an
empty 254.169.in-addr.arpa zone and return RCODE 3 for any
such query. Implementations <b>MUST</b> allow this default to
be overridden. Returning an RCODE 3 is the correct default
setting because it reduces the query load but also because if
the site administrator has not set up the reverse tree
corresponding to IPv4 Link-Local addresses in use,
returning RCODE 3 is in fact the correct answer."
</pre>
</td>
</tr>
</tbody>
</table>
<br>
<br>
<br>
Best regards,<br>
<br>
Erik<br>
<pre class="moz-signature" cols="76">._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k G u t t m a n - Sun Microsystems - cell: +49 162 790 1116</pre>
</body>
</html>
--Boundary_(ID_ipR+FRpu4pjXHUo6CVyn+w)--