Subject: Re: [DNSOP] Adoption of <draft-wkumari-dnsop-omniscient-as112-01.txt> as a WG work item?

From: Joe Abley <[email-masked]>
Date: Thu, 14 Mar 2013 18:44:20 -0400

On 2013-02-22, at 15:14, "Dickson, Brian" <[email-masked]> wrote:

> Instead of delegating to omniscient AS112 servers, what about doing a
> DNAME to a specific target "foo" (replace "foo" with what you will) in the
> DNS tree?

I've thought about this a bit, and I've decided that I quite like it.

So, if I can paraphrase to ensure we're talking about the same thing, the current working omniscient plan involves:

 - custom code
 - some degree of discomfort, possibly unwarranted, with the NOERROR/no ANSWER approach

Your idea, however, involves

 - hosting a known, empty zone on known nameservers
 - pseudo-delegating new worthy zones by provisioning a DNAME at a suitable point in another zone
 - no custom code
 - no protocol discomfort, so long as we don't gag too badly on the use of DNAME

Your idea has advantages, then.

Anybody could decide to sink traffic for any name at AS112++ servers by installing a similar DNAME. This would become a standard way to dispense with and junk DNS traffic; perhaps we need to think about writing this up as AS112.ARPA and make it a more general mechanism than just a place to sink default-local-zones traffic.

Suppose AS112.ARPA is delegated to the nameservers BLACKHOLE-3.IANA.ORG and BLACKHOLE-4.IANA.ORG, and the AS112.ARPA zone is empty apart from an SOA (SOA.MNAME = PRISONER-2.IANA.ORG). The names of the servers don't matter much, except that they need not to be named under AS112.ARPA (since that would pollute the empty zone with A and AAAA RRSets).

We acquire an IPv4 /24 and an IPv6 /48 from which to number those three servers. AS112++ operators listen on those addresses, announce the corresponding routes and host an AS112.ARPA zone which is empty apart from apex SOA and NS RRSets.

(Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's distribution masters who is retrieving the zone, and hence where the AS112++ operators were. So, this is also AS112 with DNSSEC, and it's measurable.)

We want traffic for names under D.F.IP6.ARPA (RFC4291) to be handled in an AS112 like way. We install a DNAME in the IP6.ARPA zone:

$ORIGIN IP6.ARPA.
D.F	IN	DNAME	AS112.ARPA.

No changes are needed to the servers which serve AS112.ARPA. We can change our minds about D.F.IP6.ARPA or add new bits of namespace to be treated similarly at any time, with no coordination required by the AS112++ operators.

Once we have confidence that the AS112.ARPA zone is being hosted adequately, we could re-provision 10.IN-ADDR.ARPA, 168.192.IN-ADDR.ARPA and 16.172.IN-ADDR.ARPA and friends with DNAME and the old AS112 system can be retired.

RFC 6303 could be simplified by specifying that resolvers should host an empty AS112.ARPA zone, which would give similar behaviour to hosting a long list of empty zones (not as great a reduction in traffic for the zones mentioned in 6303, but with the benefit that other zones which are AS112++ified would get caught locally without requiring updates to 6303 or resolver configuration).

RFC 6304 could be replaced with updated guidance (new addresses, just hosting AS112.ARPA).

We can avoid re-enragement of the IESG by not re-proposing SINK.ARPA as a way to avoid generating junk traffic, understanding that using AS112.ARPA wherever SINK.ARPA might have been used is nearly as good.

This seems like a good, pragmatic path forward. I'm intrigued to hear the reactions of others to the general idea or the details of this rambling thought experiment.

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Mar 2013 18:55:47 -0400

On 2013-03-14, at 18:52, George Michaelson <[email-masked]> wrote:

> how many of the deployed resolvers can understand DNAME

Good question, it would interesting to design an experiment to measure that.

> and whats the outcome for dns lookups where the intermediate systems dont understand DNAME.

CNAME synthesis, see RFC 6672 section 3.

Joe

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Thu, 14 Mar 2013 18:57:27 -0400 (EDT)

FWIW, this was first broached on the AS112 operators ML.  Thread here:

https://lists.dns-oarc.net/pipermail/as112-ops/2011-July/000209.html

Hope this contributes to the discussion.

On Thu, 14 Mar 2013, Joe Abley wrote:

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

wfms

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Mar 2013 11:01:41 +1100

I've got no objections to experimenting with DNAME like this.

DNAME and NXDOMAIN are QTYPE agnostic whereas NOERROR/NODATA is
not.

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 15 Mar 2013 12:01:55 -0400

> CNAME synthesis, see RFC 6672 section 3.

You mean like 
test.dname-only.res.dnssecready.net  txt 
test.d-and-c.res.dnssecready.net txt 
test.d-bad-c.res.dnssecread.net txt 

The first name returns only dname, second one both, the third one has different targets for 
the C and D names. The txt record pointed to tells you if you 
the results tell you if the D or C name what happened. 

<dhcp-606e:~/Code/evldns 23:09> dig test.d-bad-c.res.dnssecready.net txt 

; <<>> DiG 9.8.3-P1 <<>> test.d-bad-c.res.dnssecready.net txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12051
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;test.d-bad-c.res.dnssecready.net. IN	TXT

;; ANSWER SECTION:
d-bad-c.res.dnssecready.net. 300 IN	DNAME	good-Dname.dnssec-test.org.
test.d-bad-c.res.dnssecready.net. 300 IN CNAME	test.good-Dname.dnssec-test.org.
test.good-Dname.dnssec-test.org. 3600 IN TXT	"GOOD: DNAME followed"

But the original server returned
;; ANSWER SECTION:
d-bad-c.res.dnssecready.net. 300 IN	DNAME	good-Dname.dnssec-test.org.
d-bad-c.res.dnssecready.net. 1	IN	CNAME	bad-Cname.dnssec-test.org.

According to a large scale resolver/forwarder survey that I conducted recently DNAME is fully supported at least 
50% of resolvers/forwarders tested supported it. Im sure the number is higher today because 
Google has added DNAME support since then. Fully supported means that the resolver follows DNAME and includes the 
DNAME 's used 

	Olafur

---

From: Hugo Salgado <[email-masked]>
Date: Fri, 15 Mar 2013 15:21:54 -0300

> (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's…

Also has the benefit of penalizing when a slave becomes stalled,
going bogus when signatures expires.

A resolver which falls in a bogus nameserver should try with the
next one. So I think the organisations should host only one NS of the
complete set, giving the chance of diversity.

Hugo

---

From: Steve Crocker <[email-masked]>
Date: Fri, 15 Mar 2013 11:34:30 -0700

> complete set, giving the chance of diversity.

It feels like there are two distinct issues here.  If the signatures expire, all copies of those records will be affected, so diversity of name servers won't help.

Diversity of name servers is certainly helpful in countering operational failures of equipment or network connectivity.

Steve

---

From: Joe Abley <[email-masked]>
Date: Fri, 15 Mar 2013 14:36:58 -0400

> It feels like there are two distinct issues here.  If the signatures expire, all copies of those records will be affected, so diversity of name servers won't help.

My assumption was that this was a reference to the "signatures expired because zone transfers stopped working and nobody noticed" problem.

Joe

---

From: Hugo Salgado <[email-masked]>
Date: Fri, 15 Mar 2013 15:37:23 -0300

> It feels like there are two distinct issues here.  If the signatures expire, all copies of those records will be affected, so diversity of name servers won't help.

But the expiration affects only the instance that went stalled. The rest
of correctly-slaved secondaries should maintain fresh signatures.

Hugo

---

From: Tony Finch <[email-masked]>
Date: Fri, 15 Mar 2013 18:41:50 +0000

Joe Abley <[email-masked]> wrote:
>
> Once we have confidence that the AS112.ARPA zone is being hosted
> adequately, we could re-provision 10.IN-ADDR.ARPA, 168.192.IN-ADDR.ARPA
> and 16.172.IN-ADDR.ARPA and friends with DNAME and the old AS112 system
> can be retired.

What will be the consequences of this for validators that are trying
to use local versions of the RFC1918 zones? Will local zones have to be
signed and provide trust anchors for validating users?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.