On 11/9/21 3:29 AM, Paul Wouters wrote:
- IPv6 reverse DNS hostnames (under ip6.arpa.) already have length 73.
But would they hit 255 ?
No, this was only an illustration: Had there been some standard which
prevented such long names, then IPv6 reverse DNS names would not have
been possible. But, luckily, nothing go in the way.
We don't know how long names will be in the future, and what will get
in whose way.
I wouldn't dare make a prediction about what kind of names could be
introduced in the next decade (think of underscore labels for TLS
identities, perhaps with other parameters encoded in front etc.).
Per definition, you can create domain names that are too long to support
_underscore labels on top of them. And yet there we did not use hashing
either?
When adding labels (e.g. an underscore label) in front of a domain
name, the name of the parent / origin is fixed, so hashing it isn't an
option. It's not possible to change the length of the suffix.
However, it's possible to choose the length of the prefix that is being
added, and it may make sense to make sure it's not unnecessarily long.
Other technical considerations:
- Not hashing creates semantic collisions. Practical example from our
deployment at deSEC: The list of delegations under dedyn.io is long
and changes frequently, so we'd probably like to put bootstrapping
records for children of dedyn.io into a separate zone.
Without hashing, that zone would be dedyn.io._boot.<NS>.If we do
that, then we can't use bootstrapping for dedyn.io itself, because
dedyn.io._boot.<NS> would be an apex name. This collides with the
requirement that bootstrapping records MUST NOT occur at the apex
(where they would signify *that* zone's own DS info).
You can't bootstrap in-baliwick anyway, can you?
There seems to be a misunderstanding: The not-in-bailiwick limitation
means that a nameserver can't bootstrap its own domain, for lack for a
pre-existing validation path. But in the above example, it was not
assumed that any of the zones mentioned has any in-bailiwick NS.
To clear up the misunderstanding, I'll write out the example in detail.
dedyn.io has NS ns1.desec.io and ns2.desec.org. Children of dedyn.io
typically have the same NS rrset.
When a customer registers a new name under dedyn.io (it is a public
suffix), we currently have some kind of hook that creates the DS
records in the dedyn.io zone. Once there is a good bootstrapping
protocol, there should be no need to keep that kludge.
We would like to use the bootstrapping protocol to enable DNSSEC for
such sub-zones. For that, we have to read the bootstrapping records,
which would be, without hashing, located at something like
example.dedyn.io._boot.ns1.desec.io (sticking to _boot for now).
Because dedyn.io has a lot of delegations and keeps changing, we'd like
to run bootstrapping for dedyn.io in a separate zone (same for com).
We'd arrive at a setup like this:
dedyn.io._boot.ns1.desec.io # bootstrapping zone for dedyn.io children
com._boot.ns1.desec.io # bootstrapping zone for com children
_boot.ns1.desec.io # zone for all other bootstrapping
Now let's consider bootstrapping for dedyn.io *itself* (not one of its
children!). The location of the bootstrapping records for this domain
would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
the *zone* which constains bootstrapping records for domains *under*
dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io.
We therefore cannot put dedyn.io's bootstrapping records at
dedyn.io._boot.ns1.desec.io, as this is a zone apex, and putting
CDS/CDNSKEY records there would indicate that the DS records for the
zone "dedyn.io._boot.ns1.desec.io" should be updated, as opposed to
signaling bootstrapping records for the zone "dedyn.io".
This has nothing to do with in-bailiwick. The problem occurs because
bootstrapping records cannot be at the apex (as to not overload the
meaning of apex CDS/CDNSKEY records), but by "inheriting" the structure
under dedyn.io, a situation arises where this condition is not met.
The solution is to not "inherit", but flatten the hierarchy, which is
what the hash does. With hashing, children of dedyn.io would have
their bootstrapping records under h(dedyn.io)._boot.ns1.desec.io, such
as example.h(dedyn.io)._boot.ns1.desec.io.
In contrast, the bootstrapping records for dedyn.io *itself* would live
at dedyn.h(io)._boot.ns1.desec.io. No collision occurs.
Note that this is not an apex name, even if h(io)._boot.ns1.desec.io is
made a separate zone for operational reasons. Similary, the name for
bootstrapping of example.dedyn.io is not an apex name, even if
h(dedyn.io)._boot.ns1.desec.io is made a separate zone.
It is unclear to me how such situations would properly be dealt with if
the bootstrapping owner names retained the target domains' hierarchy.
One could of course specify that you can only ever bootstrap *one*
name along a certain branch of the DNS tree. But what would be the
motivation for such a limitation?
I'm sure the situation could be complicated futher by considering more
sophisticated delegation hierarchies (e.g. dedyn.io is at ns1.desec.io,
foo.dedyn.io is not, but bar.foo.dedyn.io is again at ns1.desec.io, and
so on). These are all things the protocol should be ignorant of.
The hash ensures that *different things* get *different names*.
It is a namespacing mechanism, and avoids overloading the names of
bootstrapping records with the names of bootstrapping zones. Such
overloading would be unclean design even if the was no pre-existing use
of CDS/CDNSKEY records at the apex.
- Clear datastructures simplify implementation (in my experience).
Hashing leads to a very predictable data structure with always two
labels in front of the underscore label. Also, that label would be
an ENT; all records live at the leaves of the tree. This assumption
cannot be made when the names are simply concatenated (see above).
ENT's aren't that great :P For example, with query minimalization on
AWS Route53, these have been broken for years. I'd stay away from ENTs.
Haha :-) Yes, I'm with you. My point was precisely that without
hashing, you may sometimes get an ENT at a certain hierarchy level and
sometimes you don't, so you'll have to deal with both cases.
With hashing, you'll only have to deal with the case that there is an
ENT at the hash label, which in turn may simplify debugging etc.
Are there any conceptual downsides of the hashed label that would
outweigh these points?
Yes. Speaking of NSEC3, that is super hard for people to grasp. To us
experts it is obvious, but all the hashes makes a new person who looks
at it pretty confused. I think it would be good in general to try and
make it so that operators can debug DNS issues with the dig command,
without needing advanced tools.
I think the main confusion about NSEC3 stems from the iterations stuff
and from sophisticated denial-of-existence, including when wildcards
are in the game. We have none of that here.
I agree about the dig command. But, it's only possible (e.g. for
DNSSEC debugging) because dig has some explicit things implemented,
e.g. options like +multiline or +trace.
One could thus turn your concern around and say that to aid debugging,
it would be cool if debugging tools like dig would get equipped with
suitable capabilities. ;-)
While I don't feel strongly, I wonder in how many cases somebody would
really look at that during that extra wait interval. Also, CDS/CDNSKEY
processing already requires checking that updated DS records don't
break resolution.
Yes, but if someone accidentally pushes a DNSSEC deployment out and
pulls it back in after 5 minutes, you don't want this protocol to have
pushed the machinary into production and causing ServFails. Similarly,
I find BGP / routing attacks still scary, and attackers can only briefly
hold the route hijacks up. So waiting a day would really offer a lot
of protection here.
Fair enough. I made a note to add a sentence along those lines.
Thanks for your input!
Peter
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
