Subject: Re: [dnsop] RFC: "AS112 work basket"

From: Dean Anderson <[email-masked]>
Date: Mon, 2 Oct 2006 11:55:41 -0400 (EDT)

On Sat, 30 Sep 2006, Mark Andrews wrote:
> > 
> > The better approach is for the WG to recommend to the in-addr.arpa
> > maintainer to put in delegations for 168.192.in-addr.arpa et al to be
> > delegated to 127.0.0.1. These delegation records should have the maximum
> > TTL.
> 
> 	Because it also breaks responses to queries from nameservers that
> 	are NOT using these addresses.

How is that? I don't think it breaks anything: If nameservers (the
users) _really_ don't use those addresses, then they won't be making
those queries.  But if they do make those queries (for which they aren't
properly configured), then they should EXPECT to get an error.  Indeed,
they SHOULD get an error.

By contrast, AS112 silently gives a "wrong" answer, with no "error". The
answer is wrong because an answer is given to an unanswerable query.  
This is bad since it prevents the nameserver operator from learning
about the misconfiguration.

> > This approach has two beneficial effects that AS112 doesn't 
> > offer: 
> > 
> > 1) The nameserver operator with the misconfigured nameserver will begin
> > getting "recursion to self" errors, which will prompt corrective action.
> > 
> > 2) The delegation records will be cached on the local nameserver,
> > reducing unnecessary traffic from the misconfigured nameserver.  
> 
> 	Because it only works when you get responses *back*.  A
> 	large amout of this traffic is non-repliable by the roots.

The _delegations_ are reply-able. There are currently delegations to
(e.g. 168.192.in-addr.arpa):

168.192.in-addr.arpa.   300     IN      NS      blackhole-2.iana.org.
168.192.in-addr.arpa.   300     IN      NS      blackhole-1.iana.org.

This could be changed to give an address of 127.0.0.1.  And these
records are cached.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Oct 2006 10:11:46 +1000

> those queries.

	I can think of a number of ways a lookup for the reverse
	of a RFC 1918 address could be made when you are not using
	RFC 1918 addresses.

> But if they do make those queries (for which they aren't

	They do get a error: Name Error.
 
> about the misconfiguration.

	RFC 1918 addresses are ambigious, not "not answerable".
	The correct answer is location sensitive.  If you are on
	the Internet and not using RFC 1918 addresses then the
	correct answer is Name Error.  If your site is using RFC
	1918 addresses and you havn't configured a PTR then the
	correct answer still is Name Error.

	This is no different that if there wasn't a PTR record for
	the public IP address I'm currently using.

> This could be changed to give an address of 127.0.0.1.  And these

	And you totally missed my point.  Fix the default configuration
	in nameservers using RFC 1918 address and the queries don't
	leak out.  They don't go to the roots regardless of whether
	the addresses are translated or not.
 
	The intent is to stop the queries leaking.

--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Thu, 5 Oct 2006 11:26:05 -0400 (EDT)

> 	of a RFC 1918 address could be made when you are not using

Then, it seems that one should _always_ be configured to respond for
such queries, whether they are assigned or not. This contradicts your
earlier assertion that there exist people who do not use those
addresses.  Not assigning addresses is not the same as not _using_ those 
such addresses.

> 	They do get a error: Name Error.

The _user_ gets NX domain on the reverse lookup.  Such errors are user
errors. The server operator gets nothing, unless the user wonders why he
gets NX domain on the reverse lookup and then contacts the server
operator.  But most dns clients don't report these errors to the user in
any case.  So NXDomain does nothing to alert anyone, (end user or server
operator) to the problem of misconfiguration of their server.

> 	The correct answer is location sensitive.  

I know this.  It is strange how you can agree that this is "not
answerable" but still posit answers.

>      If you are on
> 	correct answer is Name Error.  

No, that an answer, and isn't a correct answer. Its rather like getting
MAX_INT on division by zero. When there is no answer, the computation
must stop, this is why your program gets a exception and core dumps on
division by zero. Likewise, there is _no_answer_ to this query outside
of the locality.

>  If your site is using RFC

No, that is an answer, and isn't a correct answer, either. It is more
reasonable, but still an answer to an an unanswerable non-local query.  
The correct answer might be a local wildcard that wasn't returned
because a DNS cache server wasn't properly configured.  There is no
correct answer to this query outside of the locality.

> 	the public IP address I'm currently using.

But it is different, since one might have configured a PTR record that
just isn't found due to misconfiguration of the caching server.

> 	leak out.  

I didn't miss your point. I agree that fixing the configuration is the
right solution. But to get this to happen, you have to give server
operators some indication that there is a problem with their server that
needs to be fixed. The "recursion to self" gives them 'the clue they
need to solve this mystery' (to quote the Jedi Master;)

And it also removes the traffic from the roots/in-addr.arpa servers.

> They don't go to the roots regardless of whether

In-addr.arpa is (or used to be)  hosted by a number of root servers.  
It was the root operators who complained of this unnecessary traffic.
The idea of AS112 was to draw this traffic away from the
roots/in-addr.arpa servers.

> 	The intent is to stop the queries leaking.

Right, almost. So, do you agree at least that giving blackhole-1 and
blackhole-2.iana.org IP address 127.0.0.1 mitigates leaking to the exact
same extent as AS112 mitigates this leaking?

And do you agree that a log entry of "recursion to self" is more likely
to be noticed by server administrators than no log entry and an innocent
looking but possibly unexpected NXDomain response?

Thanks,

		--Dean

.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 06 Oct 2006 23:15:46 -0400

> division by zero. Likewise, there is _no_answer_ to this query outside
I disagree. There's no such thing as "no answer" in any given DNS 
context. The question was asked in the Internet context "what does 
192.168.x.x [for example] reverse-resolve to"? The *correct* answer is 
that there is no reverse record for 192.168.x.x *on*the*Internet*. That 
seems quite unambiguous to me, perhaps -- I dare to say -- irrefutable. 
NXDOMAIN denotes the absence of a particular name from a particular 
context. It seems the correct response here.

The user's mistake, of course, is not that they asked the wrong 
question, but that they asked it in the wrong context. The user will 
notice that, eventually, and the responsible DNS administrator will fix 
it. It's true that users and administrators sometimes don't co-ordinate 
with each other very well, and I appreciate your attempt to "fast track" 
such problems directly to those perceived as most trained/equipped to be 
able to fix them, but the chronic user/administrator 
organizational/communication problem is not something that IETF can 
really fix through standards and/or BCPs.
> looking but possibly unexpected NXDomain response?
But it might not even manifest as "recursion to self". There is no 
requirement AFAIK that resolvers listen on 127.0.0.1, so these queries 
may end up triggering unnecessary timeout/retry cycles. Or are you 
assuming that the resolver will recognize 127.0.0.1 as "special"?

Personally, I don't think we should be subverting the resolution process 
just to get things "noticed". That's a slippery slope that could be used 
to justify all manner of counter-intuitive and/or unexpected behaviors, 
and we shouldn't be condoning, must less recommending it.

- Kevin

P.S. It's a pity we can't just create a BADCONTEXT RCODE out of thin air...

.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 7 Oct 2006 16:04:47 -0400 (EDT)

On Fri, 6 Oct 2006, Kevin Darcy wrote:

> question, but that they asked it in the wrong context. 

The 'user' made no mistake whatsoever. The mistake is in the DNS
cache/recursor configuration. The user usually has no control over this.

> > And do you agree that a log entry of "recursion to self" is more
> > likely to be noticed by server administrators than no log entry and
> > an innocent looking but possibly unexpected NXDomain response?
> >   

Umm, yes: the IP Address 127.0.0.1 is special.  The
resolver(recursor/cache) has nothing to do with the recognition of these
addresses as "special". See RFC 3330 and RFC 1700 page 5.

So, yes, a recursive query to 127.0.0.1 it will always manifest as
recursion to self.

		--Dean

.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 09 Oct 2006 22:18:28 -0400

> cache/recursor configuration. The user usually has no control over this.
Regardless of one's particular theory of blame, the user is asking 
something in the wrong context. That's a "mistake".

But my main point was to dispute your assertion that there is "no 
answer" to the question. In any given context, there is an answer, and 
in the Internet context the answer is Name Error aka NXDOMAIN. That is 
the correct response, in that context. This is DNS, with a definite and 
finite namespace, which is designed to always be able to give a 
definitive answer to a query/question, not some gaggle of Phil 101 
students sitting around in a coffee klatsch pondering some of the 
Question of the Ages like "what is the meaning of life?" or "can the 
existence of <deity> be proven or disproven?". Some questions have no 
answers (at least no answers that are provable and/or universally 
accepted); DNS queries don't fall into that category of questions however.
> addresses as "special". 
I think you missed my point. Unless the resolver makes a special case 
for 127.0.0.1, then delegating a zone there when there is no nameserver 
listening on the address runs the risk of causing unnecessary 
timeouts/retries. That would be a Bad Idea, in my estimation. The 
general operational rule, and a good example to set, is you don't 
delegate somewhere unless you have the permission of the delegatee. 
Clearly it's not practical to get the permission of everyone with a 
127.0.0.1 address configured on their device.
> See RFC 3330 and RFC 1700 page 5.
>
But is it guaranteed to manifest *in*logs*? AFAIK, there is no standard 
or BCP mandating a particular level of logging for "recursion to self", 
and I don't believe BIND or any other popular resolver implementation 
gives special logging priority to "recursion to self". So your purported 
benefit of making the misconfiguration more "noticeable" is far from 
guaranteed, yet at the same time it runs the risk of wasting resources 
and/or setting a bad example, as mentioned above. Significant risk, low 
probability of benefit. This is why I disagree with your proposal.

- Kevin

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 10 Oct 2006 15:32:56 -0400 (EDT)

> something in the wrong context. That's a "mistake".

The user made the request in the local context. That isn't wrong by any
stretch of the imagination.  The user didn't ask a wrong question; Its a
right question that you want to answer globaly with a wrong answer.  
Their local recursor/cache is misconfigured. This misconfiguration 
resulted in the query being sent to the wrong (global) server.

> in the Internet context the answer is Name Error aka NXDOMAIN. 

Unfortunately, this isn't correct for the reasons I've already given
previously. Such a query is _always_ the result of a misconfiguration,
so there is not proper query in the internet context. To have a proper
query, you need a context where that query is proper and is not the
result of misconfiguration.  Merely asserting the contrary doesn't
advance your argument.

> 127.0.0.1 address configured on their device.

Timeouts can only occur as a result of misconfiguration by the local
server administrator.  I see no reason to be concerned. In such a case,
the timeout is another positive clue that the dns cache is
misconfigured.

"Permission for delegation to self (127.0.0.1) of _local_ address space,
when misconfigured"?????  This doesn't seem to be a valid point on its
face. However, IANA has authority to delegate as it finds useful, so
your point is moot.  One cannot claim that IANA doesn't have permission
to do this, nor that DNSOP doesn't have permission to make a
recommendation to IANA regarding DNS Operations.

> But is it guaranteed to manifest *in*logs*? 

You keep increasing the bar.  "guaranteed to manifest *in*logs*" is not
the measure of usefulness.  My proposal is useful because, unlike AS112,
it _can_be_ noticed in logs.  

I just checked, and DJBDNS does log this as a 'servfail'

@40000000452be5861f82ac5c.s:@40000000452be56a1614afe4 query 4334914 
c60388a0:db60:96cf 1 asdf.selftest.av8.net.
@40000000452be5861f82ac5c.s:@40000000452be56a16193424 cached ns 
selftest.av8.net. selftest1.av8.net.
@40000000452be5861f82ac5c.s:@40000000452be56a161b5ed4 cached 1 
selftest1.av8.net.
@40000000452be5861f82ac5c.s:@40000000452be56a161e0684 tx 0 1 
asdf.selftest.av8.net. selftest.av8.net. 7f000001
@40000000452be5861f82ac5c.s:@40000000452be570179f18a4 servfail 
asdf.selftest.av8.net. input/output error
@40000000452be5861f82ac5c.s:@40000000452be575183810cc servfail 
asdf.selftest.av8.net. input/output error

> AFAIK, there is no standard 
> gives special logging priority to "recursion to self". 

Now you also want "special logging priority"????  Please.

> So your purported benefit of making the misconfiguration more
> "noticeable" is far from guaranteed, yet at the same time it runs the
> risk of wasting resources and/or setting a bad example, as mentioned
> above. 

Making a misconfiguration noticable doesn't have to be guaranteed in
order to be useful. It just has to be _more_noticeable than the
alternative, or just notice_able_. However, the AS112 method guarantees
that it won't ever be noticed

Bad example????  Delegation of misconfigured private address space to
127.0.0.1 is a _good_ example of why the localhost address space exists.

> Significant risk, low probability of benefit. This is why I
> disagree with your proposal.

What risk?  You haven't explained any risk or harm.

The benefit is _at_worst_ equal to, but nearly always better than, that
offered by AS112:

  1) Unnecessary traffic is kept local. (better than AS112) 

  2) Server admins have chance to get clue of misconfiguration (better
than AS112)

		--Dean

.