Subject: [DNSOP] New draft on delegation revalidation

From: Shumon Huque <[email-masked]>
Date: Fri, 10 Apr 2020 09:45:30 -0400

Hi folks,

Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
consideration:

   https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01

I mentioned it on the [email-masked] mailing
list last week, where the topic came up in another thread,
and there has already been some lively discussion about it
there. So we recommend reading the thread there:

https://lists.dns-oarc.net/pipermail/dns-operations/2020-April/020041.html

There is a range of different behaviors in resolver implementations
in this respect today, and it would be good if we could agree on
more commonality.

The main recommendations in the draft are to: (1) deterministically
prefer the authoritative child NS set over the non-authoritative,
unsigned, delegating NS set in the parent, (2) revalidate the parent
delegation at the expiration of the parent NS set TTL, to promptly
detect when the parent has re-delegated the zone elsewhere (or
removed the delegation).

These are not new ideas of course. They have been proposed in Vixie
et. al.'s resimprove draft from 2010, and Wouter Wijngaard's resolver
mitigations draft from 2009. The Unbound resolver already mostly
implements this with the 'harden-referral-path' configuration option.

Comments/discussion welcome.

Shumon, Paul, and Ralph.

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 10 Apr 2020 11:52:54 -0400

(as a chair)

I enjoyed reading the thread on dns-operations, and as a chair,
both Benno and we like where this is going.

(consider this a gentle nudge working group this is relevant to
our interests)

thanks Shumon/Ralph/Paul

tim

On Fri, Apr 10, 2020 at 9:46 AM Shumon Huque <[email-masked]> wrote:

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

---

From: Bob Harold <[email-masked]>
Date: Fri, 10 Apr 2020 12:51:31 -0400

Having read through the draft, and twice through the emails, I think the
draft has the right balance in using the parent and child NS RRsets
properly.

I think the "extra" query for the child NS, sent once per parent TTL, is a
savings over the older method of sending the NS records as "additional
data" in every response.

-- 
Bob Harold

---

From: Brian Dickson <[email-masked]>
Date: Sat, 11 Apr 2020 00:12:18 -0700

> Comments/discussion welcome.

There is one issue not addressed (here or anywhere else) that is
operationally relevant.

If a domain's delegation NS set includes name servers that no longer act as
authoritative servers for the zone, there is no adequate mechanism to
signal to the parent zone or to resolvers that this is a permanent
situation.

The delegation (re)validation might be a reasonable place to implement
something to detect this and adjust the choice of NS on the resolver's
cache.

(Part of the problem maybe be a "catch 22": the server receiving the query
isn't authoritative for the zone, so technically it can't/shouldn't return
anything authoritatively.)

This might also be viewed (correctly) as a corner case in the RRR model
that doesn't get addressed; it seems to happen most frequently if a
registrant changes registrars or if a domain lapses, where the previous
registrar also acted as DNS operator for the zone.

Thoughts? (Not sure if I did justice to the explanation; qv "lame
delegation".)

Brian

---

From: Shumon Huque <[email-masked]>
Date: Sat, 11 Apr 2020 09:22:42 -0400

On Sat, Apr 11, 2020 at 3:12 AM Brian Dickson <[email-masked]>
wrote:

> If a domain's delegation NS set includes name servers that no longer act
> as authoritative servers for the zone, there is no adequate mechanism to

True, but is the DNS protocol the right place to perform this function? And
how would one know that this is a permanent situation or just a temporary
misconfiguration ? I assume only the child zone operators would know that.
My feeling is that these are configuration problems that are best handled
outside the protocol (e.g. via proactive monitoring by the parent/child
parties involved).

> something to detect this and adjust the choice of NS on the resolver's

I think most resolvers do a bit of this today already. If they detect a
broken delegation, they will mark that server as lame, and remove it from
the candidate nameservers for the zone (for a certain period of time), and
try another one. They don't however systematically query the entire NS set
to identify all of the lame ones.

> anything authoritatively.)

Right.

> registrar also acted as DNS operator for the zone.

I've heard proposals in the past that TLDs should routinely scan all their
delegations to identify such problems, but I gather this is a challenging
requirement to impose on them for various reasons.

Shumon.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 11 Apr 2020 18:30:41 +0200

On Sat, Apr 11, 2020 at 09:22:42AM -0400,
 Shumon Huque <[email-masked]> wrote 
 a message of 138 lines which said:

> > The delegation (re)validation might be a reasonable place to
> > implement something to detect this and adjust the choice of NS on
> > the resolver's cache.
> 
> try another one.

I don't think that you answer Brian's idea. The way I've read his
idea, he suggested, when a resolver detects a lame server (or when all
servers are lame?), to go back to the parent and to ask again the NS
set, to see if there is a new and better list.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 11 Apr 2020 18:34:02 +0200

On Sat, Apr 11, 2020 at 09:22:42AM -0400,
 Shumon Huque <[email-masked]> wrote 
 a message of 138 lines which said:

> I've heard proposals in the past that TLDs should routinely scan all
> their delegations to identify such problems, but I gather this is a
> challenging requirement to impose on them for various reasons.

Also, delegation is not only done by TLDs. The problem, already huge
with only the TLDs, would be even worse with all the delegating
domains.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 11 Apr 2020 13:02:07 -0400

> set, to see if there is a new and better list.

Fair enough. If all the servers are lame, that sounds like a reasonable
strategy.

If only some are lame, and there are still usable servers available, I
suspect resolver implementers won't want to revalidate to avoid the
potential additional performance/latency costs.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 11 Apr 2020 13:07:18 -0400

> with only the TLDs, would be even worse with all the delegating

Sure. Brian was asking specifically asking about the TLD case, so my
answer was in that context. For that space, I think one of the issues is:
even if they were willing to verify all the delegations, it isn't clear what
they are permitted to do about it, beyond notification to the registrants
(or so I've heard).

Shumon.

---

From: "John Levine" <[email-masked]>
Date: 11 Apr 2020 13:57:36 -0400

>they are permitted to do about it, beyond notification to the registrants

Remember that in ICANN contracted TLDs and in some ccTLDs, a registry
can only contact registrants by going through the registrars.  While I
can imagine some hack (EPP probably) for the registry to tell the
registrar about inconsistent NS, I don't see the point.  The lousy
registrars won't care, the good ones could check and notify themselves
if they want to.

I suppose you could make a general observation that DNS operators can
check for inconsistent NS and when practical warn the child operator
but that sounds like "don't forget to brush your teeth" sort of advice.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Apr 2020 19:39:52 +0000

On Saturday, 11 April 2020 13:22:42 UTC Shumon Huque wrote:
> ...

i think it's a corner case in the registry / registrar / registrant (RRR) 
model, as you say. what might be done here is that ICANN or DNS-OARC or the 
registry of last resort (ROLR) or perhaps all three in cooperation, could 
jointly operate an anonymizing reporting service to accept real time reports 
of lame delegations from participating full resolvers.

in this case open source resolver makers such as nlnetlabs, cznic, isc, 
powerdns, and perhaps some commercial resolver makers like nominum and 
microsoft, and perhaps even some of the so-called "public dns" providers 
(quad-this, quad-that, etc) could report delegation problems they discover, in 
real time, to be then sliced and diced and trended and published and 
especially made available to registrants, registrars, and registries for 
policy-appropriate remedial action.

this is off-topic for the draft at hand, but it's something a strong mature 
distributed naming system ought to have in it. we finally have enough CPU and 
enough bandwidth and enough competing cooperators (and enough cooperating 
competitors) that it's practical to build something like this.

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Apr 2020 20:11:00 +0000

> potential additional performance/latency costs.

if this is part of a larger strategy of lame delegation holddown, i think it's 
a good idea and even in-scope for the current draft. but without the holddown, 
it becomes a DDoS against the delegating zone's authority servers. (BIND4 had 
that at one point, and it was un-pretty.) when revalidation fails, we can 
argue whether to "rm -r" the cache contents at that delegation point, but we 
must always prevent subsequent revalidation for a period (randomly chosen) in 
a range of several minutes.

-- 
Paul

---

From: Puneet Sood <[email-masked]>
Date: Mon, 13 Apr 2020 15:21:02 -0400

+1 to the dnsop WG adopting this document.

I have not read the document fully yet but will be commenting on it.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 13 Apr 2020 16:36:44 -0400

I read the draft and like it, this is a clear statement of the problem and
good way forward.
I agree with the idea that "all" NS are lame is a good signal to
revalidate,

One idea to throw out here triggered by the first two paragraphs in section
3
Should we recommend that Authoritative servers that are configured for
minimal-response overwrite that on DNSKEY query and include NS RRset if
there is space ?

Olafur

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Shumon Huque <[email-masked]>
Date: Mon, 13 Apr 2020 16:55:47 -0400

> I read the draft and like it, this is a clear statement of the problem and

Thanks Olafur!

> I agree with the idea that "all" NS are lame is a good signal to

Yeah, me too. But as Paul later notes, I think we'd need a hold time timer
of some sort to prevent the parents from getting DDOS'd by resolvers caught
in a tight revalidation loop. We could recommend a timer value in the draft.

> minimal-response overwrite that on DNSKEY query and include NS RRset if

Worth considering. That would be a very useful optimization if everyone
was doing it from the start. But it suffers from the incremental deployment
problem. Since resolvers can't know who might be doing this in advance, if
they want to minimize latency, they'd still need to fire off the NS query in
parallel with the DNSKEY.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 13 Apr 2020 16:56:56 -0400

> I have not read the document fully yet but will be commenting on it.

Thank you Puneet - we look forward to your comments!

---

From: Shumon Huque <[email-masked]>
Date: Mon, 13 Apr 2020 16:59:03 -0400

> savings over the older method of sending the NS records as "additional
Thank you Bob. I just want to qualify your last observation a bit - the
extra query would be once per minimum of parent and child TTL, roughly.

Shumon.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Apr 2020 10:04:17 +1000

> On 12 Apr 2020, at 03:57, John Levine <[email-masked]> wrote:
> 
> can only contact registrants by going through the registrars.  

So they sent the notices via the registrar.  There is nothing preventing
that.  Just a unwillingness to exercise the path.  Registrars that fail
to pass on notices would, I presume, be in breach of contract.

> While I

The parent zone operators are already required to perform the checks (see
STD 13).  Just because many have been too lazy to do so doesn’t excuse them
of the responsibility they took on when choosing to manage the zone.  Now
if they want to amend the contract they have with the registrars so that
they do they checks they are free to do so but they still have to ensure
the checks are done.

"As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.”

I don’t see “unless you are a TLD operator” in there as a exemption.  The
“and remain so” implies the regular checks need to be made.  The instructions
clearly require “both sides” to check and take steps remedy inconsistencies.

The requirement to communicate through a registrar is not a “get out of gaol
free” card.

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

---

From: "John R Levine" <[email-masked]>
Date: 13 Apr 2020 21:48:02 -0400

> that.

Actually there is -- there's no mechanism to do so.  Registries and 
registrars communicate with EPP, and it doesn't have a "hey your customer 
is lame" feature.  You can propose an EPP extension in the regext WG but I 
wouldn't get my hopes up.

Also, as I said, some registrars would ignore them, the ones that care can 
check lame NS as easily as the registry can, so what's the point?

> glue RRs which mark both sides of the cut are consistent and remain so.”

This sort of stuff is not helpful.  We have decades of experience that 
tell us what registries and registrars will and won't do, mostly won't.

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

---

From: Bob Harold <[email-masked]>
Date: Tue, 14 Apr 2020 11:23:25 -0400

On Mon, Apr 13, 2020 at 4:59 PM Shumon Huque <[email-masked]> wrote:

>> I think the "extra" query for the child NS, sent once per parent TTL, is
>> a savings over the older method of sending the NS records as "additional
>> data" in every response.
>>
>>>
>>>

Ah, yes, thanks for the correction.

-- 

Bob Harold

---

From: Gavin McCullagh <[email-masked]>
Date: Mon, 20 Apr 2020 10:27:27 -0700

Hi,

I'm new to posting on this list, so please accept my advance apologies if I
make any novice errors or posted this in the wrong place.  Apologies also
for the long email. :-)

I can't claim to have the same detailed knowledge of the protocol as the
authors of this draft.  All the same, I've been mulling this
child/parent-centric resolver question for a while and watching its impact
on our customers and developers.  This draft seems to resolve this question
with the conclusion that child-centric (non-sticky?) is the correct
behaviour.

> in this respect today, and it would be good if we could agree on

I agree.  Having a predictable standard behavior (at least for recent,
well-behaved resolvers) is very desirable.

The recent thread on the DNS OARC list seemed to frame this question as a
trade off mostly of these points:

[a] https://tools.ietf.org/html/rfc2181#section-5.4.1 saying the in-zone NS
is authoritative and more trustworthy.  (pro: child-centric)
[b] flexibility for DNS operators to lower the effective TTL on a
delegation during changes despite registries fixing their TTL.   (pro:
child-centric)
     Paragraph 4 in
https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01#section-2
[c] the additional complexity resolvers will have to bear  (pro:
parent-centric)
[d] making resolution deterministic  (pro: parent-centric)

I'd like to draw attention to a fifth item which I haven't see addressed.

[e] obeying the principle of least astonishment for mortal DNS operators
who do not understand this subtlety (and who I assume are the overwhelming
majority).  (pro: parent-centric)

The child-centric resolver behaviour applied by many resolvers today is
probably clear to most who reads this list and DNS OARC.   But it's very
counter-intuitive to everyone else.  In my experience the overwhelming
majority of people operating DNS do not understand this very subtle point.
They all tend to assume the parent-centric behaviour.  Perhaps that's
because many of them have a software developer background and are familiar
with tree data structures and linked lists.  Put another way, child-centric
resolvers effectively insist on there being two sources of truth for a
delegation, which is very surprising.

My organization tends to operate with every team being enabled (and
expected) to own their own service, including its DNS, so we have a lot of
software developers and others who don't have time or inclination to read
DNS RFCs and books dealing with DNS but still need to do it.  We delegate
domains at multiple levels to give people that autonomy.  We're also a DNS
vendor for many public customers.  I've seen lots of outages and security
issues either caused by or prolonged by people surprised by child-centric
resolver behaviour.   So much so, that I am inclined to prefer
parent-centric.

[a] seems like a definition which could be changed if it was so decided.
DS records are totally parent centric for example.  It seems like NS could
be too if we declared the in-zone NS to be "informational only".  I
understand the desire for [b], but it seems to propose to dictate a
specific behavior at every level of delegation in order to work around a
problem that only exists with second level delegations (those managed by
registries).  In so doing, it optimizes for an arcane but admittedly useful
flexibility that only a tiny minority of DNS operators will ever understand
how to use.  At the same time, we'd be standardizing on behavior that
surprises the majority of operators and at times causes them (or at least
leads them into) outages, even when they are working at a 3rd or 4th level
delegation (ie not a registry).

There are two categories of unfortunate "surprises" we commonly see due to
child centric resolvers.  The first surprise is that when redelegating a
third level domain, it's obvious to moderately experienced operators that
they must lower the parent NS TTL in order to get a fast rollback, but as
they don't realise the in-zone NS takes over, they don't lower that TTL.
Now their fast rollback plan is ineffective on child-centric resolvers.
It's great to see in this draft that the "delegation revalidation" section
of the draft seems to solve that sharp edge by choosing the minimum TTL at
the delegation.  If we conclude we must have child-centric behaviour, this
at least makes it safer than today.   But still the misunderstanding points
to the surprising behaviour of child-centric resolvers.   The second
surprise category are a variety of subtle misconfigurations which we have
seen at the in-zone NS which operators don't understand (copying the NS
from the previous zone, altering the NS in an effort to get a full sideways
delegation, just plain errors, etc).  When we explain these problems, our
customers say "but the child NS isn't used for delegation, what are you
talking about?".   "dig +trace" also ignores the in-zone NSes (that could
be fixed of course, but it reinforces how people think about delegations).

It probably shouldn't drive the decision, but choosing parent-centric will
also remove the problems outlined in the draft around non-compliant dns
implementations which don't answer NS or do so incorrectly.  That's not
critical, but it will make life easier.  The original reason those
implementations exist is very likely due to the odd "two sources of truth"
situation we're in.  If the in-zone NS becoms "informational only", that
non-compliance will probably continue, but it will become less of an issue.

So, to summarize, compared with today, I think the draft as written would
be an improvement as it will bring consistency.  Delegation revalidation
will also remove a sharp edge which causes problems for less experienced
DNS operators in a world of child-centric resolvers.  However, on balance,
I would suggest it would be better to optimize for DNS delegations which
are "intuitive for the majority of dns operators" instead of "flexible for
a (tiny?) minority".  I think parent-centric is a better choice for DNS and
I don't think registries should force the DNS standard into making a
Sophie's Choice like this.

I hope this helps,
Gavin

PS How truly intractible is the registry argument?  It seems something like
"When an NS change is made, TTL=3600 for the first N hours, then 2 days
thereafter." would be a major step forward without drastically increasing
complexity.

On Tue, Apr 14, 2020 at 8:24 AM Bob Harold <[email-masked]> wrote:

>> On Fri, Apr 10, 2020 at 12:51 PM Bob Harold <rharolde@umich..edu
>> <[email-masked]>> wrote:
>>

---

From: Shumon Huque <[email-masked]>
Date: Wed, 22 Apr 2020 15:32:25 -0400

On Mon, Apr 20, 2020 at 1:27 PM Gavin McCullagh <[email-masked]>
wrote:

> Hi,
>
> I'm new to posting on this list, so please accept my advance apologies if
> I make any novice errors or posted this in the wrong place.  Apologies also
> for the long email. :-)
>

Hi Gavin, and welcome to DNSOP! :) Thanks for your comments.

> [a] https://tools.ietf.org/html/rfc2181#section-5.4.1 saying the in-zone
> NS is authoritative and more trustworthy.  (pro: child-centric)

A few years ago, when working on another RFC, we were actually having
trouble explaining to some others (in the IETF no less!) that the DNS
namespace and cache were a tree data structure. So I'm pleased to hear this
:)

But appreciating the subtleties of the DNS delegation mechanism involves a
lot of arcane details that are not easy to understand for anyone. If the
namespace is a tree, and zones are contiguous subtrees, how do you a
visualize a zone cut in this data structure? It doesn't cleanly intersect
any node or edge between nodes, but rather partitions the data sets located
at a node in a weird, inconsistent fashion. Most apex RRsets live
authoritatively at the node, but one has a copy in the parent zone, and one
is authoritative in the parent. It's all very complicated.

> delegation (ie not a registry).

Changing (a) properly requires re-designing the DNS delegation mechanism,
and sounds like a much more ambitious undertaking to me. I am actually
interested in looking at that myself, because there are certainly
deficiencies that could be addressed. Since delegation records and glue
address records are unsigned, they can be spoofed, and DNSSEC should really
allow us to detect such spoofing once a resolver sees referral data. And
not (as it now is), after being sent on a wild goose chase to a set of
rogue servers, and subsequently determining that those servers cannot
present a DNSKEY RRset that matches the parent DS. Fixing this, requires
creating a new delegation record type that can be signed in the parent. And
the TTL issue and delegation revalidation would then have to be assessed by
looking at both the child NS set and this new delegation record (although
for secure delegations, the DS set could likely be used in place of the
latter). And then figuring out the large work of how to deploy it Internet
wide.

You are right that the TTL control issue primarily comes up at the TLD/SLD
level, but it is certainly not a corner case or that only affects a small
minority, in my estimation.

> be fixed of course, but it reinforces how people think about delegations).

I would hope that making resolver behavior consistent would address most of
this. If all resolvers locked on to the authoritative NS set, then most of
the surprises would disappear (hopefully).

> thereafter." would be a major step forward without drastically increasing

Based on history to date, it seems to be rather intractable, but I would
love to be proven wrong. The interfaces that registrars use to update
delegation records in the registries don't even offer any TTL configuration
option that I've seen (even if the registries were willing to support it).
Does the EPP DNS mapping even support setting TTL?

Shumon Huque

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 22 Apr 2020 15:48:17 -0500

On 22/04/2020 14:32, Shumon Huque wrote:
> delegation records in the registries don't even offer any TTL
> configuration option that I've seen (even if the registries were willing
> to support it). Does the EPP DNS mapping even support setting TTL?

I am not sure what you refer to by "EPP DNS mapping".

In EPP world there are host objects (or host attributes).
Those are created by the registrar, in the registry system, and the
registry will use them to publish NS records, and potentially glues.

Those objects have name, IP addresses and a few extra meta data but
nothing about TTL.
And when you update domains for new NS you just specify the host object
IDs you want to use (which are in fact there name). For registries using
hosts as attributes instead you then there provide also glues, if
needed, but nothing more.

To give another data point, that goes into your direction, there is a
secDNS extension, that registrars uses to pass DS/DNSKEY materials to
registries, for publication.

It has the following specified:

        An OPTIONAL <secDNS:maxSigLife> element that indicates a
         child's preference for the number of seconds after signature
         generation when the parent's signature on the DS information
         provided by the child will expire.  A client SHOULD specify the
         same <secDNS:maxSigLife> value for all <secDNS:dsData> elements
         associated with a domain.  If the <secDNS:maxSigLife> is not
         present, or if multiple <secDNS:maxSigLife> values are
         requested, the default signature expiration policy of the
         server operator (as determined using an out-of-band mechanism)
         applies.

and

   The <secDNS:update> element contains an OPTIONAL "urgent" attribute.
   In addition, the <secDNS:dsData> element contains OPTIONAL <secDNS:
   maxSigLife> and <secDNS:keyData> elements.  The server MUST abort
   command processing and respond with an appropriate EPP error if the
   values provided by the client can not be accepted for syntax or
   policy reasons.

While those are not TTL per se they are in the same bag: they try to
influence what the registry publishes at the DNS level.

And while most registries implement this EPP extension to do DNSSEC
operations I know of not one of them honoring the above two parameters
(but I can certainly miss some).

So I am pretty sure that even if you defined an EPP mapping to pass TTL
data, very few registries, if not none, would use it. But that is just
my opinion, I am not a registry nor speaking for them.

-- 
Patrick Mevzek

---

From: Shumon Huque <[email-masked]>
Date: Wed, 22 Apr 2020 17:01:02 -0400

> I am not sure what you refer to by "EPP DNS mapping".

I meant the use of EPP for provisioning DNS objects. EPP is a general
purpose protocol, no? And I think it's use for specific applications is
called a "mapping". But my knowledge of EPP is quite meager, so I'd
be happy to be corrected. Thanks for chiming in with the rest of the info!

> needed, but nothing more.

Yeah, that was what I thought. I just wasn't sure whether some EPP TTL
setting extension had been proposed or developed.

> my opinion, I am not a registry nor speaking for them.

Thanks! My sense from working at a registry in the past and knowing folks
at others, is that you are probably right.

Shumon.

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 22 Apr 2020 16:24:39 -0500

> setting extension had been proposed or developed.

There is in fact at least one to my knowledge :-)
It allows to add that payload to a domain create:

<extension>
  <ttl:create xmlns:ttl="...">
    <ttl:secs>300</ttl:secs>
  </ttl:create>
</extension>

To do something similar during a domain update, and retrieve it during
domain info in EPP:

<extension>
  <ttl:infData xmlns:ttl="...">
    <ttl:secs>3600</ttl:secs>
  </ttl:infData>
</extension>

However, and still as far as I know:

- it has never been discussed in the IETF WG about EPP
- I do not see any registry using it, including the registry that drafted it
- the website where it was posted is not active any more, so besides my
own open source EPP client that implements it (I have a knack of doing
every EPP extension possible out there), I know nothing else about it.
The company's gitlab does not reference it anymore either.

HTH,

-- 
Patrick Mevzek

---

From: Shumon Huque <[email-masked]>
Date: Wed, 22 Apr 2020 18:30:42 -0400

Nice!

You didn't name the entity/company, so I won't ask. But I am mildly
curious about why they never brought the proposal to the regext
working group.

Shumon.

---

From: Joe Abley <[email-masked]>
Date: Wed, 22 Apr 2020 21:53:04 -0400

> curious about why they never brought the proposal to the regext 

Others will surely have greater insight, but there is much work on the registry-registrar interface that happens outside the IETF. I am aware that the regext wg chairs have put considerable effort into trying to encourage more such work to happen there, but there is some degree of cultural round peg square/hole going on.

As a minor adjunct to Patrick's earlier advice on EPP, note that not all registries use separate host and domain objects. In some registries the data you might otherwise find in a host object is present in domain objects themselves, rather than domain objects and host objects being linked. I think this behaviour is exclusively found in non-contracted registries.

RFC 5731:

   <complexType name="nsType">
    <choice>
      <element name="hostObj" type="eppcom:labelType"
       maxOccurs="unbounded"/>
      <element name="hostAttr" type="domain:hostAttrType"
       maxOccurs="unbounded"/>
    </choice>
   </complexType>
   <!--
   Name servers are either host objects or attributes.
   -->

   <complexType name="hostAttrType">
    <sequence>
      <element name="hostName" type="eppcom:labelType"/>
      <element name="hostAddr" type="host:addrType"
       minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
   </complexType>
   <!--
   If attributes, addresses are optional and follow the
   structure defined in the host mapping.
   -->

Joe

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 23 Apr 2020 13:09:53 +0200

On 4/22/20 9:32 PM, Shumon Huque wrote:
> Since delegation records and glue address records are unsigned, they
> can be spoofed, and DNSSEC should really allow us to detect such
> spoofing once a resolver sees referral data.

I wouldn't put much energy into improving this part in *this* draft. 
Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy,
so I'd rather kill this problem by proper encrypted protocol towards
authoritatives (in current dprive charter).

--Vladimir

---

From: "Giovane C. M. Moura" <[email-masked]>
Date: Thu, 23 Apr 2020 13:28:22 +0200

Hi Shumon,

> unsigned, delegating NS set in the parent

This was a problem waiting to be addressed for a long time. Thanks for
writing this.

For what is worth, we have a recent study[0] that measures how
resolvers, in the wild, choose when presented with inconsistent NSSets
at parent and child.

Higher order bits are:
 - .com,.org, and .net have 8% of second-level domains with != NSSet at
parent/child
 - We classify the impact of these "misconfigurations"  in the wild,
with controlled experiments, and show that it impacts how queries are
distributed among diff NSes --- and  minimum response changes the results
- We evaluate specific versions of resolvers

/giovane

[0]
https://www.sidnlabs.nl/downloads/53BNt9EPxZQOCHYjqWhYfR/7295d79a207afc79cab6309d40a15a76/When_parents_and_children_disagree_Diving_into_DNS_delegation_inconsistency.pdf

---

From: Shumon Huque <[email-masked]>
Date: Fri, 24 Apr 2020 10:49:56 -0400

> I wouldn't put much energy into improving this part in *this* draft.

No worries! As I said at the DNSOP interim meeting yesterday, we
are *not* planning to take that problem on in this draft at all. That was
more of a side conversation because the topic has come up. You can
also argue that this is not technically a security issue, since the
misdirection
is detected later on. So this is an issue of efficiency and early detection,
that arguably is not critical.

> authoritatives (in current dprive charter).

DNSSEC of course does not address privacy, that much is clear.
But I don't think I agree that encrypted transport addresses the
data authentication issue here.

In the general case, the DNSSEC security model does not rely on the
security of the authoritative servers themselves, but on the entities
that perform the signing. Encrypted and authenticated transport can
verify that you are obtaining the DNS response unmolested from the
correct authority server, but it doesn't protect you against compromise
of the server itself. DNSSEC protects you against this, if the signing
system is separately secured, as is the case with the DNS root, many
of the TLDs, and many enterprise deployments that use hidden and
inaccessible signing masters.

This is of course not true for the various online signing deployments. In
those cases, transport security is a more complete solution (because
the  signing keys are already exposed at the edges of the authority
server network).

Shumon Huque

---

From: Gavin McCullagh <[email-masked]>
Date: Fri, 24 Apr 2020 15:21:39 -0700

Hi Shumon,

On Wed, Apr 22, 2020 at 12:32 PM Shumon Huque <[email-masked]> wrote:

> is authoritative in the parent. It's all very complicated.

I agree these things are complicated (and if I'm honest I may be missing
subtleties you aren't), but I don't think ordinary DNS users should need to
understand that level of detail to be able to work with delegations.  We
seem to have a choice here between the user needing to understand "the
parent must point at the child" versus understanding that "the parent must
point at the child which (usually) must point at itself".   Everyone I talk
to outside the DNS community seems to leap to the former conclusion.   I
doubt that will change.

>> be too if we declared the in-zone NS to be "informational only".  [...]
>>
>

I may be missing some subtlety here, but parent-centric resolvers seem to
use the NS records and DS records from the parent zone today just fine.
The DS is signed by the parent and provided in the same response as the
referring NS record.  If the response was spoofed the DS rrsig wouldn't
validate.   If the referring NS record needs to be signed, surely that
should be designed into DNSSEC.  Are you saying you believe that
parent-centric resolvers are insecure?

> minority, in my estimation.

I didn't mean to suggest the TLD/SLD is a corner case, it obviously
isn't.   I was trying to point out that the non-registrar case is also not
a corner case.   Both are common.  I suppose I am arguing that the case
where: [we have a TLD/SLD managed by an expert DNS operator who understands
how to (and is motivated to) manipulate child-centric resolvers to improve
redelegation safety] is really a corner case.  Perhaps not among the people
on this list, but over all delegations in the world, I'd say it is a very
tiny fraction.  And I'd prefer to optimize to simplify the rest.

>> child centric resolvers.  [...]
>>
>
> I would hope that making resolver behavior consistent would address most
> of this. If all resolvers locked on to the authoritative NS set, then most
> of the surprises would disappear (hopefully).
>

Things will break more reliably, for sure.   And I agree that consistency
is better.   But it likely won't make it any easier for non-DNS geeks to
understand why.

> Does the EPP DNS mapping even support setting TTL?

That's one way to approach it.   What I was thinking was, if the registries
want to dictate the TTL, that seems understandable.  But in so doing, they
could have a process where they dictate a lowered TTL (of their choice) for
a period after each change, then raise it back up to normal in order to
reduce the impact of mistakes/problems.   A "bake period" essentially.  The
timers would be argued about of course, like all magic numbers, but
something conservative like an hour would seem like a major improvement on
today.  Hypothetically, would you consider that would improve your use
case?

Gavin

---

From: Shumon Huque <[email-masked]>
Date: Sat, 25 Apr 2020 00:30:20 -0400

> parent-centric resolvers are insecure?

Hi Gavin,

I probably wasn't clear enough, but what I was saying is that changing the
definition of what side of the zone cut is authoritative is a rather
significant change to the protocol. And any proposal for such a change
would need to carry a high bar for acceptance. This would be a breaking
change for validators. Deployed code today already understands the
semantics and authoritative-or-not nature of the NS/DS sets and would need
to change. Lots of NS records on either side of zone cuts would need to
signed/unsigned. For large delegation centric zones that use opt-out, this
would also impose quite a significant cost. The non-disruptive, incremental
way to introduce such a change would be introduce a new delegation record.

> is better.   But it likely won't make it any easier for non-DNS geeks to

Thanks for sharing your experience. I suspect that if we asked a wide range
of folks, we would get differing experiences too. My own experience is
quite different than yours. At my employer, we do lots of DNS changes all
the time. We have ~ 3000 registered domains, and there are constant changes
related to moving between DNS providers (acquisitions, DNSSEC signing
requirements, and other reasons). I often find checklists that have steps
like: lower the zone NS TTL, make the changes, update the TLD via the
registrar interface/API, wait, raise the TTL. This is almost like DNS 101
to them, and I have had to step in explain that lowering the TTL may not
have the effect they expect. These are quite smart people, just not DNS
experts. They understand that there are parent and child NS records, that
they should take care to make sure they match. They are only vaguely aware
of glue records and when they are needed. They see how to set the TTL in
their zones, and expect that to be used. The registrar/registry interface
presents no TTL configuration knobs, so they are not even aware there is an
issue.

To give you another example, on several occasions in the past few years,
I've had to step in to repair an outage caused by teams deploying parent
and child zones on the same server, who didn't realize that the parent has
to have NS records at the child delegation points - a configuration which
accidentally worked, until a later time at which the parent zone was
migrated to another server and things broke.

So, I suspect your experience is not universal.

> PS How truly intractible is the registry argument?  It seems something
>>> like "When an NS change is made, TTL=3600 for the first N hours, then 2
>>> days thereafter." would be a major step forward without drastically
>>> increasing complexity.
>>>
>>
> That's one way to approach it.   What I was thinking was, if the
> registries want to dictate the TTL, that seems understandable.  But in so
> doing, they could have a process where they dictate a lowered TTL (of their
> choice) for a period after each change, then raise it back up to normal in
> order to reduce the impact of mistakes/problems.   A "bake period"
> essentially.  The timers would be argued about of course, like all magic
> numbers, but something conservative like an hour would seem like a major
> improvement on today.  Hypothetically, would you consider that would
> improve your use case?
>

Based on my experience, I doubt that registries would do this. I could be
wrong though, and perhaps we should ask and get them to respond to your
suggestion. But to answer your last question, the draft that has been
proposed is not about improving my own personal use case(s).

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 25 Apr 2020 00:44:41 -0400

> This was a problem waiting to be addressed for a long time. Thanks for

Thanks Giovane ..

> - We evaluate specific versions of resolvers

I skimmed your paper quickly (will read in more detail later), but
it has lots of interesting information in it, so thanks for doing this
work!

Your recommendations in the paper largely match what is already
specified in the delegation revalidation draft.

I was thinking the test zones that you setup to investigate resolver
behavior might also be useful to software developers (e.g.
implementers of resolvers and diagnostic tools) to test their code
against. Do you plan to maintain the parent/child disjoint NS
domain (marigliano.xyz) going forward? And what about the test
domains for other types of misconfigurations?

Did you look at the potential problem of members of the child (or
parent) NS sets emitting different information? I suspect that case
also happens.

Do you have any plans to look at the behavior of the large public
resolvers?

Thanks,
Shumon Huque

---

From: Vladimír Čunát <[email-masked]>
Date: Sat, 25 Apr 2020 08:23:54 +0200

Original subject: New draft on delegation revalidation

On 4/24/20 4:49 PM, Shumon Huque wrote:
> data authentication issue here. [...]

Of course, I didn't mean to imply it would allow us completely dropping
DNSSEC.  By the way, using DNSSEC to anchor the chain to "DNS privacy"
makes most sense to me (even webPKI don't help you with getting the
"right" hostname/SNI).

Still, note that for some consumers the secure transport may be an
argument to drop validating DNSSEC themselves.  If they choose some DNS
provider that they trust with privacy (it might be their ISP), it seems
not a huge leap to trust them with DNS integrity as well (say, the
provider doing DNSSEC validation).  Especially as today "regular users"
don't get that much benefit from validation, mostly relying on
https/tls.  Some of them also want a variant of DNS filtering, which
still clashes with validation a bit (if done *after* filtering).

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Apr 2020 06:56:38 +0000

mind if i cut in?

> On 4/24/20 4:49 PM, Shumon Huque wrote:

(agreeableness.)

> https/tls.

i hope there's some use for DNS results beyond introducing me to an X.509 
authenticated web server. for example i might use DNS to validate an X.509 
self-signed certificate along the lines of DANE. to me this means the goal we 
followed for DNSSEC (authenticate what goes into an RDNS cache) was too 
narrow, and the difficulties of getting stub validation working should have 
been avoided from the outset (in 1996, that was.)

> Some of them also want a variant of DNS filtering, which

it will be necessary for filtered results to be separately (hop by hop) signed 
using something like SIG(0) or TSIG. (stubs ought to choose who can filter.) 
but this isn't a substitute for stub validation (end to end). one ought not 
trust a coffee shop or even one's own ISP to make a trusted introduction to 
one's bank (more or less quoting dan kaminsky from back in 2008 or so.)

-- 
Paul

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 25 Apr 2020 16:50:10 +0900

Vladimír Cunat wrote:

> argument to drop validating DNSSEC themselves.

Or, drop any PKI, because PKI is only weakly secure subject to
MitM attacks on CAs.

> If they choose some DNS
> provider doing DNSSEC validation).

The problem of PKI including DNSSEC is that trusted third
parties of CAs are actually untrustworthy.

 > Especially as today "regular users"

Though validation by https is no better/worse than DNSSEC
or any other PKI, https may offer some amount of privacy.

						Masataka Ohta

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 27 Apr 2020 11:47:53 +0200 (CEST)

>     Il 25/04/2020 08:23 Vladimír Čunát <[email-masked]> ha scritto:
> 
>     Still, note that for some consumers the secure transport may be an argument to drop validating DNSSEC themselves.  If they choose some DNS provider that they trust with privacy (it might be their ISP), it seems not a huge leap to trust them with DNS integrity as well (say, the provider doing DNSSEC validation).  Especially as today "regular users" don't get that much benefit from validation, mostly relying on https/tls. 
> 
In any case, for most users today DNSSEC validation is done by the resolver and not on their device, and in that case the length of the leap you mention is zero: you already have to take the resolver's word for the fact that the result of DNSSEC validation really was what the resolver tells you, so there is no additional security in knowing that the resolver says that it did DNSSEC validation and it was ok.

There is for the resolver, of course, but this means that the resolver can evaluate independently how to trust the results that it gets for its queries; it could rely on DNSSEC, or it could rely on some form of authentication of the authoritatives (e.g. ADo* and/or PKI), or on any other existing or new mechanism.

> 
>     Some of them also want a variant of DNS filtering, which still clashes with validation a bit (if done *after* filtering).
> 
Which is one more reason why clients might prefer "trust whatever the secure resolver says" to "trust the DNSSEC information that the resolver puts in your results". DNSSEC and DNS filtering are incompatible by design, and if you have to choose among the two, many users will prefer the latter.

Of course, this changes if we go into the "resolverless" mode envisaged by a couple of the ADD drafts, or in the currently rare case when the client is not a stub and does full resolution directly (the two things are IMHO architecturally equivalent). In that case, the client's security would really benefit from doing DNSSEC validation directly.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Joe Abley <[email-masked]>
Date: Mon, 27 Apr 2020 08:09:37 -0400

On 25 Apr 2020, at 00:30, Shumon Huque <[email-masked]> wrote:

> On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh <[email-masked] <mailto:[email-masked]>> wrote:
> 
> PS How truly intractible is the registry argument?  It seems something like "When an NS change is made, TTL=3600 for the first N hours, then 2 days thereafter." would be a major step forward without drastically increasing complexity.
> 
> Based on history to date, it seems to be rather intractable, but I would love to be proven wrong. The interfaces that registrars use to update delegation records in the registries don't even offer any TTL configuration option that I've seen (even if the registries were willing to support it). Does the EPP DNS mapping even support setting TTL?
> 
> That's one way to approach it.   What I was thinking was, if the registries want to dictate the TTL, that seems understandable.  But in so doing, they could have a process where they dictate a lowered TTL (of their choice) for a period after each change, then raise it back up to normal in order to reduce the impact of mistakes/problems.   A "bake period" essentially.  The timers would be argued about of course, like all magic numbers, but something conservative like an hour would seem like a major improvement on today.  Hypothetically, would you consider that would improve your use case?
> 
> Based on my experience, I doubt that registries would do this. I could be wrong though, and perhaps we should ask and get them to respond to your suggestion. But to answer your last question, the draft that has been proposed is not about improving my own personal use case(s).

As a contracted registry operator, we will do whatever the contract tells us to do.

However, it might be that centralising the requirements for this kind of new mechanism in the form of legal contracts with ICANN, back-end registry providers, etc might not be the most efficient way of deploying anything. There are also many TLDs that are not contracted parties and who (properly, sensibly) make their own decisions. If part of the goal is simplicity through consistency, this seems like a poor approach.

More generally, putting the TTL for the NS set effectively in the hands of the child zone operator provides maximum flexibility for appropriate values to be chosen. Concentrating a TTL policy in the parent for all child zones, regardless of downstream operational circumstances or personal preference, seems a lot less flexible.

With a child-centric approach, the NS RRSet TTL in the parent zone relates to the parent infrastructure and is useful until the child can be reached, at which point it can be replaced a value that makes sense for the child infrastructure. This seems intuitive, simple and sensible.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Apr 2020 22:39:41 +0000

> days thereafter." would be a major step forward without drastically

i think this capability should be preserved, which this draft does by treating 
the delegation TTL as an upper bound on the apex TTL. if some registry wants 
to operate as quoted above, then periodic delegation revalidation in all RDNS 
servers will make it possible. if the registry prefers to let the registrar 
(or ultimately, the registrant) set the delegation TTL, then that will also be 
possible.

therefore i repeat my earlier claim that any desire toward centricism, like 
child-centric or parent-centric, misses the point of delegation revalidation. 
DNS is a cooperative protocol, and local agency should determine data policy.

On Monday, 27 April 2020 12:09:37 UTC Joe Abley wrote:
> > ...
> 
> More generally, putting the TTL for the NS set effectively in the hands of
> the child zone operator provides maximum flexibility for appropriate values
> to be chosen. Concentrating a TTL policy in the parent for all child zones,
> regardless of downstream operational circumstances or personal preference,
> seems a lot less flexible.

the protocol must not require this, but should facilitate it where desired.

> With a child-centric approach, the NS RRSet TTL in the parent zone relates
> to the parent infrastructure and is useful until the child can be reached,
> at which point it can be replaced a value that makes sense for the child
> infrastructure. This seems intuitive, simple and sensible.

indeed, that's what the NS query is meant to do in this draft.

-- 
Paul

---

From: Shumon Huque <[email-masked]>
Date: Mon, 27 Apr 2020 20:21:40 -0400

On Mon, Apr 27, 2020 at 8:09 AM Joe Abley <[email-masked]> wrote:

> wrote
> However, it might be that centralising the requirements for this kind of
> new mechanism in the form of legal contracts with ICANN, back-end registry
> providers, etc might not be the most efficient way of deploying anything.
> There are also many TLDs that are not contracted parties and who (properly,
> sensibly) make their own decisions. If part of the goal is simplicity
> through consistency, this seems like a poor approach.
>

Thank you Joe. In case it wasn't clear to others, my earlier expression of
doubt was based on what I felt registries would be willing to do, if not
contractually obliged to. I wasn't advocating Gavin's idea, but was
interested in the view from registries nonetheless.

> infrastructure. This seems intuitive, simple and sensible.

Yes, I agree with this. (I also agree with Paul's qualification that we
might be wise to avoid the use of the child/parent centric terms since the
proposal on the table is about judicious use of information from both
sides).

Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Mon, 27 Apr 2020 21:02:27 -0400

> been avoided from the outset (in 1996, that was.)

That was the goal that was largely followed, but was it the original goal?

The DNSSEC specs have always contemplated validating stub resolvers.
I think the Kaminsky cache poisoning scare inadvertently focussed our
efforts on solving the DNSSEC-to-RDNS problem to the exclusion of other
more complete possibilities.

There has certainly been work on validating stubs on the margin though:
getdns, stubby, etc, but those are only used by a small minority of tech
savvy users (as far as I'm aware).

The one significant impediment cited for validating stubs is the middlebox
last mile problem. Here again, there has been attempted work, e.g. the
TLS DNSSEC chain extension for TLS enabled applications. And DNS
over TLS/HTTPS could prove to be an enabler for validating stub resolvers
to obtain a clean, unmolested path to an upstream recursive service.

Shumon Huque

---

From: Brian Dickson <[email-masked]>
Date: Mon, 27 Apr 2020 19:34:59 -0700

> one's bank (more or less quoting dan kaminsky from back in 2008 or so.)

I've been thinking about whether/how a provider of filtering service
(directly or indirectly) could be explicitly trusted to provide filtered
"answers".

It might be necessary to restrict what kinds of answers could be provided
within that scheme, in order to prevent or limit the potential for abuse.

If the client had a validating forwarder, the following would at least in
theory be possible to do:

   - Download the appropriate additional trust anchor for the filtering
   service
   - Filtered responses would be signed with this trust anchor
   - The validating forwarder would validate those using the trust anchor

This supposes that authoritative answers are served by the resolver (and
thus it would not rely on other cached responses), and that those are
signed by the filtering service.

It might be necessary for the client machine to associate a particular set
of such trust anchors with the network environment (including things like
DHCP server, DNS resolver, etc.).

Having signed filtered responses (including NXDOMAIN and/or rewritten
answers) would allow the client to do DNSSEC validation.

I'm not sure how much incremental work is required to do this, beyond some
method of discovery of trust anchors.

I think there would need to be some limitations on rewritten answer, e.g.
ranges of IP for walled garden, or domain names, or even whether positive
or negative answers are allowed.
My intuition would be that the namespace should be subordinate to the name
of the domain serving the filtering service (rpz-service.example.com as an
example) and/or limited to internal IP addresses (RFC 1918 or similar, or
some similarly scoped IP range that can be identified as "local".)

Thoughts?

Does this make sense at all?

(I've been a big proponent of RPZ for a long time now, and am interested in
some solution to client DNSSEC validation that can interoperate with RPZ.)

Brian

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Apr 2020 04:06:28 +0000

> more complete possibilities.

stub resolvers were thrown overboard in order to get DS working.

> savvy users (as far as I'm aware).

as long as the configured RDNS is DS-aware, yes. if the RDNS is older than 
that, and if there's a firewall preventing the stub from talking directly to 
authorities, there's no way for a stub to learn the DS part of the signature 
chain. so, a stub resolver needs a completely modern RDNS to work. this has 
not scaled, and won't.

> to obtain a clean, unmolested path to an upstream recursive service.

i agree that if we change most of the rules, we can get a different outcome.

-- 
Paul

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Apr 2020 15:48:13 +1000

> On 28 Apr 2020, at 14:06, Paul Vixie <[email-masked]> wrote:
> 

More correctly there isn’t protocol work to do to get stub resolvers and
DNSSEC working.  It just requires vendors to *implement* DNSSEC in the stub
resolver or even in the application.  You can take a BIND 4 resolver library
and get DNSSEC working on top of it.

> not scaled, and won’t.

The RDNS needs to be DNSSEC aware as you can’t get RRSIGs that match the answer,
NSEC, or NSEC3 records without that, much the same as you can’t point a validating
recursive server at a non-validating forwarder and have DNSSEC work reliably.

---

From: "Giovane C. M. Moura" <[email-masked]>
Date: Tue, 28 Apr 2020 11:42:35 +0200

Hi Shumon,

>  Do you plan to maintain the parent/child disjoint NS 
> domain (marigliano.xyz <http://marigliano.xyz>) going forward? And what
> about the test

Great idea. Let me look into this, will get back to with that.

> parent) NS sets emitting different information? I suspect that case

Yes, section 4 covers this (NSSet parent != NSSet child).

We have 4 scenarios, and we always query for the A record of
$probeid-$timestamp.marigliano.xyz

The trick was to configure different NSes to return different A answers,
so we knew which NS answer which query.

Is that what you refer?

(in the wild, tab1 shows that 2.1M domains in which the A of the NS
records from parent and child don't match at all -- that's a diff angle
from you question).

> Do you have any plans to look at the behavior of the large public

That's a good idea, to answer this one, we need to configure the
scenarios again. Let me get back to you once I manage to get this setup
for other folks to test this too

/giovane

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 28 Apr 2020 12:21:02 +0200 (CEST)

>     Il 28/04/2020 04:34 Brian Dickson <[email-masked]> ha scritto:
> 
>     I've been thinking about whether/how a provider of filtering service (directly or indirectly) could be explicitly trusted to provide filtered "answers".
> 
>From time to time, I've also been thinking that something like this would be useful and that we should start working on it. It would introduce more security and transparency and address many of the non-technical concerns around DNS filtering. There could even be a mechanism in which the user picks a specialized provider of filtering rules, and then tells whatever resolver they are using to apply those rules, all through authenticated secure communication.

More generally speaking, I think that it would be very beneficial to Internet end-users if the discussion around [DNS] filtering in the technical community moved from "is filtering good or evil?" to "filtering is a fact of life, how can we make it work better?".

--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Apr 2020 09:38:43 -0400 (EDT)

> I've been thinking about whether/how a provider of filtering service (directly or indirectly) could be explicitly trusted to provide filtered

There is only one method where you can trust the filtering service. That
is that they offer you the filtered data in a neutralized fashion. I
have already been waiting a few years for the RPZ draft to pass the ISE
publication process so the IETF can work on the bis document that moves
the censored data into the authoritative section. That way, you get
all the data innoculated. Clients not supporting this will not see
this data and get filtered. Clients supporting this can talk to an
enduser if one is available to say their data was filtered and present
a choice on accepting the filter or not.

I have poked Paul Vixie and the ISE a number of times on the RPZ draft.
I even gave them another full review, but it seems nothing is happening
to move this draft forward.

If I hadn't been too busy, I would have already submitted a rpz bis
draft.

Paul

---

From: S Moonesamy <[email-masked]>
Date: Tue, 28 Apr 2020 12:29:49 -0700

Hi Paul,
>to move this draft forward.

I found a WG draft (expired) from 2017 about RPZ.  I am not sure why 
it stalled in DNSOP.  There is also a 2018 draft (expired).  I 
vaguely recall looking at a draft.  However, proposed changes were 
not accepted.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2020 17:57:16 -0400

>vaguely recall looking at a draft.  However, proposed changes were 

One problem is that the last time I looked at it, the draft needed a
great deal of editing and reorganization to be accessible to people
who don't already know all about RPZ.  The other is the question of
documenting something that definitely exists and is implemented but
has some arguable technical flaws.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Apr 2020 22:12:20 +0000

> has some arguable technical flaws.

the situation at present is, i got way more feedback from reviewers than i 
anticipated, lost heart, and got stuck. it's in the independent editor queue, 
having been determined as non-competitive to any WG's current activity. i'm 
home for the pandemic, so let me pump out an updated draft which will 
hopefully get quick review by the rest of you home for the pandemic.

whatever technical flaws it may have can be enumerated (if there's consensus) 
but not fixed in this draft. we're going to document what exists, so that the 
community can then take it in hand and determine what it becomes.

-- 
Paul

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Apr 2020 21:17:04 -0400

> stub resolvers were thrown overboard in order to get DS working.

Paul - I guess I'm missing some background here. In what sense did
getting DS working throw validating stubs overboard? Do you mean it
took the focus away from them?

As Mark A points out, it isn't that hard these days to write a validating
stub resolver. It just needs a clean path to a working DNSSEC aware
recursive server. Yes, the RDNS has to be DS aware, but those have
been commonplace for a decade or so.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Apr 2020 21:22:17 -0400

> Great idea. Let me look into this, will get back to with that.

Thanks!

> so we knew which NS answer which query.

I meant servers within the child (or parent) NS set had different NS
sets configured in them, i.e. yet another level of mismatch. Maybe
that's not worth investigating, but I'm pretty sure I've come across
such misconfigurations in the past.

> for other folks to test this too

Cool, thanks!

Shumon.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 29 Apr 2020 04:49:51 +0000

> took the focus away from them?

no. i mean that the decision to require a "clear path" for DNSSEC meant that 
no DNSSEC-dependent application has ever received investment. for example, 
DANE is interesting in the SMTP market because that's small and geeky, but 
will never be adopted by the Web because there are too many endpoints who 
cannot do stub validation and too many who will never be able to.

building a DNSSEC-dependent product or service would be commercial suicide. 
whatever we had to do to prevent this, no matter what the cost, up to and 
including putting keys and signatures into TXT records, would have been more 
in keeping with our own long term rational self interest and the goal of 
DNSSEC ubiquity. if as i expect history passes DNSSEC by other than for DANE/
SMTP and SSHFP and protection of RDNS caches, it will be due to the "clear 
path" design decision.

imagine the WWW launching as it did in the early 1990's but in a way that 
could not work on any desktop whose DNS server was from an earlier era. i hope 
we can agree that it would have failed, and that its failure would have 
inspired something more like the WWW we actually know, which works, and 
worked, everywhere.

-- 
Paul

---

From: Shumon Huque <[email-masked]>
Date: Wed, 29 Apr 2020 09:44:12 -0400

> cannot do stub validation and too many who will never be able to.

Ah, thanks for clarifying.

In that case, I would not characterize this as "DS throwing stubs under the
bus",
but just as a more general challenge with DNSSEC. A validating stub needs to
not only have a clean path to issue and obtain DS responses from an upstream
RDNS, but more generally, also be able to issue CD=1, EDNS/DO=1, queries
for
arbitrary record types including, critically DNSKEY. If any of this is
blocked by a
middlebox, there will be a problem.

This is by no means a problem unique to DNSSEC. Many new protocol features
have and continue to face the middlebox challenge: SCTP, TCP fast open,
multi-
path TCP, QUIC, TLS 1.3 etc. Some have developed workarounds with varying
degrees of success, some like SCTP have more less died. The web has the
advantage (in my opinion) that a small number of browsers are able to impose
changes on the middlebox ecosystem in a way that the DNS will never be able
to.

I certainly agree that the clean path issue is a big impediment for
something like
DANE. I don't think I want to repeat the long and contentious history of
the TLS
DNSSEC chain extension effort which was designed to address this for the
Web,
but you can read my take on it here if you're bored:
https://blog.apnic.net/2019/07/05/whither-dane/

As I mentioned in a previous note, DNS over HTTPS (however one might feel
about current deployment models and such), can probably provide the clean
path that end user applications of DANE need.

Shumon Huque

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Apr 2020 11:34:31 -0400 (EDT)

> cannot do stub validation and too many who will never be able to.

You seem to think that the Web(PKI) not accepting DNSSEC was a technical
problem. While there were technical issues, I don't think the acceptance
or not had anything to do with technology.

But regardless, those technology problems are now resolved. Most people
have a clean path and those who don't have ways to make it clean using
DoH or DoT. We can wait a few years now. We have waited long enough. And
if DNS(SEC) is replaced by something else that's cleaner, that is fine
too, provided that new solution keeps the hierarchical structure of TLDs
intact. And there is no way it could not, as there are piles of money
involved - billions of dollars as we recently saw.

Paul

---

From: Shumon Huque <[email-masked]>
Date: Wed, 29 Apr 2020 11:45:19 -0400

> or not had anything to do with technology.

Nope, I'm fully aware of all the non-technical issues and resistance (and
have described some of that in the article). But there were a small
contingent
of web folks that were interested in DANE, and that might have been enough
to gain an initial foothold there. You have to start somewhere.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 29 Apr 2020 11:54:33 -0400

to the list, after Paul Wouters replied to me privately.

I realize now this was Paul W responding to Paul V. I thought in
my response below I was replying again to Paul V!

My apologies ..

Shumon.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Apr 2020 11:56:51 -0400

Hi,

I discovered this draft during the interim meeting. We had similar thoughts
in our "Recommendations for DNSSEC Resolvers Operators". Our motivation for
supporting this work are that it  1) improves the reliability of the
resolution as well as 2) removes the temptation to (inadvertently) break
resolution by fixing in appearance a misconfiguration. In other words it
eases the operation.

Yours,
Daniel

On Tue, Apr 28, 2020 at 9:23 PM Shumon Huque <[email-masked]> wrote:

> On Tue, Apr 28, 2020 at 5:43 AM Giovane C.. M. Moura <giovane.moura=

-- 
Daniel Migault
Ericsson

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Apr 2020 07:15:45 +0000

> changes on the middlebox ecosystem in a way that the DNS will never be able

so, there were two modes. first, the web was created. it worked everywhere and 
required no upgrades to the OS or any other protocol or any gateways or 
firewalls. later (today), the web is dominant and if it makes a change that 
doesn't work everywhere, the pain will be felt everywhere, and every operating 
system and gateway and firewall will conform or die.

DNSSEC has never been in either mode. depending on DNSSEC for a product or 
service remains commercial suicide and always will. thus noone invests in such 
products or services, and anyone thinking about the X.509 CA problem ignores 
DANE and focuses on cert-pinning or similar.

the pre-DS clear path requirement was really "allow unknown RRtypes". the 
post-DS clear path requirement was really "understand DS". that was a change 
we made, that stopped all progress beyond "let's opportunistically protect the 
RDNS cache, and geeky stuff like SSHFP, and DANE for SMTP".

> path that end user applications of DANE need.

i heard you say that, and i disagree, but it's off-topic, so, another time.

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Apr 2020 07:21:38 +0000

ah. too many pauls, as before. nevertheless i agreed with your reply:

> > contingent of web folks that were interested in DANE, and that might
> > have been enough to gain an initial foothold there.
> > You have to start somewhere.

+1.

-- 
Paul

---

From: "Giovane C. M. Moura" <[email-masked]>
Date: Thu, 30 Apr 2020 12:33:38 +0200

> such misconfigurations in the past.

Oh now I get it.
We did only with a sample of 1% of .org domains (10k), only looking at
different NSes at the child level. We found 2% of them having
inconsistencies.

See on the last paragraph of section 3 [0]:

"Note that the OpenINTEL platform performs the measurements choosing
one of the child authoritative nameservers. To verify how often sibling
name servers have different configurations (child-child delegation
inconsistency), we execute a measurement on a random sample of ∼ 1% of
.org domains (10k domains). The measurement suggests that ∼ 2% of total
parent-child delegation inconsistency cases also have child-child
delegation inconsistencies, meaning that our results give a lower bound
for the problem of parent-child mismatch. "

/giovane

[0]