Subject: [DNSOP] Renumbering and glue record updates

From: Matthias-Christian Ott <[email-masked]>
Date: Tue, 01 Sep 2015 23:23:36 +0000

Since 6renum is concluded I thought this WG could most likely help to
address the following problem:

If the IPv6 network of an authoritative nameserver is renumbered and the
parent zones of zones that are served by the nameserver contain glue
records for the nameserver, the glue records need to be changed as well.
As described in RFC 7010, the nameserver could update the glue records
through Secure Dynamic DNS Updates and the nameserver of the parent zone
could restrict dynamic DNS updates to the AAAA RRs for the name of the
nameserver through ACLs (principle of least privilege). So in theory the
problem the problem is solved.

In practice subdomains registered under public suffixes do not allow
dynamic DNS updates. Glue records and NS records can only be changed
through EPP or proprietary protocols of the respective registries and in
some cases only through fax or letter. Most registrars expose their
interface to the registry, including glue record management, directly to
registrants either through a self-service web interface that can be
scraped, EPP or some proprietary protocol and only few require
interaction with their customer support. So it is still possible to
automatically update the glue records of a nameserver when its network
is renumbered. However, there is no fine-grained access control - even
if you interface directly with the registry. That means that you have to
store the credentials that can be used to change all details of your
domain in the registry on every nameserver if you want that nameserver
to be able automatically update its glue records. If your domain uses
DNSSEC with separate KSK and ZSK, it suffices to compromise a secondary
nameserver to replace the KSK which undermines the security model.

After some thinking the only countermeasure that I could come up with is
to either to have a trusted gateway to the registrar/registry that you
assume to be secure and highly-available or monitor the registry for key
changes and have an emergency plan to limit the damage. Both
countermeasures seem unsatisfactory to me.

Obviously registries and registrars could introduce more fine-grained
access control but I doubt that this is going to happen, especially
considering the interfaces provided by registrars.

Has this problem been addressed somewhere or is there an ongoing effort
that would address it?

- Matthias-Christian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2015 13:22:00 +1000

> Has this problem been addressed somewhere or is there an ongoing effort

https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/

Provided a mechanism to do this which allowed fine grain access control
base on tsig / sig(0) name.

It could also use SIG(0) instead of TSIG though the draft doesn't state
that.

> - Matthias-Christian
> 
> _______________________________________________
> 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: Holger Zuleger <[email-masked]>
Date: Wed, 2 Sep 2015 12:12:40 +0200

>> nameserver to replace the KSK which undermines the security model.
You can overcome the problem with the glue records by putting all the NS
server in a different domain not below your zone. But this of course
wouldn't help on DS or NS updates.

> It could also use SIG(0) instead of TSIG though the draft doesn't state
I've written a client tool to update NS, DS and glue records and uses
TSIG (only) authenticated DNS UPDATEs.

$ zkt-delegate -h
usage: zkt-delegate -h|-v
usage: zkt-delegate -k keyfile [-d] [-t ttl] [-s server] [-p port] [-o
origin] <cmd> [parameter  ...]
	-h, --help		 print out this help message
	-V, --version		 print out version and exit
	-v, --verbose		
	-k, --keyfile=tsigfile	 name of file with tsig key (named.conf syntax)
	-d, --delete		 switch update delete processing
		 		 (default: In file mode delete old RRSet before adding new ones)
	-t, --ttl <ttlspec>	 specify ttl of RR (default depends on cmd)
	-o, --origin=zone	 specify domain (default is tsig keyname)
	-s, --server=master	 specify master server for updates (default is SRV
or SOA record)
	-p, --port=<port>	 specify port for updates (default is 53)
<cmd>
	ns   {-f zonefile | [nsname ...]}		change delegation record (NS)
	ds   {-d dsfile | -f zonefile_with_CDS}		change delegation signer
record (DS)
	glue {-f zonefile | nsname [ipaddr ...]}	change glue address record
(A/AAAA)

It's not very well tested yet and is part of the latest ZKT [1] version
(which is actually not the same as the one in the BIND contrib dir).
The tool requires the ldns library which doesn't support SIG(0) for
updates (as far as I know).

Holger

[1] https://github.com/hzuleger/ZKT

---

From: Matthias-Christian Ott <[email-masked]>
Date: Wed, 02 Sep 2015 21:56:47 +0000

> It could also use SIG(0) instead of TSIG though the draft doesn't state

A variant of the mechanism proposed in the draft is certainly a simple
solution.

However, I don't think it will work in the current market. Most
registrars and nearly all of their customers have no interest in this
(ask a randomly selected registrar about DNSSEC and IPv6). So there is
no competitive advantage or incentive to implement it.

I looked at many registrars over the last weeks and found that their
proprietary APIs provided by most registrars are often incomplete and
low quality (some PHP script that translate SOAP or REST API calls to
EPP or a proprietary protocol of a registry) because they are developed
for resellers of the registrars who apparently don't care and have very
low requirements (often also only available to resellers).

It's hard to find DNS service providers that even offer TSIG for zone
transfers, most providers sadly authenticate zone transfers through IPv4
addresses.

Very recently I scraped the websites of ICANN and major European
registrars and tested whether the websites of several hundred registrars
are available over IPv6 and whether the corresponding zone is signed
with DNSSEC. Fewer than a dozen registrars worldwide fulfil this
criteria and fewer than a handful of registrars have an API that allows
you to change your NS RRs and DNSSEC keys.

So to sum it up: Registrars are very far behind and haven't even
implemented DNSSEC and IPv6. There are to too many registrars and most
of them have customers who simply do not care as long as their website
is somehow reachable over IPv4 and any additional service just means
wasted time for them. Asking them for an even less frequently used
feature is hopeless and pointless (its cheaper to become a registrar
yourself than to pay the registrar to implement this feature). I think
if there can be a solution it should not involve registrars. On the
other hand most registries also do not directly deal with registrants,
so I'm not sure who should implement the solution to this problem.

To prevent a longer discussion: I know that most statements and
observations that I made about are claims and except for the statistics
about DNSSEC and IPv6 deployment I have no evidence to back them up
other than the fact that I spent a considerable amount of time studying
the market.

- Matthias-Christian

---

From: Matthias-Christian Ott <[email-masked]>
Date: Wed, 02 Sep 2015 22:01:35 +0000

> wouldn't help on DS or NS updates.

At some point/level of indirection you will need glue records.

- Matthias-Christian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Sep 2015 08:33:36 +1000

> no competitive advantage or incentive to implement it.

This is partially a chicken and egg issue.  There is no protocol
specified so no one is willing to invest the time to get a protocol.
As there is no protocol no one complains about it not being there.

Apple have registered _dns-upate._udp SRV as a mechanism to redirect
updates to a alternate server.  MacOS uses this to do its dynamic
updates (See System Preference -> Sharing -> Edit).  This could just
be pointed at a UPDATE only server that examines the ZONE and UPDATE
sections for the correct registrar then forwards the update message
provided it has a TSIG or SIG(0) signature.

This UPDATE only server would take less than a day to write.

	open listening sockets

	parse message

	check for signature - return NOTIMP if not found.

	check ZONE section for sanity

	look at first name in UPDATE section to determine registrar

	forward update using a per registrar txid space for TSIG
	so you can de-mux replies.

	forward update using same txid for SIG(0) ensuring that
	you don't have multiple txid outstanding on the same socket
	so you can de-mux replies.

	relay reply fixing restoring txid for TSIG.

Named does all this for UPDATE when running as a slave with
update-forwarding enabled, with the exception of looking up the
registrar, so this is *nothing* new.  You are looking at 16 year
old code paths here.

---

From: Matthias-Christian Ott <[email-masked]>
Date: Sat, 12 Sep 2015 14:21:04 +0200

> registrar, so this is *nothing* new.  You are looking at 16 year

Still the registrar would have to implement the translation from DNS
updates to EPP messages. I wouldn't say that this is impossible to
implement in PHP (sadly that's how most registrars work) but it's not
easy. Moreover, there has to be customer demand or another incentive for
a registrar to implement it.

- Matthias-Christian

---

From: Mark Andrews <[email-masked]>
Date: Sun, 13 Sep 2015 10:32:58 +1000

> a registrar to implement it.

Given that a number of registrars provide a collection of different
adhoc tools to do this there is a demand, just not standardisation.
By not standardizing they are creating registrar lock-in.

ICANN, under its charter to encourage competition, should be pushing
for this as lock-in discourages real competition.