Subject: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

From: [email-masked]
Date: Thu, 15 Oct 2009 16:00:42 +0100

I've just submitted the following draft.

--8<--8<--
A new version of I-D, draft-bellis-dns-recursive-discovery-00.txt has been 
successfuly submitted by Ray Bellis and posted to the IETF repository.

Filename:                 draft-bellis-dns-recursive-discovery
Revision:                 00
Title:                   DNS Proxy Bypass by Recursive DNS Discovery and 
LOCAL.ARPA
Creation_date:            2009-10-15
WG ID:                    Independent Submission
Number_of_pages:        9

Abstract:
This document describes a method for a DNS client resolver to
discover the IP addresses of the upstream recursive DNS resolvers and
hence bypass the local DNS proxy.  It also directs IANA to reserve
the "LOCAL.ARPA" domain name and to create a registry for well known
sub-domains of that domain name, such sub-domains being reserved for
use within any network's administrative boundary.
--8<--8<--

The draft is available for download at 
http://tools.ietf.org/html/draft-bellis-dns-recursive-discovery-00

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "George Barwood" <[email-masked]>
Date: Sat, 17 Oct 2009 00:39:06 +0100

Ray,

I have read the draft, found no problems other than the missing security considerations
( I don't see any particular security considerations ), and fully support it.

Did you consider a "referral" model using NS records?

LOCAL.ARPA.    9000    NS    A.LOCAL.ARPA.
LOCAL.ARPA.    9000    NS    B.LOCAL.ARPA.

A.LOCAL.ARPA.    9000    A    1.2.3.4
B.LOCAL.ARPA.    9000    A    2.3.4.5

I think this may be cleaner, it allows multi-homed servers to be properly distinguished
( you shouldn't try an alternate address until other servers have been tried ), and
seems closer to the normal DNS representation of name servers.

A simplistic client can still just save all the A records, and ignore the names.

This may be significant if the glue types are extended in future to supply other link-local
parameters, for example the DNS transport protocols supported, or a link-local public key.
Although this is not a fully secure way to acquire a local public key, it does raise the bar for
an in-path attacker, and clients could warn users if a link-local public key changes.

I also note that using LOCALHOST, or a sub-domain of LOCALHOST, would avoid
non-local queries being sent by servers that are not aware of LOCAL.ARPA. Which
is the most appropriate domain to use I am unable to judge.

Regards,
George

----- Original Message ----- 
From: [email-masked] 
To: [email-masked] 
Sent: Thursday, October 15, 2009 4:00 PM
Subject: [DNSOP] Fw: New Version Notification fordraft-bellis-dns-recursive-discovery-00

--8<--8<-- 
A new version of I-D, draft-bellis-dns-recursive-discovery-00.txt has been successfuly submitted by Ray Bellis and posted to the IETF repository.

Filename:                  draft-bellis-dns-recursive-discovery
Revision:                  00
Title:                         DNS Proxy Bypass by Recursive DNS Discovery and LOCAL.ARPA
Creation_date:                  2009-10-15
WG ID:                           Independent Submission
Number_of_pages:        9

Abstract:

The draft is available for download at http://tools.ietf.org/html/draft-bellis-dns-recursive-discovery-00 

Ray 

--------------------------------------------------------------------------------

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: [email-masked]
Date: Sat, 17 Oct 2009 09:14:13 +0100

> I have read the draft, found no problems other than the missing 
> security considerations ( I don't see any particular security
> considerations ), and fully support it.

Thanks - and that's why the Security Considerations is "TODO" - we're not 
sure what they are yet.  The only significant risk we can think of is 
someone spoofing that initial seeding query, and thereafter intercepting 
all DNS requests. 

> I think this may be cleaner, it allows multi-homed servers to be 
> properly distinguished ( you shouldn't try an alternate address
> until other servers have been tried ), and seems closer to the
> normal DNS representation of name servers.

Resolvers require a list of A (or AAAA) records to send queries to.  Hence 
we use the RR type which represents just such a list.

> A simplistic client can still just save all the A records, and 

That would be harder to implement than simply asking for A records in the 
first place.

> This may be significant if the glue types are extended in future
> to supply other link-local parameters, for example the DNS transport
> protocols supported...

At this point any other transports are (with all due respect) entirely 
hypothetical so they are not considered here.
 
> I also note that using LOCALHOST, or a sub-domain of LOCALHOST,
> would avoid non-local queries being sent by servers that are not
> aware of LOCAL.ARPA

See RFC 2606:

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

Ray

---

From: Florian Weimer <[email-masked]>
Date: Tue, 20 Oct 2009 06:52:22 +0000

> I've just submitted the following draft.

This will work for a short time only because those proxies will likely
be changed to return their own address for DOMAIN.LOCAL.ARPA.

You cannot rely on a NXDOMAIN response for DOMAIN.LOCAL.ARPA when the
resolver does not support this protocol due to widespread DNS
poisoning.

I wholeheartedly support the creation of LOCAL.ARPA, though.  But you
should mention that mDNS MUST NOT be used for LOCAL.ARPA (so that some
people don't get funny ideas).

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: [email-masked]
Date: Tue, 20 Oct 2009 08:19:12 +0100

> be changed to return their own address for DOMAIN.LOCAL.ARPA.

The draft specifically prohibits this.  Of course vendors _do_ ignore 
RFCs, otherwise this draft wouldn't be necessary.  However we'd be in a 
good position to name and shame any vendor whose proxies intentionally 
serve LOCAL.ARPA in defiance of the standard.

> resolver does not support this protocol due to widespread DNS

Hmm - given the need to protect this query a nonce prefix may be a useful 
addition.  That requires more thought...

> people don't get funny ideas).

OK, I'll consult with Stuart on mDNS and it's interaction (or otherwise) 
with this.

thanks,

Ray

---

From: Alex Bligh <[email-masked]>
Date: Tue, 20 Oct 2009 11:19:01 +0100

Florian,

> be changed to return their own address for DOMAIN.LOCAL.ARPA.

I think you are presuming that such a proxy vendor is deliberately
setting out to break things. I don't think that's the case. Ignorance
is the main cause.

As per the draft, a proxy which implements a full recursive server
that correctly passes DNSSEC packets is permitted to return its own
address from DOMAIN.LOCAL.ARPA; the sort of proxies we see today
may not. Ray in his response to you correctly points out that companies
may choose to violate the draft (perhaps it could be more explicit
about the consequences of doing so); we have no IETF police force
and people can always violate drafts.

> resolver does not support this protocol due to widespread DNS

Could you amplify a bit on this one? I think what you are saying is
that recursive servers which do not support DOMAIN.LOCAL.ARPA
(and hence don't strip it out of any response to a recursive
query) can be subject to poisoning attacks which will result in
duff nameserver records being sent to clients that are aware
of the protocol.

I think that is indeed a security concern, and perhaps not
one that can be brushed aside with the response "but such
servers can have any DNS query made to them poisoned anyway".
May be we need to come up with a way for a server
to signal that it does indeed support DOMAIN.LOCAL.ARPA
(or perhaps LOCAL.ARPA) in a manner not reliant upon
poisonable records. For instance, the client could always
query with a given EDNS0 option set, which would be returned
to the client by the server; any response without this set
would indicate lack of support for {DOMAIN.,}LOCAL.APRA
and cause the response to be treated like NXDOMAIN. The
disadvantage here is that this would require a server s/w
change and a larger protocol change, whereas the current
protocol only requires a configuration change. I shall
think about this.

-- 
Alex Bligh

---

From: Florian Weimer <[email-masked]>
Date: Tue, 20 Oct 2009 10:53:49 +0000

> duff nameserver records being sent to clients that are aware

I was alluding to this:

; <<>> DiG 9.5.1-P3 <<>> @208.67.222.222 DOMAIN.LOCAL.ARPA
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44816
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;DOMAIN.LOCAL.ARPA.             IN      A

;; ANSWER SECTION:
DOMAIN.LOCAL.ARPA.      0       IN      A       67.215.65.132

;; Query time: 41 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Oct 20 13:12:32 2009
;; MSG SIZE  rcvd: 51

And 67.215.65.132 does not offer DNS service.

> servers can have any DNS query made to them poisoned anyway".

ARPA will soon be signed, so I don't think this is much to worry
about.  If the powers that be finally agree to make NXDOMAIN/NODATA
synthesis the default in the upcoming minor DNSSEC revision, this will
also help to cut down the number of requests.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Oct 2009 10:29:05 +1100

> also help to cut down the number of requests.

And LOCAL.ARPA would need to be a unsigned delegation.
 
> -- =
> Kriegsstra=DFe 100              tel: +49-721-96201-1
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Tue, 20 Oct 2009 19:38:19 -0400

> And LOCAL.ARPA would need to be a unsigned delegation.

Could you explain this? The draft under discussion specifies that  
LOCAL.ARPA is not to be delegated at all, so your sentence above  
confuses me.

Joe

---

From: [email-masked]
Date: Wed, 21 Oct 2009 00:47:16 +0000

> LOCAL.ARPA is not to be delegated at all, so your sentence above  

	Think ... kind of like RFC 1918 prefixes are not supposed to be 
	advertized.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Oct 2009 12:45:08 +1100

In message <[email-masked]>, Joe Abley writes
> LOCAL.ARPA is not to be delegated at all, so your sentence above  

For LOCAL.ARPA to be accepted you need a break in the DNSSEC trust
chain.  You can only break a trust chain at a delegation.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Oct 2009 06:37:53 +0000

* Mark Andrews:

> chain.

Mark, I din't think this is true given how the proposed protocol
works.  For a start, you often cannot fetch the DNSKEY RR for ARPA
before running the protocol.

---

From: [email-masked]
Date: Wed, 21 Oct 2009 08:32:49 +0100

> before running the protocol.

Indeed LOCAL.ARPA would need to be unsigned.  That needs to be added to 
the draft.

Since (as Bill points out) LOCAL.ARPA would be served much like RFC 1918 
space there's no way it could be signed and have the DS key present in the 
parent, because there will be numerous separate instances of LOCAL.ARPA. 

In any event the seeding query needs to be sent without the DO bit set, 
since (some) CPE proxies are known to interfere with that.

Ray

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Oct 2009 08:34:39 +0000

* Ray Bellis:

> Indeed LOCAL.ARPA would need to be unsigned.

Not really.  Why would it need to exist in the public tree at all?
All we need is agreement from both ICANN and IETF that LOCAL.ARPA is
reserved and not to be delegated in the official tree.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 21 Oct 2009 09:59:12 +0100

> reserved and not to be delegated in the official tree.

OK, let's try this one again. LOCAL.ARPA is not delegated at all.
It is unsigned.

Necessarily, ARPA. will have no records for LOCAL.ARPA (except
perhaps pointing at a sink). Each of the individual LOCAL.ARPA
instances run by recursive nameservers have different administrators.
Whilst it would be theoretically possible to sign them, this would
achieve no purpose as anyone operating a recursive nameserver would
need to sign them.

Moreover the queries into DOMAIN.LOCAL.ARPA are going to be made
in an environment where we suspect DNSSEC queries don't work, as
there is, ex hypothesi, possible a misbehaving proxy in the way.
Therefore, queries will likely be made with DO clear (that
should be in the draft too).

So there are two separate security risks: cache poisoning on the
recursive server (this needs addressing and I have some ideas),
and a theoretical Kaminsky style attack on the individual
non-DNSSEC queries to DOMAIN.LOCAL.ARPA. There are some obvious
mitigation strategies here (such as uRPF on customer facing edges
and not taking source IP addresses from critical server ranges
on other edges), but I'm not sure that ultimately this one needs
addressing. Firstly, it can only be used against individual
clients and requires some heuristic knowledge of when the query
is going to be made. Secondly, all you "win" is the ability
to spoof insecure queries. However, it would be possible to
avoid even this, e.g. with a nonce in the QNAME.

-- 
Alex Bligh

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Oct 2009 09:10:16 +0000

> OK, let's try this one again. LOCAL.ARPA is not delegated at all.

If it is not delegated, it will be signed (as Mark pointed out).

> Necessarily, ARPA. will have no records for LOCAL.ARPA

Then its non-existence will be signed.

> there is, ex hypothesi, possible a misbehaving proxy in the way.

Right.  (Otherwise, you wouldn't use class IN for this stuff.)

> non-DNSSEC queries to DOMAIN.LOCAL.ARPA. 

Don't worry too much about spoofing from off-path attackers.  ISPs
have plenty of means to prevent it (granted, for IPv4 directly over
Ethernet, there's no standard way of doing things which conserves
address space, but that's a different issue).

As I've tried to explain, spoofing by the resolver operator itself is
the relevant issue here.  It breaks the proposed protocol.  Please
tell me how I can explain this in a better way---perhaps I shouldn't
say "spoofing" but "DNS rewriting", "NXDOMAIN redirection",
"Sitefinder", "online help page", or something else, but it's really
spoofing.

Note that this problem will not go away when you bring LOCAL.ARPA or
DOMAIN.LOCAL.ARPA into existence.  People say "NXDOMAIN redirection"
but they really mean "arbitrary DNS manipulation".  It doesn't stop at
NODATA response or the second level of the tree.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 21 Oct 2009 10:50:28 +0100

Florian,

> Then its non-existence will be signed.

Sure, on the .ARPA nameservers, but these will (a) never be
queried when there is a DOMAIN.LOCAL.ARPA-supporting nameserver,
and (b) the signature of its non-existence will not be relevant
to a DO clear query anyway, will it?

Clearly a validating recursive nameserver not supporting
DOMAIN.LOCAL.ARPA may get a signed denial of existence for
LOCAL.ARPA, but that's just fine. LOCAL.ARPA doesn't
exist "there".

> address space, but that's a different issue).

I'm not actually worried about it, I just explained it for completeness.

> "Sitefinder", "online help page", or something else, but it's really

Ah. I think I now understand what you mean. Well yes they can do that, but
they could do it anyway. The resolving server operator can say "please
query this spoofing/sitefinder/whatever" resolver (let's call it
$evilserver) instead. But it has exactly the same effect as if they supply
$evilserver's IP address by DHCP / over PPPoA to the CPE gateway and the
CPE gateway uses that. Indeed the very server which is responding to
LOCAL.ARPA queries may be $evilserver. So all the bad things you describe
can happen at the moment, and this draft won't fix them. We are solely
changing:

      Client Stack -----> Proxy ----> $evilserver
   to
      Client Stack -----------------> $evilserver

and

      Client Stack -----> Proxy ----> $goodserver
   to
      Client Stack -----------------> $goodserver

> NODATA response or the second level of the tree.

Indeed, and it is not intended to. The draft is simply intended to
bypass the CPE proxy. The only way in which it helps with preventing
arbitrary DNS manipulation is that the technology we already have
to stop that (DNSSEC) has implementation issues due to poorly
performing proxies. Bypass them, and DNSSEC becomes easier to deploy,
in which case we have a weapon against DNS manipulation (I appreciate
there are arguments that this weapon is less than perfect, but it
is currently the best weapon we have).

-- 
Alex Bligh

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Oct 2009 09:55:06 +0000

> LOCAL.ARPA, but that's just fine. LOCAL.ARPA doesn't

Great, then we are in agreement actually.

> they could do it anyway.

There's an additional twist: If I have got a client device (not DNS
proxy) which supports the proposed protocol, it will not work when I
connect it to a network which uses a resolver that performs this type
of spoofing, unless the spoofing resolver has specific support for
this protocol.

It's not "someone could do evil things and make it break", but
"someone already does (perhaps evil) things, and it breaks".

---

From: Alex Bligh <[email-masked]>
Date: Wed, 21 Oct 2009 11:15:32 +0100

--On 21 October 2009 09:55:06 +0000 Florian Weimer <[email-masked]> wrote:

>> Ah. I think I now understand what you mean. Well yes they can do that,
>> but they could do it anyway.
>

Right, so if a spoofing resolver which does NXDOMAIN redirection but does
not support this protocol (and hence returns bogus A records for
domain.local.arpa along with everything else) receives a query from a
client stack which supports the protocol, it could confuse the client stack
by returning A records which don't support DNS query (e.g. a "sitefinder
site").

That's easily remedied, and would be a good addition to the protocol. The
first thing the client does is send a query to the candidate new nameserver
(possibly with "Christmas tree" options, e.g. DO set and so forth), and
check the reply looks sensible. If not, it doesn't use it. That way it
doesn't use any server that makes things worse. The query could be an NS
query for ".", but perhaps better a fixed records in .ARPA that does exist
& is signed.

-- 
Alex Bligh

---

From: [email-masked]
Date: Wed, 21 Oct 2009 11:24:08 +0100

> query for ".", but perhaps better a fixed records in .ARPA that does 
exist

I'm in meetings today so can't reply fully.

We could simply propose NXDOMAIN.LOCAL.ARPA. as well.

If the answer for that comes back the same as for DOMAIN.LOCAL.ARPA, we 
know we've got an "evil" resolver. :)

Ray

---

From: Alex Bligh <[email-masked]>
Date: Wed, 21 Oct 2009 12:33:26 +0100

> know we've got an "evil" resolver. :)

True - and that has obvious benefits. However, testing the new
nameservers work before installing them is probably not a bad idea,
just in case the proxy tries to be "helpful" by transparently intercepting
DNS packets not addressed to it (as a small minority of the proxies
you tested did).

-- 
Alex Bligh

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Oct 2009 06:39:54 -0700

Hi,

> reserved and not to be delegated in the official tree.

Entries in the ARPA tree are (now) only created by the IAB or a protocol action. ICANN merely implements what we're told. I'd suggest an IANA considerations section that simply said that "LOCAL.ARPA" is reserved and must not be delegated.

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Wed, 21 Oct 2009 10:44:45 -0400

On 2009-10-21, at 09:39, David Conrad wrote:

> Entries in the ARPA tree are (now) only created by the IAB or a  
> protocol action. ICANN merely implements what we're told. I'd  
> suggest an IANA considerations section that simply said that  
> "LOCAL.ARPA" is reserved and must not be delegated.

This is already in the draft. It makes use of the registry proposed by  
Olafur and me for use by SINK.ARPA.

Note that the draft specifies that LOCAL.ARPA *not* be delegated, not  
that any change be made to the ARPA zone. The document further  
requests approval from the IAB in section 9. All procedural bases seem  
well-covered here (to the extent that the SINK.ARPA proposal has legs).

Joe

...

8.  IANA Considerations

    This document directs the IANA to add the following record to the
    ARPA Reserved Names Registry [I-D.jabley-sink-arpa]:

    +------------+----------------------+--------- 
+---------------------+
    | Name       | Purpose              | RRTypes |  
Reference           |
    +------------+----------------------+--------- 
+---------------------+
    | LOCAL.ARPA | Locally administered | NONE    | This  
document       |
    |            | infrastructure       |         | (RFCXXXX)  S.  
3     |
    +------------+----------------------+--------- 
+---------------------+

...

9.  IAB Considerations

    The addition of "LOCAL.ARPA" to the ARPA Reserved Names Registry
    requires IAB approval.

...

---

From: [email-masked]
Date: Thu, 22 Oct 2009 20:35:26 +0000

> parent, because there will be numerous separate instances of LOCAL.ARPA. 

	well...  there are these cases where an island of trust
	gets its DS keys treated as a SEP and folks configure them
	anyway.

	and I'm sure we can get some kind folks to ensure that no one
	-EVER- shares a trusted keys file with others.

	just saying.

--bill