Subject: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

From: Ben Schwartz <[email-masked]>
Date: Wed, 29 Jul 2020 15:54:49 -0400

I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to
make sure that the draft isn't overstating the achievable benefits.  To
that end, I have some questions about the text of the -01 draft.

(I recognize that these are issues I've raised before, but I still haven't
gotten answers that I understand.)

Assuming the claims are correct, I think they need some clarifications for
naive readers like myself (and possibly deduplication, since some claims
are repeated in different sections).

>   Exposing such targeted attacks requires a transparency audit
>   infrastructure similar to what is deployed for PKIX ([RFC6962]).
>   However, a DNSSEC version would need to log significantly more data,
>   as all signed DNS data used by a DNSKEY must be recorded in order to
>   prove that data signed by a parent zone's DNSKEY was out of expected
>   policy.  The very distributed nature of the DNS combined with the
>   typically frequent zone resigning rate makes such transparency logs
>   prohibitively expensive and nearly impossible to operate.

How does this draft alter that cost?  For delegation-only zones that are in
compliance, it seems like the cost is not changed.  Presumably violations
will be rare, so they won't contribute significantly to the cost.

>   Additionally, it would require zone owners to expose all their zone
>   data to any public log operators, thereby introducing privacy
>   implications and exposing all relevant DNS data to a public archive.

I don't understand how this flag would alter that exposure.  If my zone is
already delegation-only, how does adding this flag improve privacy?

>   At the time of this writing, the list of entries in the
>   public suffix list contains over 8800 entries as well, with 73 wild-
>   card entries (prefixed with a "*") indicating that all of their
>   (unknown number of) children are public registration points.  In the
>   absence of an interoperable mechanism (like this draft provides), it
>   is infeasible that a validating resolver or auditing log could know
>   which of these zones are delegation-only without individual policy
>   statements from each of them.

Marking a zone delegation-only doesn't imply that it is suitable for
logging, so wouldn't participation in any logging scheme require an
individual policy statement anyway?

>   Finally, a DELEGATION_ONLY flagged DNSKEY for
>   the root zone cannot be overridden easily, as it would require a
>   trust anchor update in all validating resolvers.

The preceding sentences deal with the lingering "false child key" problem,
which still applies here, so I don't understand the relevance of this
sentence.

I also had some thoughts on the Security Considerations:

>   Care should be taken by resolvers to not
>   unnecessarily empty their cache.  This is specifically important for
>   roaming clients that re-connect frequently to different wireless or
>   mobile data networks.

I believe this advice is counter to best practices for mobile clients for
both performance and privacy reasons.  See e.g. http://dnscookie.com/.

Also, I think it's worth mentioning that "delegation-only" zones can still
deny the existence of a DS for the child (if the child was signed to begin
with), and then generate deep unsigned records for the child.  This limits
the direct impact of this flag to cases where DNSSEC is mandatory.
(Logging might be able to deter this attack, assuming NSEC records are
logged.)

Thanks,
Ben Schwartz

---

From: Petr Špaček <[email-masked]>
Date: Thu, 30 Jul 2020 15:57:55 +0200

Hello,

I'm going to generalize Ben's questions:

It is hard to see what benefits draft-ietf-dnsop-delegation-only brings without having description of "DNSSEC Trasparency" mechanism available.

Please describe intended usage of the proposed mechanism, at the moment it is hard to see all the details and interactions.

Petr Špaček  @  CZ.NIC

On 29. 07. 20 21:54, Ben Schwartz wrote:
> I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to make sure that the draft isn't overstating the achievable benefits.  To that end, I have some questions about the text of the -01 draft.
> 
> (I recognize that these are issues I've raised before, but I still haven't gotten answers that I understand.)
> 
> Assuming the claims are correct, I think they need some clarifications for naive readers like myself (and possibly deduplication, since some claims are repeated in different sections).
> 
> How does this draft alter that cost?  For delegation-only zones that are in compliance, it seems like the cost is not changed.  Presumably violations will be rare, so they won't contribute significantly to the cost.
> 
> I don't understand how this flag would alter that exposure.  If my zone is already delegation-only, how does adding this flag improve privacy?
> 
> Marking a zone delegation-only doesn't imply that it is suitable for logging, so wouldn't participation in any logging scheme require an individual policy statement anyway?
> 
> The preceding sentences deal with the lingering "false child key" problem, which still applies here, so I don't understand the relevance of this sentence.
> 
> I believe this advice is counter to best practices for mobile clients for both performance and privacy reasons.  See e.g. http://dnscookie.com/.
> 
> Also, I think it's worth mentioning that "delegation-only" zones can still deny the existence of a DS for the child (if the child was signed to begin with), and then generate deep unsigned records for the child.  This limits the direct impact of this flag to cases where DNSSEC is mandatory.  (Logging might be able to deter this attack, assuming NSEC records are logged.)
> 
> Thanks,
> Ben Schwartz

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2020 13:20:46 -0400 (EDT)

> It is hard to see what benefits draft-ietf-dnsop-delegation-only brings without having description of "DNSSEC Trasparency" mechanism available.

I do not believe that is correct. The first and foremost purpose is for
the bit to signal the parent zone's behaviour in a public way that
prevents targeted / coerced attacks from the parent. This allows
policy violations to be rejected even if these violating DNS answers
are DNSSEC signed.

Secondary, it eases the transparency logging. If it is clearer for
us to leave out the DNSSEC Transparency parts, that can certainly
be done, but I will try to provide text to Ben's and others to
clarify this latter part.

>> How does this draft alter that cost?  For delegation-only zones that are in compliance, it seems like the cost is not changed.  Presumably violations will be rare, so they won't contribute signifi…

You can only be a "delegation-only zone in compliance" if you publish
this new DNSKEY flag. Without this flag there is no way to know the
zone's policy. This is what is often described as the Public Suffix
list/problem.

One you know a zone is delegation only, the only way this zone can still
try to violate its own policy is to replace the child delegation with
its own. Therefor, you only need to log DS records that will show you
there is a child zone change. And resolvers can drop any Answers DNSSEC
signed outside the apex as bogus. Therefor, the parent won't even try
to do this and we dont have to log all its queries.

Without this bit, even if we know ".ca" is defacto a delegation only
zone, we have no mechanism to drop records violating this policy without
maintaining a public suffix list type within the resolver or using some
RBL type queries to more dynamically determine the delegation-only
aspect. So now we need to log things like _443._tcp.nohats.ca. IN TLSA
records if signed by something higher than nohats.ca because we can
no longer declare such records as "harmlessly dropped as bogus" and
we simply cannot tell if the record is legitimately signed or not.

>> I don't understand how this flag would alter that exposure.  If my zone is already delegation-only, how does adding this flag improve privacy?

Your zone is not "delegation only" if you have no automated way of
declaring it as such that is accepted by DNS resolvers all over the
world. See Public Suffix issues.

>> Marking a zone delegation-only doesn't imply that it is suitable for logging, so wouldn't participation in any logging scheme require an individual policy statement anyway?

Logging is not done by the publishers (zone owner) like in CT. Logging
would be done by DNS resolvers in some privacy preserving shared method.

>> The preceding sentences deal with the lingering "false child key" problem, which still applies here, so I don't understand the relevance of this sentence.

I'll clarify that in the next version.

>> I believe this advice is counter to best practices for mobile clients for both performance and privacy reasons.  See e.g. http://dnscookie.com/.

Performance and privacy cannot always go hand in hand together. As for
privacy, I don't understand your argument. When my laptop fires up in a
coffee shop on an empty cache, you will see:

- possibly priming queries and TLD queries
- my firefox tabs reloading/updating causing queries to:
   * bugzilla.redhat.com
   * jabber.org
   * github.com queries
   * testing.libreswan.org
   * datatracker.ietf.org

- Me doing som work will trigger:
   * A/AAAA and SSHFP queries for *.nohats.ca

On an empty DNS cache, I'm quite literally broadcasting the largest DNS
fingerprint possible to identify my. My only change at hiding is to have
a local DNS cache. The last thing I care about is 20ms speedup for some
web page content - the ones who care about those 20ms are the ad auction
participants, not me.

>> Also, I think it's worth mentioning that "delegation-only" zones can still deny the existence of a DS for the child (if the child was signed to begin with), and then generate deep unsigned records…

No they cannot generate "deep unsigned records". Their zone is signed,
so if they are not adding a zone cut / delegation, then they have to sign
it or else DNSSEC validating resolvers will drop those queries as bogus
(missing RRSIG).

Yes they can deny the existence of a child, but that too needs a
signed record of non-existence (NSEC or NSEC3) which would be logged by
transparancy clients logging DS or proof of non-existence of DS.

If you are talking about TLD's that are not dnssec signed, there
is nothing we can do to help those at this point. Any ISP used by me
at the coffeeshop can already send forged A/AAAA records. But that is
pretty harmless, as that has the same impact as your ISP just performing
NAT on your packets or routing your packets to their stolen IP based
networks. The power to change A/AAAA is not what anyone is really trying
to prevent. The prevention is mostly for records with public keys of
fingerprints, such as TLSA, SSHFP, IPSECKEY, eSNI and what not. And none
of those records should ever be used without being protected by DNSSEC
to begin with.

Paul

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2020 14:05:02 -0400

Hi Paul,

> policy violations to be rejected even if these violating DNS answers

Has anybody done a survey to find out how many TLD zones actually fits the description of "delegation-only"?

I know for a fact that ORG does not today and I would say is unlikely ever to. For example, any nameserver N that is subordinate to domain D and linked to some other domain E will be served authoritatively from the ORG zone if domain D is suspended and while E continues to be delegared. Suspensions happen regularly, e.g. for domains implicated in technical abuse. There are several thousand examples of such N today and history suggests the number is not becoming smaller. Even if the number of such N could reach zero in ORG, we could never assume the number would remain at zero and still would not be able to assert usefully that the zone is delegation-only.

I don't think ORG is particularly special in this regard; it seems possible that other (possibly many other; possibly most or all) TLD zones are similar. If there are no TLD zones that actually are delegation-only then there seems no obvious application for it, regardless of whether we consider it to be useful or not.

Joe

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 30 Jul 2020 14:16:53 -0400

On Thu, Jul 30, 2020 at 1:21 PM Paul Wouters <[email-masked]> wrote:

> > It is hard to see what benefits draft-ietf-dnsop-delegation-only brings
> without having description of "DNSSEC Trasparency" mechanism available.
>
> prevents targeted / coerced attacks from the parent.

I would love to see some more description of these attacks in the draft.
Does the targeted attack still apply if the recursive resolver does QNAME
minimization?

>From the current text, I'm having trouble understanding why it matters
whether the attacker has to generate a fake child zone or not (in the
absence of transparency).

This allows
> >> How does this draft alter that cost?  For delegation-only zones that
> are in compliance, it seems like the cost is not changed.  Presumably
> violations will be rare, so they won't contribute significantly to the cost.
>
> zone's policy.

My "null hypothesis" throughout is that

1. zone owners can simply tell me their delegation policy if I email them
to ask, and
2. participation in a logging scheme would require manual review and
approval anyway, because delegation-only zones could still be inappropriate
to log, either because they have privacy concerns or because they would
spam the logs.

If we can safely log any zone that puts up this flag, without further
review, that would certainly make for a stronger case.  Perhaps we can make
logging opt-in part of the flag definition?  Or perhaps we can signal it by
the use of NSEC instead of NSEC3?

This is what is often described as the Public Suffix
> list/problem.

The Public Suffix List has little to do with delegation, and many of the
listed suffixes are not zone cuts at all (e.g. github.io).  Membership in
the PSL would be entirely independent from the DELEGATION_ONLY flag (unless
DELEGATION_ONLY is defined to have additional semantics for HTTP!).
However, I agree that it is an example of the kind of non-technical, human
process that I am describing, and would have significant overlap with
delegation-only zones.

> to do this and we dont have to log all its queries.

But if the parent zone is delegation-only, then there won't be anything
else to log except in case of violation, so these two logs are normally the
same size.

> we simply cannot tell if the record is legitimately signed or not.

But how would such a signature come to exist, if ".ca" is a defacto
delegation-only zone?

> >> I don't understand how this flag would alter that exposure.  If my zone
> is already delegation-only, how does adding this flag improve privacy?
>

The draft says that universal logging "would require zone owners to expose
all their zone data ... thereby introducing privacy implications".  This
seems to apply whether or not the zone is delegation-only, so DNS resolvers
would be violating this proposed privacy principle unless the zone somehow
indicates that it opts in to logging.

...

> >> I believe this advice is counter to best practices for mobile clients
> for both performance and privacy reasons.  See e.g. http://dnscookie.com/.
>
> privacy, I don't understand your argument.
>
...

> a local DNS cache.

If you move IP addresses without wiping your DNS cache, your cached DNS
entries become a supercookie by which a distant server can reidentify you
across the network.  As such, I've been told that the best practice for
privacy is to bind the cache to a single interface and IP.  I would love to
see a draft on this topic, especially if you think this is actually not the
best behavior for privacy.

The last thing I care about is 20ms speedup for some
> web page content - the ones who care about those 20ms are the ad auction

In case it isn't clear, the concern here is about incorrect network
localization of DNS responses.  This is particularly important when using
CDN nodes that are _inside_ an ISP, and are intended for (or perhaps even
restricted to) serving that ISP's customers.  However, it's true that this
is primarily about small performance gains.

>> Also, I think it's worth mentioning that "delegation-only" zones can
> still deny the existence of a DS for the child (if the child was signed to
> begin with), and then generate deep unsigned records for the child.  This
> limits the direct impact of this flag to cases where DNSSEC is mandatory.

Yes, as I noted, this mechanism can deter this attack, but it cannot
prevent it.

If you are talking about TLD's that are not dnssec signed

No, I mean signed parents.

...

> The power to change A/AAAA is not what anyone is really trying
> fingerprints, such as TLSA, SSHFP, IPSECKEY, eSNI and what not.
>

Yes, but nothing in the draft mentions this ... nor its converse, that the
draft only prevents targeted attacks in use cases that already mandate
DNSSEC.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2020 15:43:08 -0400 (EDT)

> I don't think ORG is particularly special in this regard; it seems possible that other (possibly many other; possibly most or all) TLD zones are similar. If there are no TLD zones that actually are…

You are mixing up the generic policy of delegation only with the exact
semantics of the bit. The .org is definately what I would call a
delegation-only domain. Now let's examine the corner case you have
and see if/what we can do.

Rephrasing what you are saying is that "sometimes we need to take over
our children and we currently do this in such a away that we would no
longer appear to be delegation only".

So you are saying that if ns1.example.org serves another-example.org
and example.org is suspended for abuse, that you will still service
A records for ns1.example.org and NS records for another-example.org
containing ns1.example.org but no NS records for example.org? In
the hopes that another-example.org keeps working?

Wouldn't that already fail with DNS servers like unbound with:

 	harden-glue: yes
 	harden-dnssec-stripped: yes
 	harden-below-nxdomain: yes
 	harden-referral-path: yes

which is the default in Fedora / RHEL / CentOS and maybe others?

Paul

---

From: "John Levine" <[email-masked]>
Date: 30 Jul 2020 20:17:08 -0000

In article <[email-masked]>,
>> Has anybody done a survey to find out how many TLD zones actually fits the description of "delegation-only"?

I did some greppage, and found that all of the domains run by Verisign
and Nominet have signed non-glue A records. I think there are a lot of
TLDs run by others that are delegation only but they're mostly tiny
vanity domains.

>which is the default in Fedora / RHEL / CentOS and maybe others?

If the domain is suspended the NS goes away and the A records are not
glue so none of those apply. Some registrars insert faux NS like
NS1.IN-EXPIRATION-GRACE-PERIOD.WTF but many don't since it has just
the collateral damage you identified.

I can tell you from experience as a tiny registrar reseller that Joe's
scenario happens all the time, not suspended for abuse, but just
expired and in the 30 day renewal grace period. E-mailed renewal
notices get lost for various reasons, the domain with the name servers
expires, and it take a few days to figure out why things aren't
working and fix it. In fact the name servrs and the other domains are
all fine as is the expired domain once someone clicks the renew
button.

While I think your general goal is reasonable, by the time we added
enough special cases to match the way real TLDs operate, the camel
would cry.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2020 16:21:37 -0400

Hi Paul,

On 30 Jul 2020, at 15:43, Paul Wouters <[email-masked]> wrote:

> semantics of the bit.

I don't think so, but I would definitely appreciate some clarification if you think that's happening.

> The .org is definately what I would call a

OK. Note that it's not a corner case, however; there are many thousands of examples of this and although I haven't examined every single serial that has ever been published, it seems entirely plausible that that there has never been an ORG zone published since 2002 which has been delegation-only.

> longer appear to be delegation only".

That's a fairly clumsy way of saying what I mean, but it's entirely possible we are talking about the same thing :-)

> the hopes that another-example.org keeps working?

That also seems quite imprecise. Here's a more specific worked example to make sure we understand each other.

$ORIGIN ORG.

BADDOMAIN NS ...
BADDOMAIN NS ...
NS1.BADDOMAIN A 192.0.2.1

GOODDOMAIN NS NS1.BADDOMAIN.ORG.
GOODDOMAIN NS ...

If BADDOMAIN.ORG is suspended (or if the domain is suppressed for some equivalent reason) then the zone cut betwen ORG and BADDOMAIN.ORG will be removed (the BADDOMAIN.ORG NS set will disappear) but the A record above will remain, since it is linked to another domain, GOODDOMAIN.ORG, that depends upon it. Without a zone cut, that makes the ORG servers authoritative for the A record.

To a certain extent, this behaviour is a consequence of (a) the venerable operaetional need to suspend domains because they have been implicated in abuse and (b) the EPP data model used in the ORG registry, which itself has its origins in the RRP data model used before the re-delegation of ORG to PIR in 2002. As such, it's tempting to assert that the behaviour is a contractual requirement shared with all other gTLDs that are operated subject to the same contract that exists between PIR and ICANN, hence my question about applicability.

> which is the default in Fedora / RHEL / CentOS and maybe others?

If so, that sounds like a problem with Fedora/RHEL/CentOS. To the best of my knowledge, this has been the way that ORG has operated for the past 18+ years.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2020 16:28:36 -0400 (EDT)

> I would love to see some more description of these attacks in the draft.

I'm a bit confused that you think describing that in more detail helps.
We are talking about fairly simple records like the .ca zone publishing:

 		nohats.ca	IN	DS	blob + RRSIG(key of .ca)
 		nohats.ca	IN	NS	ns0.nohats.ca.
 		ns0.nohats.ca	IN	A	193.110.157.101

while also (targetted per victim or within a certain time frame) publishing:

 	_443._tcp.nohats.ca	IN	TLSA	blob   + RRSIG(key of .ca)
 		www.nohats.ca	IN	A	<malicious IP>  + RRSIG(key of .ca)
 		nohats.ca	IN	MX 0	tapbox.ca.  + RRSIG(key of .ca)

But I can add this if you feel it helps.

> Does the targeted attack still> apply if the recursive resolver does QNAME minimization?

It is unrelated to query minimalization, other than that targetted
attacks in response to specific queriers is harder.

> From the current text, I'm having trouble understanding why it matters whether the attacker has to
> generate a fake child zone or not (in the absence of transparency).

The attacker could do the above (or even just present glue pretending
the nohats.ca is unsigned, thereby leaving out cryptographic traces).
If it is forced to generate a new DS for his attack to succeed, and they
are forced to publish this at large (eg because query minimalization)
then any monitoring of DS records will get them caught.

> 1. zone owners can simply tell me their delegation policy if I email them to ask, and

This does not scale and cannot be used to automate behaviour of DNS
servers in marking malicious responses as bogus or not.

> 2. participation in a logging scheme would require manual review and approval anyway, because
> delegation-only zones could still be inappropriate to log, either because they have privacy concerns or
> because they would spam the logs.

I think you are confused about transparency. The zone owner does not do
any kind of submittion to a CT log. Instead you monitor your own or
people at large monitor the domains they know or care about or find via
recursive query logs to keep a list of when its DS records have changed.
This requires no permission of the zone owner and does not involve any
agreement about whether producing DS record logs is "appropriate" or
not.

> for a stronger case.  Perhaps we can make logging opt-in part of the flag definition?  Or perhaps we can
> signal it by the use of NSEC instead of NSEC3?

I don't see this being relevant. Also NSEC vs NSEC3 has different
hardware requirements and unrelated privacy considerations.

> But if the parent zone is delegation-only, then there won't be anything else to log except in case of
> violation, so these two logs are normally the same size.

You need to have that bit that TELLS you the zone is delegation-only
without involving humans, management of humans and management of TLD
data, update management policies, etc.

Yes, once you have that bit, the transparency log is reduced to the
violation cases, although you could not boter with logging the futile
attempts that would result in the DNS server dropping the data as bogus
anyway (although you might want it as proof that their DNSSEC key was
used abnormally)

> But how would such a signature come to exist, if ".ca" is a defacto delegation-only zone?

While we at IETF and ICANN might have confidence that the root key or
some TLD keys will never be abused, the fact that these zones have the
power to use these keys for these kind of actions is what some very
vocal people in the infosec community keep hammering on as why you
cannot trust DNSSEC. This bit is specifically meant to increase that
trust.

> The draft says that universal logging "would require zone owners to expose all their zone data ... thereby
> introducing privacy implications".  This seems to apply whether or not the zone is delegation-only, so DNS
> resolvers would be violating this proposed privacy principle unless the zone somehow indicates that it
> opts in to logging.

That statement applied to when we do not have this bit and we would want
to ensure no queries every violated the implicit delegation-only role.

Again there is no "submission" of zone data to a log anywhere in this
system by the authoritative zone operator. I will talk to Wes about
changing this text.

> If you move IP addresses without wiping your DNS cache, your cached DNS entries become a supercookie by
> which a distant server can reidentify you across the network.

That is why you use prefetching and ideally the resolver you are using
also uses prefetching, so that hot data (eg data that is regularly
queried for while it is still in the cache) is pre-fetched before
expiry. And no direct IP link exists between you and the auth server.

I think supercookies would be easier to do if I'm forced to re-query
everything I have all the time.

>  As such, I've been told that the best
> practice for privacy is to bind the cache to a single interface and IP.  I would love to see a draft on
> this topic, especially if you think this is actually not the best behavior for privacy.

I don't think it is.

> In case it isn't clear, the concern here is about incorrect network localization of DNS responses.  This
> is particularly important when using CDN nodes that are _inside_ an ISP, and are intended for (or perhaps
> even restricted to) serving that ISP's customers.  However, it's true that this is primarily about small
> performance gains.

While that could be important and nice to have for my TV or playstation,
I'm not concerned with that for my phone or laptop. Especially since my
mobile devices already VPN across the planet, and are often at
coffeeshops and hotels where I wish my only problem was a 20ms delay.

>       existence of a DS for the child (if the child was signed to begin with), and then generate
>       deep unsigned records for the child.  This limits the direct impact of this flag to cases
>       where DNSSEC is mandatory.  (Logging might be able to deter this attack, assuming NSEC records
>       are logged.)
>
> Yes, as I noted, this mechanism can deter this attack, but it cannot prevent it.

Nothing can prevent a parent from repurposing a child. It is inherent in
the DNS hierarchy. It's a small price to pay for being able to recover
your domain via legal proceedings, or from losing your private keys,
which is true for all "decentralized DNS" proposals.

> Yes, but nothing in the draft mentions this ...

We can add a note to say that anyone in your path can reroute packets to
their own network, thereby pretending to be any target IP address you
have, and as such, there is little value in preventing this takeover
at the DNS layer. I guess we could add that but then also need to talk
about on-path vs off-path attackers. I personally feel that is getting
rather out of scope for the draft.

> nor its converse, that the draft only prevents targeted
> attacks in use cases that already mandate DNSSEC.

I don't talk about DNS without DNSSEC. Without DNSSEC, you are running a
flawed vulnerable version of DNS. One of the largest mistakes of the
IETF has been that it has been so afraid of stating this, that it has
actually given people reason to think no-DNSSEC is a viable
"alternative". It's like trying to secure telnet because you don't like
ssh.

Paul

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2020 16:33:26 -0400

Hi Paul,

> But I can add this if you feel it helps.

Usually when I do risk assessment exercises in order to determine what threats are worth spending money on to mitigate, we throw out those that are thought to be very unlikely to occur or very expensive to mitigate, since there are usually better things to focus on.

Have you done any thought on that kind of risk analysis for this proposal?

For example, has there ever been an example of this attack happening, or are the contractual or commercial pressures to behave well considered by someone to be inadequate? On the expense side, what is the cost of implementation to the degree that the mechanism actually provides some benefit?

My sense is that this is a nice idea in theory but doesn't solve a problem that anybody actually has, and the camel is starting to look a little bit fraught. But I don't think any proposal should succeed or fail based on anybody's uninformed sense, hence the request for more data.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2020 16:36:52 -0400 (EDT)

> OK. Note that it's not a corner case, however; there are many thousands of examples of this and although I haven't examined every single serial that has ever been published, it seems entirely plaus…

50 domains in a few million is a corner case :)  But let's not drift
into language here. I understand your point in that you always have a
few of these in the .org zone.

> If BADDOMAIN.ORG is suspended (or if the domain is suppressed for some equivalent reason) then the zone cut betwen ORG and BADDOMAIN.ORG will be removed (the BADDOMAIN.ORG NS set will disappear) bu…

That is exactly what my "quite imprecise" text said :)

Although please clarify what you do if there are DS records for
BADDOMAIN.ORG and/or GOODDOMAIN.ORG

> If so, that sounds like a problem with Fedora/RHEL/CentOS. To the best of my knowledge, this has been the way that ORG has operated for the past 18+ years.

Clearly not many people are querying for BADDOMAINS.ORG, or they are
afraid to contact you?

Also, you seem to claim that it is normal and accepted that one should
trust unsigned glue records from a parent for your delegation and that
confirming these records at the child is something that you count on
people not doing?

Seems like .org needs to update an 18+ year old operation policy, and
just to clarify that has nothing to do with this draft as .org already
has this problem.

Paul

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2020 16:43:38 -0400

On 30 Jul 2020, at 16:36, Paul Wouters <[email-masked]> wrote:

> 50 domains in a few million is a corner case :)

There are some 20,000 examples in the ORG zone, of which at least 7,000 are due to the domain suspension mechanism I gave as an example. There are lots of well-functioning domains that would fail if all of those A/AAAA records suddenly stopped resolving.

> That is exactly what my "quite imprecise" text said :)

No, your imprecise text used had hostnames serving domains and A records being serviced. Those could mean any number of things.

> BADDOMAIN.ORG and/or GOODDOMAIN.ORG

There should be none for BADDOMAIN.ORG <http://baddomain.org/> in that example, but there may be for GOODDOMAIN.ORG <http://gooddomain.org/>.

> Clearly not many people are querying for BADDOMAINS.ORG, or they are

Well, I don't know that that's clear. I think it's fair to say that the majority of queries we receive at the ORG servers do not come from unbound servers (they come from operators that we know do not run unbound), so the other way of phrasing what you said is that most people who are querying for BADDOMAINS.ORG <http://baddomains.org/> will have no problem at all, even if the specific cases of queries handled by unbound with that specific configuration are handled differently.

> confirming these records at the child is something that you count on

I'm not sure where you think I'm making a claim of any kind. I'm simply pointing out what happens on the actual Internet.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Jul 2020 13:44:57 -0700

On Thu, Jul 30, 2020 at 1:21 PM Joe Abley <[email-masked]> wrote:

> If BADDOMAIN.ORG is suspended (or if the domain is suppressed for some
> equivalent reason) then the zone cut betwen ORG and BADDOMAIN.ORG will be
> removed (the BADDOMAIN.ORG NS set will disappear) but the A record above
> will remain, since it is linked to another domain, GOODDOMAIN.ORG, that
> depends upon it. Without a zone cut, that makes the ORG servers
> authoritative for the A record.
>
> To a certain extent, this behaviour is a consequence of (a) the venerable
> operaetional need to suspend domains because they have been implicated in
> abuse and (b) the EPP data model used in the ORG registry, which itself has
> its origins in the RRP data model used before the re-delegation of ORG to
> PIR in 2002. As such, it's tempting to assert that the behaviour is a
> contractual requirement shared with all other gTLDs that are operated
> subject to the same contract that exists between PIR and ICANN, hence my
> question about applicability.
>
>
Yes, this does appear to be driven by EPP (the data model and the RFCs for
said), although it is not completely clear whether the policy choice of
keeping vs suspending the NS1.BADDOMAIN is a contractual requirement (it
probably is), since the EPP spec discourages but does not forbid
suspension/deletion of these NS glue records.

Clearly, removing those glue records would cause the other delegations to
fail, and possibly for other domains to become unresolvable.

So, this points to an area of overlap between policy and technology, where
alternative implementations of maintaining the ability to resolve the other
domains, might be possible by making other technology choices.
E.g. changing the name of the object N, to make it subordinate to some
other domain, while the suspension is operative, e.g. by using the other
domain (E) as the parent in place of the suspended domain (D).

Clearly, changing that would likely require policy changes for any
contracts that currently would not permit that change, as well as
modifications of the EPP spec.
The latter would not (I don't believe at least) be done in DNSOP.

However, is it appropriate to discuss the requirement or request to have
the EPP spec (and contracts) changed, as a topic for DNSOP?

Do we know how many contracts would be impacted? Are those all strictly
from the 2002 era?
Or does anyone know if more recent contracts include similar language, and
what rough order of magnitude of contracts would be impacted?
E.g. If the number of contracts is O(12), vs O(1000), the conversation is
likely to be very different.

Brian

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2020 16:46:19 -0400

> just to clarify that has nothing to do with this draft as .org already

Again, I'm not a lawyer, but I think what we are doing is a consequence of the contract we have to operate the ORG registry. If that's right you are of course entirely at liberty to engage through the ICANN bottom-up policy-development process to advocate for individual contract changes for the 1,500 or so TLDs that are operated under essentially the same contract.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2020 17:10:30 -0400 (EDT)

> My sense is that this is a nice idea in theory but doesn't solve a problem that anybody actually has, and the camel is starting to look a little bit fraught. But I don't think any proposal should s…

This proposal is meant to increase the amount of trust people can place in
DNSSEC by decreasing the hard trust that is currently required of ICANN,
Verisign and the TLD operators. I understand in our community, we do
not see this as a big problem. Unfortunately outside our community it is.

It is further interesting that you raise your point of "the risk analysis
shows we can never afford to deploy this" when a few months ago you
raised the reverse point that "we dont want to be forced to have to use
this to be seen trustworthy". Both arguments cannot be true.

As for the DNS camel, we are talking about 1 bit and many 20 lines of
code in the resolver. Looking at the rest of the current drafts in
DNSOP, I think this isn't going to break the camel's back.

As for your single issue, the glue issue, you could also change your take
down system.  You could bring up a take-downXXX.org. zone and update
the NS glue for the GOODDOMAINS.org to use that, give out the original
IP and sign it with take-downXXX.org's key. It would even work with
resolvers that insist on hardening and confirming glue, so you would
actually improve your .org deployment independently of this draft.

What I'm trying to avoid is adding complexity to support this already
unstable "run on glue" domains. Sure, we could add an exception for
A/AAAA since these records are of low value to protect because onpath
attacks can just NAT/route it to them anyway, but doing so would
actually increase the complexity of the code and muddle the expectation
of the protetion of "delegation only" zone.

Paul

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 30 Jul 2020 16:33:40 -0500

> Again, I'm not a lawyer, but I think what we are doing is a consequence of the contract we have to operate the ORG registry. If that's right you are of course entirely at liberty to engage through…

ICANN procedures and hence application process for new gTLDs have 
specific text/question to address the handling of "orphaned glue 
records" in the registry zonefile, in the sense that the operator needs 
to document what it does, which probably hints at the fact that there is 
no one size fits all solution here.

Question 28 of 
https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf
is:

Abuse Prevention and Mitigation: Applicants should describe the proposed 
policies and procedures to minimize abusive registrations and other 
activities that have a negative impact on Internet users. A complete 
answer should include, but is not limited to:

[..]

Proposed measures for removal of orphan glue records for names removed 
from the zone when provided with evidence in written form that the glue 
is present in connection with malicious conduct (see Specification 6);

</quote>

There is even a SSAC comment on this too.
[SAC048]: 	SSAC Comment on the Orphan Glue Records in the Draft 
Applicant Guidebook (12 May 2011)

https://www.icann.org/en/system/files/files/sac-048-en.pdf

Note specifically this part:

Orphaned glue can be used for abusive purposes; however, the dominant 
use of orphaned glue supports the correct and ordinary operation of the 
DNS.  Thus it is inappropriate to include the management of orphaned 
glue under the rubric of "abuse prevention and mitigation" and we 
suggest that it be removed

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 30 Jul 2020 16:55:14 -0500

On 30/07/2020 15:44, Brian Dickson wrote:
> 
> 
> On Thu, Jul 30, 2020 at 1:21 PM Joe Abley <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     $ORIGIN ORG.
> 
>     BADDOMAIN NS ...
>     BADDOMAIN NS ...
>     GOODDOMAIN NS NS1.BADDOMAIN.ORG <http://NS1.BADDOMAIN.ORG>.
>     GOODDOMAIN NS ...
> 
>     If BADDOMAIN.ORG <http://BADDOMAIN.ORG> is suspended (or if the
>     domain is suppressed for some equivalent reason) then the zone cut
>     betwen ORG and BADDOMAIN.ORG <http://BADDOMAIN.ORG> will be removed
>     (the BADDOMAIN.ORG <http://BADDOMAIN.ORG> NS set will disappear) but
>     the A record above will remain, since it is linked to another
>     domain, GOODDOMAIN.ORG <http://GOODDOMAIN.ORG>, that depends upon
>     it. Without a zone cut, that makes the ORG servers authoritative for
>     the A record.
> 
>     To a certain extent, this behaviour is a consequence of (a) the
>     venerable operaetional need to suspend domains because they have
>     been implicated in abuse and (b) the EPP data model used in the ORG
>     registry, which itself has its origins in the RRP data model used
>     before the re-delegation of ORG to PIR in 2002. As such, it's
>     tempting to assert that the behaviour is a contractual requirement
>     shared with all other gTLDs that are operated subject to the same
>     contract that exists between PIR and ICANN, hence my question about
>     applicability.
> 
> 
> Yes, this does appear to be driven by EPP (the data model and the RFCs 
> for said),

Only if you take the "hosts as objects" case (where any hosts to be used 
as to be provision like a domain but by just providing, in some cases, 
some IP addresses), which is only one of the two, the other being "hosts 
as attributes (of a domain object)"

The problem is similar to the following:

- registrar A is sponsor of domainA.example
- this domain has (not necessarily using them) hosts 
"ns1.domainA.example" and "ns2.domainA.example"
- at some point, registrar B creates domainB.example ...
using ns1.domainA.example and ns2.DomainA.example

Now, registrar A CAN NOT delete domain domainA.example anymore because 
it has "child" nameservers used elsewhere and if he could do that we are 
back to the "orphaned glue records" problem.
It can not for the same reasons delete the nameservers themselves, just 
update their names or IP addresses.

There are various solutions, all bad in some aspects:

- let the registrar A eat the bill (of domainA.example being renewed 
forever) and that is all
- convince registrar B to change the delegations (and no matter what 
amount of garbage you put in the zone server by those nameservers it 
would still not guarantee anything is changed)
- have nameservers be changed in their hostnames, so that after the 
domain can be deleted as not having child nameservers anymore; this 
works only in the "hosts as objects" case above and not always as change 
of hostname is not implemented by all registries or with restrictions 
like not internal->external renaming
(which is also a major arguments by registrars to dislike the hosts as 
attributes case)
- have the registry let the domain be deleted and then have domainB be 
broken (which it is already in a way since the delegations to those 
nameservers can be explicitly made broken; but the difference is between 
registrar A breaking registrar B stuff, or the registry breaking 
registrar B stuff).

> the EPP spec (and contracts) changed, as a topic for DNSOP?

The above problems, for me, are only loosely related to EPP.
You could use any other provisioning protocol (if it existed) and have 
the same problem of DNS management.
The problems comes more from having a single space (the registry 
zonefile) be managed by multiple actors (registrars), collaboratively 
but also in competition.

> Or does anyone know if more recent contracts include similar language, 
> and what rough order of magnitude of contracts would be impacted?
> E.g. If the number of contracts is O(12), vs O(1000), the conversation 
> is likely to be very different.

See my other message where I quote ICANN resources where this question 
is part of the application of any 2012-era gTLD operator.

-- 
Patrick Mevzek

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2020 17:57:54 -0400

> not see this as a big problem. Unfortunately outside our community it is.

Can you provide some information about that? I think it would be helpful to understand the problem that people are bothered by.

> this to be seen trustworthy". Both arguments cannot be true.

Well, I didn't say that we can never afford to deploy anything. Clearly we can deploy lots of things all the time. I think I've explained why we couldn't just turn this on in ORG right now, and so a requirement to do so would be a problem.

The lines of code to be added to particular implementations are not the only measure of complexity in deployment, however. We don't have a good handle on all the software that exists between application and authority server, nor how it interacts. There are costs in resolution failures that appear intermittent because they happen with some applications, networks or hosts but not others, assuming that it is deployed anywhere.

If the technical difficulties for particular registries like ORG can be circumvented but the benefits are not obviously compelling, then there's the question of why any commercial registry would implement this proposal. If it needs to happen as a contractual obligation, then that means contract changes and although that's very much not my area, my sense is that that's a fairly heavy ball that needs to be rolled up a steep and tall hill. That sounds like a cost to me.

Without widespread implementation, I'm not sure how the problems (admittedly, problems that I don't really understand) will actually be addressed. The costs will remain, however. And right now I haven't heard a single example of a TLD that might be in a position to implement this (not saying there isn't one, just that I haven't heard an example).

Joe

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 30 Jul 2020 18:25:04 -0400

I want to reiterate that I support the goal of this draft.  I just think
the claimed benefits need to be more precise.  I think Petr is right: this
is mostly because we don't agree on what transparency looks like.
Specifically, we need to understand both (a) what transparency logging
requires without this flag and (b) how it is easier with this flag, in
order to compare them and identify the benefit.

Take .org as an example.  Per Joe's description, .org is not
DELEGATION_ONLY, but it is "mostly delegation only".  Knowing this, we can
start transparency-logging the org zone.  The DELEGATION_ONLY flag isn't
needed, and wouldn't substantially help, for this single case.

I think this flag does help overall.  For example, assuming we can make it
usable by some TLDs, I think it is a sufficient indicator that a TLD is
suitable for logging, avoiding the human effort of investigating those
TLDs' practices.  (I also think it greatly reduces the chance of
_accidental_ impersonation, which might be enough justification on its own.)

With or without this flag, I think we'll also want to log many zones that
are "mostly delegation only".  We might even need a different flag that
says "this zone is suitable for logging", or the inverse, but has no effect
on the resolution process.  Alternatively, perhaps those zones can be
curated manually out-of-band, like the PSL.

...

>From this conversation, it seems like these attacks are achievable, and are
detectable by logging, with or without the DELEGATION_ONLY flag.  I was
trying to understand if the flag can sometimes _prevent_ the attack, e.g.
when there are cached DS records.  However, a prevention claim requires
much more text on possible attack modes (e.g. can the parent shorten TTLs
to enable the attack?).

> attacks in response to specific queriers is harder.

That seems like an important mitigation.  Does this rely on the attacker
inserting "deep" Additional records?

> whether the attacker has to

You said above that this flag "prevents" targeted attacks, but I think here
you are saying that it only _deters_ these attacks, provided that logging
or monitoring is in place.  (I don't really understand the difference
between logging and monitoring.)  I want this deterrence!  I also want to
be precise about the motivation.

...

> to ensure no queries every violated the implicit delegation-only role.

I don't understand.  What privacy implication would apply to contentful
zones, but not to delegation-only zones?  In my experience, the main
privacy concern expressed by zone owners is about the list of names, not
the content of any records.  (Hence NSEC3, NSEC5, etc.)

If I believe that names under corp.mycompany.example are supposed to be
secret, then presumably I don't want them showing up in public logs due to
an overzealous stub resolver on my network.  Yet there's no reason
corp.mycompany.example couldn't be DELEGATION_ONLY.

> entries become a supercookie by

I don't think that helps.  A website at example.com can easily put $
userid.example.com into your local (and recursive) cache, with long TTL,
CNAMEd to example.com.  Then, it can remove $userid from its zone.  From
now on, when a client connects via a different recursive, example.com can
check if it's you, by telling the client to connect to $userid.example.com.
If that works, you must be the same user.  (Fancier variations can scale
better.)

This is off-topic except to say: the caching recommendation is not obvious,
is not necessary, and should go in a different draft (if it is indeed the
group's consensus).

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Jul 2020 23:30:09 +0100

John Levine <[email-masked]> wrote:
> > Has anybody done a survey to find out how many TLD zones actually
> > fits the description of "delegation-only"?
>

If there are RRSIG(A) records in .com and .net there must have been a
policy change since 2010?

There was a very subtle behaviour tweak implemented by Verisign for orphan
glue aka host objects that have lost their domain objects: although the
address records appear in the zone file, the name servers do not answer
queries for them authoritatively: the addresses only appear in additional
sections in referrals, and are not signed according to this:

https://seclists.org/nanog/2010/Jan/298

I don't know if other nameservers implement the same behaviour. AFAIK it
isn't possible to represent orphan glue in standard zone files or zone
transfers, so I think this is an ATLAS special.

Also despite having discussed this several times before I have not
previously thought properly about how signing such a zone works! I suppose
the assumption is that most resolvers are delegation-centric by default so
they won't normally come back to validate the glue in the referral and
won't discover it has been orphaned. So it usually won't matter if
gtld-servers.net return an NSEC3 opt-out denial in response to a direct
query for an orphaned glue record..

Maybe an NSEC3 opt-out covering these address records is enough to imply
that they are orphan glue without needing new zone file or zone transfer
syntax...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: West backing southeast 2 to 4, increasing 5 or 6 later. Slight or
moderate. Occasional rain. Good, occasionally poor in north.

---

From: "John R Levine" <[email-masked]>
Date: 30 Jul 2020 19:59:09 -0400

> policy change since 2010?

Sorry, no, they're different.  For all of the new TLDs they run they have some test
delegations with name servers in the TLD:

emt-ns1.emt-t-1113662392-1595861228527-2-sdojq.aol.	172800	in	a	198.41.1.168
emt-ns1.emt-t-1113662392-1595861228527-2-sdojq.aol.	172800	in	rrsig	a	8	3	172800	20200804181604	20200728181604	32545	aol.	h+iuDHDjmnr5a0egcjKDSiGxSyYe9O4UVJVOL8F3ttqwv31PnNnWyxFoa9k8gyGGBB6155jbJExvCY4KxqHqYPKylVw5Br/zfbFCfXD+wpMEmxHvQbRkDtK7AZBSLNunPl8gJ+WmywX8LVXhjobWCo9VGMogVKJz+cRcFKu/PY97fOzQbnNJBkF473zoPNX0Ct+2C/5QSEd5OYSIVfD2iA==
emt-ns1.emt-t-1158551749-1595861079980-2-xo.aol.	172800	in	a	198.41.1.126
emt-ns1.emt-t-1158551749-1595861079980-2-xo.aol.	172800	in	rrsig	a	8	3	172800	20200804175637	20200728175637	32545	aol.	a4ij0JWJZlHXbPR+At9pYnTrWwpyFI12ubSnMmZ6PhlK4Sed5v64mzVy8QAmbgAtT2kNJqLW/weG4ZGHQDzN/oTYo2+NhLYpqf9/r1CBaX1V3As17lOSx5I7nm5aeKIupYnyMBb/h5NyxIh/7pbYT4fd+AtENKIt1Va+TAsZPBcL6a9dqcajRpnQ3Fx9Tq9QQJQC38sfHEK2X4fjRCF3/w==
emt-ns1.emt-t-1737294735-1595858930228-2-jz.aol.	172800	in	a	198.41.1.92
emt-ns1.emt-t-1737294735-1595858930228-2-jz.aol.	172800	in	rrsig	a	8	3	172800	20200804171915	20200728171915	32545	aol.	FiTCAdK7jDWig2s0Y/duIsKuM86BOoe4jEcYLh9eEI1swnPKmUTWY9aM5xCFr9yqTlWHDz5cX3WzivizMqbhOa7LorQuIU359bh2z9FOk1MWZrhLUk5jhBW8tLT+Lj6lNe8rN4kmfVAU3ScBJ8X+pfALYACkoHdIuZs74fvspxiO/DF7EOH88mmyedyFiZA0NtOzN4lfFLDkPqUgKQL+8g==
emt-ns1.emt-t-1919814529-1595856863287-2-rflv.aol.	172800	in	a	198.41.1.111
emt-ns1.emt-t-1919814529-1595856863287-2-rflv.aol.	172800	in	rrsig	a	8	3	172800	20200804165227	20200728165227	32545	aol.	WtEXPHu8fXQ3hDK6qVOmHbcRDMKsXTG2Q3qlJh10zyUCAFATsSvaZtHvmFZX60EvzB5H9qOATjmhd4ondDAoHwwS5+vn2Q8+Gtwl8lbMgv97OjtZTyf+KDKf7zsS+h7+rQtL8xOHSZp04uB6bTGscE7FoFVnXtGLC8efJPpGcIEvXtqx1CQMmA+OfY6Fkff6a0+qD3ZECCWtLbc/KI3pnw==
emt-ns1.emt-t-2040593332-1595870898209-2-fjmc.aol.	172800	in	a	198.41.1.65
emt-ns1.emt-t-2040593332-1595870898209-2-fjmc.aol.	172800	in	rrsig	a	8	3	172800	20200804215349	20200728215349	32545	aol.	CKITWMU4hsaZz9sDYLPZOdnqPrGucEb82tPrFe7AUnsKC8uc20OwpaWBZsKiljm1J3khT7LuZFfLpvAC4Ma4c7DFXZBlJU0vwV4ONk5+M6+Ne+kiIYr8FfdAZy/UfgO0PYY0bqFYADINjxhAAcUPabgDQXmyjgHMLJmSXHibCWlD7rNhGbSYnHk2HYljhB3F5Qr5M/9JbgSXySq2XAdVQQ==
emt-ns1.emt-t-320674882-1595861934204-2-ngoj.aol.	172800	in	a	198.41.1.109
emt-ns1.emt-t-320674882-1595861934204-2-ngoj.aol.	172800	in	rrsig	a	8	3	172800	20200804183500	20200728183500	32545	aol.	OFH8JEJioRiVjLm9eP2Dxgncj064Mevm9QAV0/Ybj8p0HhhEehlKvwazcTSCymLHN2eKiw8b9jN3Lfvpy2PEh2yXGM+GzJ5/eTLO0RLGV2PuaXYGiFbgze8j48ROw+W9FD7LdP33U2vGXwmn8aHaIAuCvzoIHQAUnDgKTJK9zQYzYj51Ltx0zFZGtibsafKwMvRI7fJcbJgApAJ89tjaSQ==
emt-ns1.emt-t-645432105-1595875144963-2-p.aol.	172800	in	a	198.41.1.80
emt-ns1.emt-t-645432105-1595875144963-2-p.aol.	172800	in	rrsig	a	8	3	172800	20200804233833	20200728233833	32545	aol.	KVOc4xcORtulWDbaMxMBATKmBxPz2BKTozKsh9hWmxqAYuJviwRSfFDthojzIWc1rHJocAWTf/0pwQVhYvWeK1w5LH+4v33VxzGOlQKTBYr20etIgChS5JK7ohH4PsZPK0juk+1mvFHoD7DJYeGv3XIkXOEs4+cdsbIOD9hBnWh4OrihJdPGPZIzpiMG21Nplc5CFP+uOGbPZPtdqqdJEQ==
emt-ns1.emt-t-706490806-1595861285174-2-gmk.aol.	172800	in	a	198.41.1.117
emt-ns1.emt-t-706490806-1595861285174-2-gmk.aol.	172800	in	rrsig	a	8	3	172800	20200804182723	20200728182723	32545	aol.	InRAqN/asgig+58aeUI4AqCP7QgMdK/Xr/5soEYRnvUdqXdD6s9vSqVDWhZzbdBNocKnoMo1WBiYUIMBvPoUGCMnAjCuKq5hze654pZAoiQYFatnE+AhNgkRqGdglvlSrP6ou7igOmPOAlMlEgmnwV3psVMJeaAdXI2Zx/460TLSYougRqS9/gCPf5hfinXiRpf4l2InnRypGU25ARapdw==

> transfers, so I think this is an ATLAS special.

Nothing special there, orphan glue that isn't under a delegation is
just an ordinary A record. I suppose they could do an nsec3 opt-out to
provide a hint that it's intended to be glue, but who'd care?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Jul 2020 18:01:21 -0700

On Thu, Jul 30, 2020 at 1:44 PM Joe Abley <[email-masked]> wrote:

>
> There are some 20,000 examples in the ORG zone, of which at least 7,000
> are due to the domain suspension mechanism I gave as an example. There are
> lots of well-functioning domains that would fail if all of those A/AAAA
> records suddenly stopped resolving.
>
>
> I realize this is close to going down a rabbit/rat hole, so I'll try to
keep it as focused as possible.

Those two numbers (7000 and 20000) raise a question in my mind:
What's the typical range of domains impacted for each suspended domain?
I.e. given BADDOMAIN and GOODDOMAIN_1 through GOODDOMAIN_N, what would the
median value of N be, and the max or 95%ile value of N?
(I'm guessing it would be easier for you to get the answer than it would be
for me.)

The reason to ask is, what is the reasonableness of alternatives to the
current method depend? Those very much on the expected size of N.

If N is most typically about as many fingers as there are on one hand, that
suggests that changing the glue for the remaining domains, on a per-domain
basis, is not an unreasonable amount of work.
(I.e. replace all instances of "NS NS1.BADDOMAIN.ORG" with "NS
NS1.GOODDOMAIN_1.ORG", and replace NS1.BADDOMAIN A <value> with
NS1.GOODDOMAIN_1 <value> everywhere it occurs in the ORG zone.)

It's unclear whether this crosses the line of what registrars should do vs
what registries should do.
If the "suspend" action is not literally accompanied by the registrar doing
the removal of the NS records, then the (temporary) renaming of the object
by the registry on behalf of the registrar(s) involved, would seem to not
be unreasonable.

It keeps the GOODDOMAIN_N delegations functioning, and avoids promoting
glue to authoritative.

Of course, the OTHER question is, of those 20000 instances, in how many of
those cases is the registrant for BADDOMAIN and GOODDOMAIN_N the same
party? Is the expectation of the registrant that their error (lapse) or
action (abuse) on BADDOMAIN should not also have the same impact on the
related domains operated by the registrant a reasonable expectation?
(That's probably a lawyer question.)

I'm happy to stick to the technical aspect, on the renaming option: for
each suspended domain, what is the number of domains sharing a nameserver
below the delegation point, and thus how many actual renaming things and
address substitutions would be expected/required?

Brian

---

From: "John Levine" <[email-masked]>
Date: 30 Jul 2020 23:56:15 -0400

>just to clarify that has nothing to do with this draft as .org already

I believe that every public contracted TLD does the same sort of
suspensions that .ORG does since they all have similar contracts. I
wouldn't bs surprised if a lot of ccTLDs do too, since many have their
policies similar to the gTLD ones.

Having just come back from yet another fight over DMARC, I am
extremely unsympathetic to arguments along the lines of "your reality
doesn't match my clever hack, therefore your reality must change." In
this case I can't imagine the TLDs changing since that would require
changing both ICANN contracts and the complex and messy EPP system
used to manage TLDs.

I think the reasonable approach here is to stop further consideration
of this draft until Paul can survey the existing TLD practice and see
how many TLDs really are delegation-only.

R's,
John