Subject: [DNSOP] DNS privacy and AS 112: the case of home.arpa

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Dec 2017 10:00:51 +0100

During the discussions about draft-bortzmeyer-dname-root or about
draft-wkumari-dnsop-internal, there have been many remarks about the
risk for privacy if we delegate things to AS 112: unlike the root (or
.arpa), AS 112 is managed by many different people we don't know and
cannot know. So, leaked requests are more at risk of surveillance with
AS 112.

But I notice that draft-ietf-homenet-dot, currently in the RFC Editor
queue, delegates home.arpa to AS 112, in its section 7 (unless I'm
wrong, it will be the first delegation to the new AS 112, the one with
DNAME, described in RFC 7535).

Does it mean the privacy problem is solved? Or simply overlooked? Can
we delegate RFC 6761 special-use domains such as .internal to AS 112?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Dec 2017 01:10:20 -0800

Stephane Bortzmeyer wrote:
...
> we delegate RFC 6761 special-use domains such as .internal to AS 112?

any AS112 operator can tell you that the world doesn't care about 
privacy, based on the amount of organizationally sensitive information 
that's leaked in queries for PTR in RFC 1918 address blocks. so, privacy 
was never my concern.

rather, AS112 has no authoritative operator registry. we don't know who 
is running these servers, and we have no way to assure that they hear a 
request that they add more secondary DNS zones to such servers. so if we 
delegate more zones that way, there will be a lot of SERVFAIL except for 
servers who send REFUSED. either way we have to consider the matter.

i think as long as we keep the traffic away from the ARPA and root 
servers, we should not care what response is received -- should be 
NXDOMAIN but could be pretty much anything. ideally we'd sign all of 
these zones with DNSSEC and put DS RR's into the delegations, to assure 
that poison wasn't getting believed by modern validating resolvers.

but we should concern ourselves with the question: did the AS112 
operators realize that we'd be adding zones over time, and will they see 
the new RFC and/or announcements here/elsewhere and know to update their 
configs? and will any of them consider this an imposition?

-- 
P Vixie

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Dec 2017 10:18:00 +0100

On Mon, Dec 11, 2017 at 01:10:20AM -0800,
 Paul Vixie <[email-masked]> wrote 
 a message of 31 lines which said:

> we have no way to assure that they hear a request that they add more
> secondary DNS zones to such servers. so if we delegate more zones
> that way, there will be a lot of SERVFAIL except for servers who
> send REFUSED. either way we have to consider the matter.

This problem was solved a long time ago by RFC 7535 (the new AS 112).

> but we should concern ourselves with the question:

No. Problem solved (check with sink.bortzmeyer.fr, which is delegated
to the unspecting operators of AS 112 nodes).

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Dec 2017 01:26:27 -0800

Stephane Bortzmeyer wrote:
>   Paul Vixie<[email-masked]>  wrote

ok.

-- 
P Vixie

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Dec 2017 11:17:35 -0500

Hi Stéphane,

> This problem was solved a long time ago by RFC 7535 (the new AS 112).

Note though that the homenet document specifically requests a delegation.

IANA are currently working through their process and trying to get AS112 operators to add the home.arpa zone, to avoid it being lame. This is apparently a good first thing to try because the idea of adding a DNAME record to the ARPA zone is scary and expected to receive push-back from root server operators.

(I may be putting words into Kim's mouth by abbreviating the situation that way, but my point is that the IANA team are aware of the disconnect between the likely-lame delegation to AS112 vs. the approach this working group documented in 7535 and are doing their best).

There is some related mail on the as112-ops list hosted at OARC. I think you need to subscribe to see the archive, so no deep link.

https://lists.dns-oarc.net/mailman/listinfo/as112-ops

Joe

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Dec 2017 09:40:58 +1100

You don’t add the DNAME to the ARPA domain because it does not add the insecure delegation that is REQUIRED.  You add the DNAME to the HOME.ARPA domain if you really want to redirect the traffic.  For some reason IANA wants to make this more complicated than it needs to be.  You don’t need to contact the AS112 server operators (a impossible task).  You just contact the existing ARPA server operators to install HOME.ARPA on those servers.  Add each NS as the operator say that their servers are reconfigured to support HOME.ARPA.

This is what I would end up with.

HOME.ARPA. SOA	A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 1800 900 604800 86400
HOME.ARPA.	NS	A.ROOT-SERVERS.NET.
HOME.ARPA.	NS	B.ROOT-SERVERS.NET.
HOME.ARPA.	NS	C.ROOT-SERVERS.NET.
HOME.ARPA.	NS	D.ROOT-SERVERS.NET.
HOME.ARPA.	NS	E.ROOT-SERVERS.NET.
HOME.ARPA.	NS	F.ROOT-SERVERS.NET.
HOME.ARPA.	NS	G.ROOT-SERVERS.NET.
HOME.ARPA.	NS	H.ROOT-SERVERS.NET.
HOME.ARPA.	NS	I.ROOT-SERVERS.NET.
HOME.ARPA.	NS	K.ROOT-SERVERS.NET.
HOME.ARPA.	NS	L.ROOT-SERVERS.NET.
HOME.ARPA.	NS	M.ROOT-SERVERS.NET.
HOME.ARPA.  DNAME EMPTY.AS112.ARPA.

Mark

> On 12 Dec 2017, at 3:17 am, Joe Abley <[email-masked]> wrote:
> 
> Hi Stéphane,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Kim Davies <[email-masked]>
Date: Mon, 11 Dec 2017 15:16:46 -0800

Hi Mark,

> HOME.ARPA.	NS	A.ROOT-SERVERS.NET.
..
> HOME.ARPA.  DNAME EMPTY.AS112.ARPA.

It is unclear to me how this avoids having root servers process DNAME
records. Given the process of consultation, coordination and testing
support for DNAME records in the root servers (or relocating the .arpa
authorities) is likely to take longer than is desirable to have home.arpa
insecurely delegated, the delegation to AS112 was considered as the best
short-term approach even if it is not without its own difficulties.

kim

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Dec 2017 10:46:27 +1100

Firstly they are HOME.ARPA servers.  Just because they are the same physical servers it doesn’t mean that policy for the root zone content has to apply to other zones on that server.  Maintaining that distinction is important.  

Secondly a otherwise empty zone on these servers will fulfil the requirements to provide a insecure delegation.  Just drop the DNAME from the zone contents below.  All the servers involved can serve SOA and NS records and return NXDOMAIN for names under HOME.ARPA.

If you need to delegate to a different set of servers create a seperate constellation of servers that you control directly or by contract.  Trying to re-use AS112 servers will never work reliably as you don’t have agreements with *all* the operators.  This also applies to the operators of EMPTY.AS112.ARPA.

As for DNAME, that is a requirement of DNSSEC which, in theory, all the root servers support fully.

Mark

> On 12 Dec 2017, at 10:16 am, Kim Davies <[email-masked]> wrote:
> 
> Hi Mark,
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Dec 2017 19:50:29 -0500

> Note though that the homenet document specifically requests a delegation.

Please do not read more into the document than was intended.   What Mark is saying looks to me like an accurate representation of what we intended.   The goal is simply for it to be the case that there is not an unsigned delegation for home.arpa, which means that it has to point _somewhere_.   I am a bit frustrated to hear that this is turning into a substantial amount of effort.   It should be extremely simple.   There is no wrong answer for what the delegation looks like other than "signed."

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Dec 2017 11:29:02 +0100

On Mon, Dec 11, 2017 at 03:16:46PM -0800,
 Kim Davies <[email-masked]> wrote 
 a message of 22 lines which said:

> the delegation to AS112 was considered as the best short-term
> approach even if it is not without its own difficulties.

Interesting information, thanks.

But the original question was about privacy. Was it considered or do
people in charge felt it was, as Paul Vixie mentioned, a false problem
here?

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Dec 2017 16:46:00 -0500

> Please do not read more into the document than was intended.   What Mark is saying looks to me like an accurate representation of what we intended.   The goal is simply for it to be the case that t…

So it's fine if the delegation is secure (which is I presume what you mean by signed) but lame?

The document actually specifies quite clearly that the delegation "MUST NOT include a DS record" which seems to be different from what you are saying. It also specifies that the delegation "MUST point to one or more black hole servers", which is pretty vague language following a MUST.

I appreciate that the intention of homenet may well have been clear, but the text in section 7 is definitely not clear. I think actually it would have been reasonable for IANA to send it back as ambiguous before it got to the RFC Editor queue.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Dec 2017 09:09:12 +1100

Section 7 says:

"In order to be fully functional, there must be a delegation of 'home.arpa' in the '.arpa' zone [RFC3172]. This delegation MUST NOT be signed, MUST NOT include a DS record, and MUST point to one or more black hole servers, for example BLACKHOLE-1.IANA.ORG and BLACKHOLE-2.IANA.ORG. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa' on a homenet name server."

Thats a INSECURE DELEGATION and machines that return NXDOMAIN for *.HOME.ARPA.   Note it says “for example”.  The names of the servers the zone is delegated to are NOT proscribed there, just the functionality.

RFC 6303 has similar requirements and IANA was able to co-ordinate those delegation.

"As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones.  This will allow DNSSEC validation to succeed for queries in these spaces despite no t being answered from the delegated servers.”

Mark

> On 14 Dec 2017, at 8:46 am, Joe Abley <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Dec 2017 17:14:54 -0500

> The document actually specifies quite clearly that the delegation "MUST NOT include a DS record" which seems to be different from what you are saying. It also specifies that the delegation "MUST po…

I second-guessed myself on the double negative in the previous message.   What I meant, and what I believe the document clearly says, is that there must be a delegation, and it must not be signed.   The point of this is to avoid either a secure denial of existence (the status quo) or a secure delegation.   Either of these would completely prevent home.arpa from working for a validating stub.

> I appreciate that the intention of homenet may well have been clear, but the text in section 7 is definitely not clear. I think actually it would have been reasonable for IANA to send it back as am…

Can you point to the actual ambiguity?   The reason we said "one or more black hole servers" was to leave it up to the operator of .arpa to decide which black hole servers and how many of them.   That was a deliberate choice, not an omission.

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Dec 2017 19:31:22 -0500

Hi Ted,

> On Dec 13, 2017, at 17:14, Ted Lemon <[email-masked]> wrote:
> 

The ambiguity is (for example) that "point to" is not a well-defined phrase, given that we have two documented ways of doing this in the AS112 project, and neither is "black hole server" which from the examples seems it refers to servers made available from the AS112 project, but which examples surely are non-normative.

This no doubt sounds pedantic to many, but I think (a) that a certain precision is warranted in directions to the IANA and (b) given that the obvious interpretation is not possible to implement accurately (the problems with new delegations to the original AS112 servers having been well documented) ambiguity is in fact *required* in order for anything to happen here.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Dec 2017 19:40:27 -0500

Hi Mark,

> On Dec 13, 2017, at 17:09, Mark Andrews <[email-masked]> wrote:
> 
> Section 7 says:

Yes, I know. I read it.

> RFC 6303 has similar requirements and IANA was able to co-ordinate those delegation.

Apart from the zones originally delegated to the AS112 project, I couldn't find a zone specified in 6303 that is delegated at all, actually.

Admittedly I didn't check all of them (I got bored after 0.in-addr.arpa, 127.in-addr.arpa, 2.0.192.in-addr.arpa and d.f.ip6.arpa). Here's an example:

monster:~]% dig @b.in-addr-servers.arpa 0.in-addr.arpa soa +norec +dnssec

; <<>> DiG 9.11.2 <<>> @b.in-addr-servers.arpa 0.in-addr.arpa soa +norec +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64980
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;0.in-addr.arpa.                        IN      SOA

;; AUTHORITY SECTION:
in-addr.arpa.           3600    IN      NSEC    1.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY
in-addr.arpa.           3600    IN      RRSIG   NSEC 8 2 3600 20171228213500 20171208080001 51846 in-addr.arpa. D167CxX3WV8Cygq3JHJ8Ik4VUo5qGbEqxGq68vyil2QMhf9O7DjyU3sn q3S9kR+TJ7yQJPsfzy6Qqygft2Jnr0pujDspruYyKcFfx5WbO2X7pTxQ zFSjjHspZPCJ5ZVNoML/3aFYcqvBeYZWViZB8zCuyYZWF6YXtDppXukz 3GQ=
in-addr.arpa.           3600    IN      SOA     b.in-addr-servers.arpa. nstld.iana.org. 2017102477 1800 900 604800 3600
in-addr.arpa.           3600    IN      RRSIG   SOA 8 2 3600 20171231104329 20171210060001 51846 in-addr.arpa. a7/wJ7RcUM9MOV3M0+0i9MUgOF4Yw6VqUIuR7ItN70CuM8qoCYGi+0/F bRiiHPeRFgFD92Shgb7pwRsM2lYh53jheWAZSOg8wOdNMaF+eiEolErv wpBuDoZM/m1mlAZ26BiN2BKDDh22AXj/76KA+pgIa+J3y2kQHYsNKEmB pvg=

;; Query time: 22 msec
;; SERVER: 2001:500:87::87#53(2001:500:87::87)
;; WHEN: Thu Dec 14 00:39:19 UTC 2017
;; MSG SIZE  rcvd: 492

[monster:~]% 

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Dec 2017 12:19:10 +1100

Looks like we need to open a ticket for those.  But the ones people actually have internal zones in are correct.  Check the RFC 1918 delegations.  I know these started out being delegated to blackhole servers before the parent zones were signed by this isn’t rocket science.

[rock:bin/tests/system] marka% dig 10.in-addr.arpa @f.in-addr-servers.arpa +dnssec

; <<>> DiG 9.12.0rc1+hotspot+add-prefetch+marka <<>> 10.in-addr.arpa @f.in-addr-servers.arpa +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15498
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 1a755958649b4ee4edf6fe055a31cb4dc97ce57a3c818987 (good)
;; QUESTION SECTION:
;10.in-addr.arpa.		IN	A

;; AUTHORITY SECTION:
10.in-addr.arpa.	86400	IN	NS	blackhole-2.iana.org.
10.in-addr.arpa.	86400	IN	NS	blackhole-1.iana.org.
10.in-addr.arpa.	3600	IN	NSEC	100.in-addr.arpa. NS RRSIG NSEC
10.in-addr.arpa.	3600	IN	RRSIG	NSEC 8 3 3600 20171229130507 20171208140001 51846 in-addr.arpa. WcpA1d1GIL2vC22QrTf6V3wni22+aD8XlTgSR3K8WAvf7vWfz1NcUIeW 8fiRVj2tTq7rJlnxdoTtTheM1COZrZCdxhBa2wHHnte8k4MlD+p5Wiza 5NjitvL/ASp2VPAdOfEofsJSgWHyQ1C4obCsYGMxux3dgv7ePdYiPzgr 9hE=

;; Query time: 411 msec
;; SERVER: 2001:67c:e0::1#53(2001:67c:e0::1)
;; WHEN: Thu Dec 14 11:52:29 AEDT 2017
;; MSG SIZE  rcvd: 342

[rock:bin/tests/system] marka% 

[rock:~/git/bind9x] marka% dig 17.172.in-addr.arpa +dnssec @r.arin.net

; <<>> DiG 9.12.0rc1+hotspot+add-prefetch+marka <<>> 17.172.in-addr.arpa +dnssec @r.arin.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1672
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;17.172.in-addr.arpa.		IN	A

;; AUTHORITY SECTION:
17.172.in-addr.arpa.	86400	IN	NS	blackhole-1.iana.org.
17.172.in-addr.arpa.	86400	IN	NS	blackhole-2.iana.org.
17.172.in-addr.arpa.	10800	IN	NSEC	170.172.in-addr.arpa. NS RRSIG NSEC
17.172.in-addr.arpa.	10800	IN	RRSIG	NSEC 5 4 10800 20171227213540 20171213203540 40857 172.in-addr.arpa. kLq3ev/dBxW/4NEDxBJlksmE6nXI7CZC84D17ZLsLzo4jThantJea5fw UTdtR/YFt0kFAYtNv3gTkHn8E48wQV/50rExb5Kg4iKTSCol84S6o6p0 Lt6lKslVCt8qPIjonScKmJhly9WlO/mPqsFu7xNoK4wFGs2p+hOMcvkQ oN8=

;; Query time: 320 msec
;; SERVER: 2001:500:f0::63#53(2001:500:f0::63)
;; WHEN: Thu Dec 14 12:17:37 AEDT 2017
;; MSG SIZE  rcvd: 326

[rock:~/git/bind9x] marka% 

[rock:bin/tests/system] marka% dig 168.192.in-addr.arpa +dnssec @r.arin.net

; <<>> DiG 9.12.0rc1+hotspot+add-prefetch+marka <<>> 168.192.in-addr.arpa +dnssec @r.arin.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3764
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;168.192.in-addr.arpa.		IN	A

;; AUTHORITY SECTION:
168.192.in-addr.arpa.	86400	IN	NS	blackhole-1.iana.org.
168.192.in-addr.arpa.	86400	IN	NS	blackhole-2.iana.org.
168.192.in-addr.arpa.	10800	IN	NSEC	0.169.192.in-addr.arpa. NS RRSIG NSEC
168.192.in-addr.arpa.	10800	IN	RRSIG	NSEC 5 4 10800 20171227213323 20171213203323 57162 192.in-addr.arpa. Pg7l5KbT8lU7pbZJf/W1CeKM68b9gp8Nck0e+IsiJ08kcjHPXyVg6juu 1f5eLDbbq7SeqR8yMxu9BKf4FqXhgzsqTxXB5AdwCNIBLEHwbWSIurqy nFiTD1upf3PbiSmheqLGz2n3kCqgMS+/dVapW4y2JQsDMEBp1Q/Y5ux/ UpY=

;; Query time: 293 msec
;; SERVER: 2001:500:f0::63#53(2001:500:f0::63)
;; WHEN: Thu Dec 14 12:03:18 AEDT 2017
;; MSG SIZE  rcvd: 329

[rock:bin/tests/system] marka% 

> On 14 Dec 2017, at 11:40 am, Joe Abley <[email-masked]> wrote:
> 
> Hi Mark,
>

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Dec 2017 20:25:38 -0500

Hi Mark,

[I'm typing this on a phone. It's going to look horrible in a real
mail client. Sorry about that.]

> Looks like we need to open a ticket for those.  But the ones people actually have internal zones in are correct.  Check the RFC 1918 delegations.  I know these started out being delegated to blackh…

The zones originally delegated are not rocket science, agreed. The
others are difficult to do unless you don't mind them being lame for a
hard-to-measure population of end-users. Isn't that what we are
talking about?

I can't tell whether you disagree with that or whether you think lame is ok.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Dec 2017 20:45:42 -0500

> The ambiguity is (for example) that "point to" is not a well-defined phrase, given that we have two documented ways of doing this in the AS112 project, and neither is "black hole server" which from…

What is wanted is that there be a delegation in .arpa for home.arpa that isn't signed, so that DNSSEC validation will not fail when an answer is presented to the stub that is different than what's in the .arpa zone.   There is never a valid use case where a query actually goes to a server to which home.arpa is delegated from the authoritative servers for .arpa.   We just need for .arpa not to say something that contradicts what the locally-served zone says.

This is the same behavior that is necessary for e.g. 10.in-addr.arpa, in order that a local DNS service can provide answers within that zone without the actual from-the-root delegation authentically contradicting what that server is saying.

IOW, if you think that what is being requested here is different than what's needed for 10.in-addr.arpa, we've failed to communicate.   The issue is that we hadn't really thought about the secure denial of existence problem prior to the dot-home work.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Dec 2017 12:53:30 +1100

> On 14 Dec 2017, at 11:31 am, Joe Abley <[email-masked]> wrote:
> 
> Hi Ted,
> 

And if IANA didn’t understand the instructions they had a opportunity during the RFC creation process to request clarification.   It is a explicit step in the process to try to prevent issues like this.  IANA could have done the delegation at that point in time and had it in place before the RFC exited the RFC publication process and even asked “Is this correct?”.  IANA make similar queries for registry entries.

Creating a delegation is a operation that happens millions to times a day around the world as is setting up name servers to serve a zone.

As for “point to” read it as “delegated to” if you want to nit pick.   Also IANA was NOT instructed to delegate to the AS112 servers.  IANA was instructed to delegate to back hole servers and a example of which, the AS112 servers, was presented.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 Dec 2017 15:16:47 +0100

On Thu, Dec 14, 2017 at 12:53:30PM +1100,
 Mark Andrews <[email-masked]> wrote 
 a message of 41 lines which said:

> Also IANA was NOT instructed to delegate to the AS112 servers.  IANA
> was instructed to delegate to back hole servers and a example of
> which, the AS112 servers, was presented.

I understand it is precisely one of the problems Joe Abley mentioned:
AS 112 servers are not really black hole servers (they reply).