Re: [DNSOP] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

[Joe Abley]

Hi again,

On Oct 16, 2022, at 13:09, Momoka Yamamoto  wrote:

> [...] However, we thought that in theory (but maybe not currently) an 
> iterative resolver is the only application that actually needs IPv4 to 
> operate. 

I'm interested in this perspective. 

My feeling is that it's far more common to find dual-stack nameservers 
reachable directly by v6-only and v4-only clients than it is to find services 
that the requested names refer to that are dual-stack and similarly reachable. 
On the face of it this seems like the opposite assumption than the one you 
describe above. 

Do you have any data to support your perspective? This is an honest question; 
to be clear, I have no data to support mine and I am very willing to discover 
that I am wrong :-)


Joe


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

[Joe Abley]

Hi there,

On Oct 8, 2022, at 13:58, Momoka Yamamoto  wrote:

> re: Mark Andrews 's comments
> > this is yet another example of why DNS64 should be made historic.
> > This is requesting even more support to work around problems introduced by 
> > DN64, a poorly thought out, supposedly short term hack.
> 
> We did not write this draft thinking DNS64 has a problem.
> We thought that IPv6-only iterative resolvers not existing because of 
> IPv4-only authoritative servers is a problem, and wanted a way to solve it 
> from the resolver side and not only from the network side (e.g. using 
> 464XLAT).

A host connected to a v6 network that has access to v4 networks via translation 
mechanisms is a dual-stack host for the purposes of initiating queries and 
receiving responses. It is not a v6-only resolver in a practical sense.

Another example of such a host might be one which has v4 connectivity, and 
which has v6 connectivity through a tunnel. That host is also dual-stack.

Your document seems to say, in essence, "your resolver should be dual-stack if 
it needs to be able to send queries over both v4 and v6". But this is 
unsurprising news, since it's basically the definition of "dual-stack".

Perhaps I am missing something?


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Joe Abley]

Fujiwara-san,

On Sep 22, 2022, at 11:05, Kazunori Fujiwara  wrote:

> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and
> they often don't work as expected.
> 
> However, it may be easy to avoid using the Fragment Header on IPv6.
> (limit IPv6 response packet smaller than interaface MTU.)
> (Or, is it not easy ?)

I think it's easier if we just recommend a maximum message size for UDP 
transport that is likely to avoid truncation in the majority of cases. Perhaps 
that is the simplest formulation of your ultimate goal? Just update the base 
specification and say it clearly. 

This will make UDP transport only usable for a subset of DNS messages that are 
ever sent on the Internet. Other transports can remain as-is and do not need 
this limitation. People who ignore the recommendation are on their own.  

UDP then becomes a convenient choice for DNS messages that are small and that 
do not have requirements for confidentiality, bit not a default choice in the 
protocol sense (despite the fact that it will probably remain the choice for 
most messages).

The default transport becomes TCP, since that is the alternative, 
must-implement transport available in all parts of the system.

> Then, to allow larger than 1232/1400 and smaller than interface MTU
> response packets, recommendations for UDP requestors are changed as:
> 
>  UDP responders can send reponses fit in both
>  the result of path MTU discovery (if available),
>  interface MTU and UDP requestor's payload size.

I think a formulation to avoid magic numbers is probably better but to be 
honest I don't find magic numbers to be so terrible if they make the advice 
more clear.

(I think the current draft's advice is not particularly clear since it contains 
a lot of
if then else, but perhaps others think differently.)

The DNS is used in private networks as well as on the Internet. I think it's ok 
to say simply that UDP transport is NOT RECOMMENDED for large messages since 
fragmentation SHOULD be assumed to be unavailable.

That leaves wriggle room for implementations who have more knowledge of their 
network path or who don't care about delivery failures (for example) to do 
their own thing. I don't think we should spend too much time imagining what 
those things should be.

>>> 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header.
>>>(many TCP implementations already set DF bit)
>> 
>> I doubt we have control over this from the application. Is there even
>> API to control that on TCP sockets?m

I don't think we should write as if UDP and TCP are the only transports 
available. I also think it's a mistake to dive down into rabbit holes relating 
to any particular transport other than UDP.

UDP is the only transport we have in which the DNS protocol needs to care about 
message size. I think the current draft does a good job in restricting its 
discussion to UDP.

> At least, I would like to disable IPv6 fragmentation.
> and I would like to make "avoid IPv4 fragmetion" our goal.

I think we should just be bold and declare a RECOMMENDED maximum message size 
when using UDP transport and make TCP the default choice of transport.

UDP becomes an acceptable alternative to TCP alongside other transports that 
might be available, if suitable for a particular message, according to local 
policy. 

The maximum that is specified could be a magic number (like the original 
specification's 512 bytes) or it could be a formulation based on particular 
address families' minimum capabilities. Clearly some people prefer the latter. 

The question of how to construct a minimum sized response in cases where a DNS 
responder really wants to avoid a trip through another transport might ideally 
live in a separate document.

I appreciate that it's a bit late in the process to be suggesting such a change 
in approach to what is quite a mature document. Sorry about that. 


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[Joe Abley]

On Aug 24, 2022, at 11:27, Schanzenbach, Martin  wrote:

> We (I) learned that this is a good approach after conversations with our 
> reviewers in particular since it is very difficult to distinguish what "case" 
> actually is with respect to i18n.

Fortunately (at least as far as understanding domain names and IDNA are 
concerned) you don't have to. A-Labels are case-insensitive in the manner that 
"Alt" and "alt" are the same domain name. There are no such expectations of 
U-labels. 

> If the application decides that the user expectation is that "example.ch.Alt" 
> IS "example.ch.alt", then the application is invited to make the user happy 
> accordingly:

Sure, there are no protocol police. All applications are free to ignore user 
expectations and standards if they want. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[Joe Abley]

On Aug 24, 2022, at 10:13, Joe Abley  wrote:

> That's a large installed base of assumptions; to a close approximately it's 
> all users of the internet and all software that makes use of it.

Approximation, not approximately. My phone and I have different ideas about 
language, soapy about thatch. 


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[Joe Abley]

Hi Peter,

On Aug 24, 2022, at 09:40, Peter Thomassen  wrote:

> On 8/23/22 18:37, Joe Abley wrote:
>> So your suggestion is that this document should specify behaviour for QNAMEs 
>> whose final label is exactly "alt" but that names with different 
>> capitalisation should be leaked to the DNS?
> 
> Please don't put words in my mouth. :-)

Certainly wasn't doing that. I was just trying to point out some insane 
implications in a gentle way. 

> Names ending other than with the specified reserved label(s) would "leak" 
> somewhere, just like typos (".allt") would. Typos aside, the question is what 
> problem is getting solved by allowing various capitalizations.

Domain names are case-insensitive. Example.com is precisely the same name as 
EXAMPLE.Com is precisely the same name as eXamPLE.cOM. These are not typos; 
this is by design and, as a consequence, it's a fundamental assumption of users 
and software that concern themselves with domain names. 

That's a large installed base of assumptions; to a close approximately it's all 
users of the internet and all software that makes use of it.

The largely unknown set of names we are talking about (reluctantly in my case) 
under ALT are also domain names. If they weren't there would be no risk of 
collisions, no conflict with the DNS and even less reason to have this 
conversation than is evident here. 

So the question is not whether to allow mixed capitalisation; the question is 
why we would intentionally change a fundamental expectation of domain names to 
accommodate names and resolution protocols that we largely don't have any 
requirements for because with one notable exception they don't exist?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[Joe Abley]

On Aug 23, 2022, at 18:07, Peter Thomassen  wrote:

> Unaware applications: yes, perhaps mixed; but as they're unaware, they'll 
> ignore the carve-out regardless of case
> 
> Aware applications: ... will produce only what's compliant. And the question 
> here is what we want to define as compliant with the carve-out.

So your suggestion is that this document should specify behaviour for QNAMEs 
whose final label is exactly "alt" but that names with different capitalisation 
should be leaked to the DNS?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-alt-tld-17

[Joe Abley]

On Aug 23, 2022, at 16:03, Schanzenbach, Martin  wrote:

> "
> 
> This document uses ".alt" for the pseudo-TLD in the presentation
>   format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
>   wire format.  The presentation and on-the-wire formats for non-DNS
>   protocols might be different.
> "
> 
> I had to read this 3 times and I am still not sure what is important and what 
> not.

Doesn't this text also imply that the alt label is case-sensitive?

I may have missed something (I have been trying very hard) but it seems a 
little weird for the wire format for a definitively non-existent domain name to 
be specified at all, to be honest; I'm not sure what imagined audience that is 
intended to help.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Joe Abley]

On Aug 16, 2022, at 16:15, Schanzenbach, Martin  wrote:

> And this is why there must be a registration policy and process.

If that's really where this conversation has landed, then perhaps it's worth 
pointing out again that a variety of such registration policies and processes 
already exist, as do well-exercised policies and processes for changing the 
policies and processes when it is decided that change is needed. 

We developed all those existing policies and processes in an organisation that 
is well-staffed, well-funded and that has considerably more engagement from a 
much more diverse set of interests than we do in dnsop (but a set that includes 
us, too). Tell me again why we are talking about this here?

Doesn't it make better engineering sense to say "namespace issues that way" and 
for dnsop to concentrate on dns operations?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Joe Abley]

On Aug 8, 2022, at 08:08, Christian Huitema  wrote:

> The name space is "almost" unitary. People deploy things like domain suffix 
> search lists so that users can type "mailserver" and arrive at 
> "mailserver.corp.example.com" -- or something else, depending where they 
> started for.

There are also private, isolated namespaces; namespaces whose attached RDATA 
exists but looks different depending on who is asking (and when); names that 
are blocked in some places but not others; collisions between names; and no 
doubt other sources of incoherence.

There one namespace in the DNS like there is one namespace in IP, which is to 
say there are multiple and many namespaces that are challenging to count or 
characterise with accuracy. 

What the DNS (domain name) and IP (address) namespaces have in common is that 
they look unitary so long as the common intersection of all the namespaces 
appears large to end users. 

We should perhaps remember that the ship has already sailed on there being a 
single DNS namespace and that what we are really concerned with preserving is 
that the illusion that it has not. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Joe Abley]

Hi Andrew,

On Aug 4, 2022, at 15:33, Andrew McConachie  wrote:

> I apologize for derailing this conversation by bringing up NAT. My point was 
> that the document makes a claim that PMTUD ‘remains widely undeployed due to 
> security issues’. Yet it makes no reference to anything that might back up 
> that claim.

I think the concern about the assertion and the lack of citation are reasonable 
and it ought to be possible to improve the text.

Anecdotally, the problems I have observed with pMTUd is with networks that 
blindly and misguidedly block all ICMP inbound "because security" which breaks 
the signalling path that pMTUd relies upon to know that an interface with a 
small MTU has been found by an outbound packet sent with DF=1. This used to be 
[*] overwhelmingly common when sending large responses back from servers to 
client devices attached through tunnels, e.g. CPE routers using upstream PPPoE: 
servers that are "protected" by over-suppression of downstream ICMP have no way 
of knowing that a packet has been dropped and sessions stall.

For TCP this is mitigatable on the client side (in this example) by techniques 
like MSS-clamping in the CPE. For other layer-4 protocols, not so much. This 
makes failures difficult to troubleshoot since "the internet" seems fine for 
some users/applications but broken for others.

I do not have a convenient reference for this, but searching for "operational 
problems with pmtud" seems to yield a healthy number of results, so perhaps 
something suitable can be found quite easily. RFC 2923 contains descriptions of 
various problems that are relevant, although its clearly-stated focus is with 
TCP transport, not UDP.


Joe

[*] might still be, but I'm more distant from the operational front line than I 
used to be, these days
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Joe Abley]

On Aug 2, 2022, at 10:26, Independent Submissions Editor (Eliot Lear) 
 wrote:

> On 02.08.22 09:56, Joe Abley wrote:
>> 
>> If the position of the ISE is to ignore the prior discussion and publish one 
>> set of opinions regardless then perhaps it would be more straightforward 
>> just to say so.
> 
> Had I wanted to do so, I would not have approached dnsop in the first place.

Had you wanted to which? I'm confused.

By approaching dnsop in the first place with a box of freshly lit matches you 
seem precisely to be ignoring the prior discussion. 

If you don't intend to publish the drafts on your table then I don't understand 
what you're saying in the context of the hat you're wearing. 

Perhaps more fundamentally the idea of the ISE promoting work to be done in a 
working group apparently without the involvement of the chairs itself seems 
confusing. You know more about the job than I do, but in the past when I have 
published documents through the independent stream, the ISE's consultation was 
limited to an IESG conflict review.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Joe Abley]

Hi Eliot,

On Aug 2, 2022, at 07:59, Independent Submissions Editor (Eliot Lear) 
 wrote:

> But what is not reasonable to expect researchers to attempt to enter the 
> ICANN arena in order to facilitate a the safe use of a new naming system that 
> doesn't require use of the DNS.

This argument (and others) have been discussed extensively in the past. There 
are many counter-arguments. Again, I have my doubts that rehashing then again 
will lead to a different outcome. 

(To this particular point, just for illustration and not intended for 
discussion, for which see mail archives: suitable anchors for private 
namespaces can be acquired through the icann system for roughly $10/year, or in 
the opinions of some for $0/year by using one of the two-letter ISO-3165 code 
points that are reserved for private use.)

If the position of the ISE is to ignore the prior discussion and publish one 
set of opinions regardless then perhaps it would be more straightforward just 
to say so. 

If the position is rather that dnsop should pick this up again, perhaps that's 
a question for the dnsop chairs to manage?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Joe Abley]

On Aug 1, 2022, at 15:58, Ben Schwartz  
wrote:

> I think we already have such a mechanism: ICANN.  People who want unique 
> registrations can acquire them via the existing ICANN and registry processes.

I think we have been around and around these arguments at the ietf and in 
various parts of the icann community so many times that there's hardly any 
point in taking another run at them.

My observation from being in variously in middle and on the edges of several of 
these discussion is that there is no clear consensus around any of this: no 
consensus that there is a problem to solve, no consensus on what a solution 
would look like to any particular problem and no consensus about the proper 
venue for any architectural or governance decision that might hope to implement 
any particular solution. 

We have had proposals in ICANN ACs, questions considered by the ICANN board, 
proposals in working groups at the IETF and now proposals in the ISE queue.

While it seems entirely reasonable that an independent submission might have 
something to say (there is no shortage of individual opinions) I think it would 
be unfortunate if a document that wound up in the RFC series gave the 
impression that it contained something resembling an IETF position or community 
consensus when it didn't because there isn't one. 

I appreciate independent-stream boilerplate and other cautionary notes within 
the document ought to be able to make this clear, but I have my doubts about 
whether that clarity be obvious in practice to anybody making reference to the 
document.

[If I was on the IESG giving advice to the ISE I would argue that this 
disconnect between individual opinion and the clear lack of group consensus 
represented a conflict. I am not on the IESG, however, for which everybody can 
be thankful, hence the brackets around this paragraph.]

Perhaps it would be a kindness for someone to write a document that said that 
there was no consensus around any of this. Such a document might provide some 
incentive to stop trying to find some and we can all move on with our lives. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The DO bit - was Re: [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

[Joe Abley]

On Jul 29, 2022, at 16:49, Paul Wouters  wrote:

> Interesting history,
> 
> I would have expected (and have taught) that this was by design to not 
> disrupt systems with new data unless we knew they were ready for it. I didn’t 
> realize we first tried to do it without that 

By the time we got to signing the root zone (surely much, much later than Ed's 
anecdote) there was some hope that we could deploy DNSSEC RRs into the root 
zone whenever we felt like it, since clients that didn't explicitly want DNSSEC 
RRs in their responses wouldn't set DO=1, there would be no RRSIGs etc in 
responses they received, and hence they would be immune from any unintended 
consequences.

Of course by then DNSSEC had been well and truly implemented in the most 
deployed resolver implementations and it had become clear that such resolvers 
needed to set DO=1 on all upstream queries regardless of whether validation was 
turned on locally so that downstream validators could be supported. So in 
practice pretty much every query received by authoritative servers already had 
DO=1. The need to be careful remained and this led to the idea of the DURZ, so 
that the effect of large responses could be isolated and assessed independently 
of the need to validate signatures.

I remember David Conrad in particular being very sad about the ubiquity of 
DO=1, more so even than he already was about DNSSEC in general. Or maybe DRC's 
sadness just seemed more pronounced because he had to deal with me as an 
employee.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Joe Abley]

Hi Andrew,

On Jul 29, 2022, at 11:14, Andrew McConachie  wrote:

> We don’t need a useful standard for NAT to recognize that most 
> implementations break PMTUD, and that those implementations of NAT are 
> deployed enough to make PMTUD significantly broken.

I was really just suggesting that some measurement to support the assertion 
might be nice.

>> So perhaps it's reasonable to say that the IETF use of MTU pre-dates 
>> Ethernet switch vendors' usage, since it pre-dates Ethernet switches, since 
>> it pre-dates Ethernet.
> 
> Ok. But the text still isn’t clear on how many bytes are assumed to be 
> consumed by layer-2 protocols.

I think the point is that it's not necessary to know that.

> We don’t need to have a super tight definition of MTU to progress this 
> document. Implementors just need to know how big of packets they can transmit.

The answer to that question for any particular interface (attached to any 
layer-2 network) is "that interface's MTU".


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Joe Abley]

On Jul 28, 2022, at 12:24, Andrew McConachie  wrote:

> PMTUD doesn’t work through NAT

That's a very definitive statement considering that there's no useful standard 
for NAT.

If there's actual research on this to demonstrate that, pragmatically speaking, 
no implementations use the payload of a type 3 code 4 ICMP message to identify 
a translated target for the packet I would like to read it, because that sounds 
interesting. 

>> Currently, DNS is known to be the largest
>>   user of IP fragmentation.
> 
> Compared to what? I would just drop this sentence because it doesn’t add 
> anything to the document and it’s trying to make a point that doesn’t need to 
> be made.

I'd also like to see a citation for this one if there has been a study. I agree 
that it's probably the most familiar example of fragmentation for an audience 
mainly preoccupied with the DNS, but that's probably not a helpful observation 
:-)

> Before I was interested in the DNS I worked for an ethernet switch vendor for 
> 8 years, and I often find the way MTU gets talked about in IETF documents 
> simply weird.

RFC 791 introduces the term "maximum transmission unit" to be the maximum size 
of a datagram, not the maximum size of a frame whose payload is a datagram.

The maximum sized datagram that can be transmitted through the
  next network is called the maximum transmission unit (MTU).

> MTU is a measurement of maximum frame size for a network segment starting at 
> Layer 2.

I have also heard MTU used in that way. I have always assumed it was just 
sloppy writing.

There may be prior use of the phrase that I'm not aware of (prior to 1981) but 
even if that's the case I think it's reasonable to use the IETF definition of 
the phrase in the IETF.

I think Ethernet was not standardised until the publication of IEEE 802.3 in 
1983. I also think the original specification did not anticipate switches but 
described a multi-access network with a broader collision domain.

So perhaps it's reasonable to say that the IETF use of MTU pre-dates Ethernet 
switch vendors' usage, since it pre-dates Ethernet switches, since it pre-dates 
Ethernet.


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

[Joe Abley]

On Jul 26, 2022, at 15:29, Ólafur Guðmundsson 
 wrote:

> Parent is authoritative for the existence of the delegation 
> Child is authoritative for the contents of the delegation
> 
> DNS design did not take this into account thus there is no "range" of Parent 
> only records, 
> DS is the only record that is explicitly a "violation" of this 
> 
> IMHO RFC103x should have defined a DEL record in parent and NS in the child 
> then resolvers could have kept both sides. 

I recall suggesting a retrofit for this once before.

https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer-00

I wrote that quite a while ago, and I seem to remember being surprised at the 
lack of public indigestion that resulted from it. Perhaps that just means 
people didn't read it. It doesn't seem to be completely terrible, having just 
skimmed through it again.

(In an alternate reality where REFER was implemented and in common use, perhaps 
the weird DS mechanism that we have would also have different RRTYPEs split 
between parent and child and would not need to be weird.)

If there is anybody else with sufficiently bad taste to imagine trying any of 
this out, perhaps we could talk. I am not be in Philadelphia this week, 
however, so I am not immediately availble for the alcoholic aspirations 
imagined by the text in appendix A.1.


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

[Joe Abley]

On Jul 8, 2022, at 08:50, Bob Harold  wrote:

> I thought the catalog zone was required to be a valid zone. 

I think it might be worth exploring what "valid zone" might mean. 

All consumers of catalogue zones digest the whole zone as an atomic unit; they 
don't retrieve it piecemeal or walk the zone. To retrieve a zone you need prior 
knowledge of a server that hosts it. While I suppose it's possible to identify 
such a server by means of referrals, I'm not aware of anybody who thinks that 
is sensible. So there is no need for a functional zone cut above the catalogue 
zone; the zone can exist in a disjoint, isolated namespace. 

More generally, a zone can be syntactically valid without the servers specified 
in its apex NS set existing in the global namespace or being reachable, or 
without an apex NS set at all. The only RR required for a zone to be valid is 
an SOA at its apex (but see the trailing comment in this reply). 
Implementations intended for general use might still complain about the absence 
of an apex NS set for reasons of (quite reasonable) local policy. 

So I think it's ok and expected for a catalogue zone to be weird, but that 
doesn't necessarily make it invalid. 

> We certainly should not be requiring changes to the code that verifies a 
> valid zone.  Is an NS record part of the validation in some DNS code bases?  
> If so, it should be mandatory.

If local policy requires an apex TXT record containing a version control 
string, that might be a local requirement. I think the presence of an NS set is 
similar. I don't think all possible local requirements need to be anticipated 
in this draft, although common or expected ones might reasonably benefit from a 
mention.

> Do the RFC's require an NS record?

"The RFCs" and "require" in the context of the DNS is more usually a matter of 
religion than science. See above for examples. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

[Joe Abley]

On Jun 27, 2022, at 13:40, Peter Thomassen  wrote:

> Thinking about it, perhaps there's no reason for normative language here. If 
> others agree, please let me know and I'll change to lowercase "should".

If you are going to downgrade the requirement, MAY seems better than should, 
perhaps coupled with advice to help an operator make a good decision. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation

[Joe Abley]

On Mar 25, 2022, at 18:36, Benno Overeinder  wrote:

> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.

I think it's clear that there are people who want to do this, I think a 
standard approach is important to write down, and I think this draft is a 
perfectly reasonable starting point for that. So I think this draft is suitable 
for adoption by dnsop.

> Please also indicate if you are willing to contribute text, review, etc.

I am willing to do either or both.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

[Joe Abley]

On Apr 7, 2022, at 21:10, Paul Vixie  wrote:

> but it seems to me you'd be better off with a zero-length option called 
> SERIAL which if set in the query causes the SOA of the answer's zone to be 
> added to the authority section (similar to an RFC 2308 negative proof) and 
> which option would only be echoed in the answer's OPT if the option was 
> supported. you'd want to specify that the SOA in this case is not optional 
> and that its truncation would cause the TC bit to be set.

That sounds like a lovely and clean way to do this. I like it. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

[Joe Abley]

On Mar 25, 2022, at 16:28, Benno Overeinder  wrote:

> With this email we start a period of two weeks for the call for adoption of 
> draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list.
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.

I think this draft is suitable for adoption. 

> Please also indicate if you are willing to contribute text, review, etc.

I am (either or both) if I can be of use. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC as a Best Current Practice

[Joe Abley]

On Mar 22, 2022, at 10:06, Masataka Ohta  
wrote:

> Bjorn Mork wrote:
> 
>>> Plain DNS with long enough message ID is secure enough.
>> Hello!
>> Can you please point me to the set of RFCs (or draft) which describes
>> this "secure enough" alternative to DNSSEC?
> 
> As I wrote "rely on DNS cookie or something like that",
> an example is in rfc7873.

Could I perhaps summarise what you're saying as follows?

1. The cost of DNSSEC signing is high, e.g. due to increased complexity, 
brittleness of the DNS, perhaps as shown by relatively low demonstrated 
system-wide deployment;

2. The threats that DNSSEC protects against are not high-probability threats, 
especially following the adoption of various resolver-hardening techniques 
adopted following the late Dan Kaminsky's various observations;

3. The threats that DNSSEC protects against are not high-impact either since 
they affect one layer amongst many for most applications;

4. Protocols and applications that depend on cryptographic assurances in the 
DNS (DNS as PKI) are few and far between, e.g. low uptake of DANE for protocols 
other than SMTP;

5. The cryptographic assurances in DNSSEC in any case are not absolute, e.g. 
since they depend on accurate trust anchor maintenance that is subject to 
interference by nation states, mobile device management, manipulation through 
system compromise;

6. Better to avoid the cost of DNSSEC deployment given its low value and focus 
instead on other approaches like cache-hardening or improving transactional 
integrity using cookies. 

Does that come close to what you're getting at?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt

[Joe Abley]

On Mar 9, 2022, at 00:12, Shumon Huque  wrote:

>> This document looks good. Some comments:
>> 
>> In fact, the Extensible Provisioning
>> Protocol (EPP) [RFC5731], that is often used by TLDs to configure
>> delegation parameters has no provision to set the TTL.  This inhibits
>> a child zone owner's ability to make more rapid changes
>> 
>> This is somewhat misleading. Even if EPP had the functionality, the
>> parent zone would still want to set their own TTL to reasonable values
>> for _their_ dpeloyment considerations. So the implication of the problem
>> of "EPP cannot set TTL" is not really right. I would remove this text.
> 
> The first sentence is fact.

Since the E in EPP stands for extensible, and since there's an active community 
(an active ietf working group, even, with participants who are registry 
operators) working on such extensions, I'm not sure the truth of the first 
sentence is useful generally.

in any case, I agree with Paul that the operator of a child zone generally 
should have no expectation of being able to influence the TTL in the delegation 
NS set (above the zone cut).

I also think it makes sense just to remove this commentary. 

>>When a delegation response is received during iteration, a
>> validation query should be sent in parallel with the resolution of
>> the triggering query

"Referral response" not "delegation response" I think. 


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

[Joe Abley]

On Dec 15, 2021, at 18:11, Brian Dickson  wrote:

> Overly-pedantic clarification on wording/semantics:
> Glue is non-authoritative data in a zone, where the owner name of that glue 
> data is below some zone cut (or otherwise out-of-zone, like different-TLD, if 
> that is even permitted by the zone owner's policies.)
I think with that text you just introduced three more terms that need a 
definition ("glue data", "out-of-zone" and "different-TLD").


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

[Joe Abley]

On 29 Nov 2021, at 14:56, Paul Hoffman  wrote:

> On Nov 29, 2021, at 11:48 AM, Joe Abley  wrote:
>> The idea of modifying the protocol to accommodate namespaces outside the DNS 
>> is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS 
>> could just concentrate on being the DNS and other namespaces can fight their 
>> own battles?
>
> This bit of wrong text originates with RFC 6761:
>   5.  Authoritative DNS Servers:
>
>   Are developers of authoritative domain name servers expected to
>   make their implementations recognize these names as special and
>   treat them differently?  If so, how?
>
> [...]
>
> #5 explicitly talks about expectations on developers of authoritative *DNS* 
> servers dealing with names that are not in the DNS. In retrospect, this was 
> probably a mistake. (In retrospect, that mistake was probably caused by 
> exhaustion from the discussion.)
>
> Despite the nausea-inducing of Peter's suggestion, I think folks here need to 
> deal with it, if for no other reason than RFC 6761 still being a standard.

6761 surely doesn't require any particular answers to those questions, thoug; 
it just requires the respective issues to be considered. Perhaps an alternative 
approach in this case is to update the answer to (5) to be "no" and update the 
answer to (6) accordingly?


Joe


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

[Joe Abley]

Hi Peter,

On 29 Nov 2021, at 14:25, Peter van Dijk  wrote:

> On Mon, 2021-11-29 at 14:16 -0500, Paul Wouters wrote:
>> On Mon, 29 Nov 2021, RFC Errata System wrote:
>> 
>>> Original Text
>>> -
>>>  5.  Authoritative DNS Servers: Authoritative servers MUST respond to
>>>  queries for .onion with NXDOMAIN.
>>> Corrected Text
>>> --
>>>  5.  Authoritative DNS Servers: Authoritative servers MUST respond 
>>> non-authoritatively to
>>>  queries for names in .onion.
>>> The original text for 5 and 6 is conflicting. A name server cannot respond 
>>> with NXDOMAIN (which is an authoritative answer) without having a zone 
>>> configured to serve that NXDOMAIN from. Clearly the intent of the text is 
>>> that clients will not find authoritative answers to .onion queries anywhere 
>>> in the DNS.
>> 
>> The corrected text does not describe what to return though. I guess the
>> text implies REFUSED, but perhaps the WG reasoned this was not good as
>> it would lead to more queries to other servers or instances of the
>> authoritative server set?
> 
> Yes, it implies REFUSED. I was unsure REFUSED was standardised, or
> whether it is still a convention that almost all auths happen to
> follow. REFUSED would indeed lead to resolvers trying other auths
> (although that seems a bit theoretical - where did the resolver even
> come up with the idea to ask a bunch of auths about .onion names?).
> 
> I also now realise that the root servers do not honour my new text, and
> their behaviour -is- correct, so perhaps:
> 
> 5. Authoritative DNS Servers: Authoritative servers (other than the
> root servers) MUST respond non-authoritatively to queries for names in
> .onion.

Yes, the root servers respond with an authoritative name error for QNAMEs under 
.ONION. For them to do otherwise would arguably break the commitment they have 
made many times to serve precisely the root zone provided to them by the IANA.

I do see the problem that the proposed erratum is trying to address. However, I 
don't see much difference between clients of a resolver receiving a 
non-authoritative name error (e.g. a negative response from a root server that 
has been cached) vs. an authoritative name error (e.g. a negative response from 
a resolver that has been configured to answer in such a fashion). And I don't 
really see the point in any RFC suggesting that they can MUST operators into 
acting in any particular way, regardless of whether the servers they administer 
are acting as recursive or authoritative.

The idea of modifying the protocol to accommodate namespaces outside the DNS is 
causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could 
just concentrate on being the DNS and other namespaces can fight their own 
battles?


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Deprecating infrastructure .INT domains

[Joe Abley]

On Nov 12, 2021, at 08:28, Masataka Ohta  
wrote:

> Kim Davies wrote:
> 
>> Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/
>> It’s a short document, but at its heart we’ve identified the
>> following domains that are referenced in places but seem to be obsolete:
> 
> That's fine. As the decision is made by IANA/ICANN, not IETF, it is
> appropriate that the intended status is not BCP but informational.

The operational decisions relating to these things have already been made, as I 
understand it -- the delegations no longer exist. Kim and Amanda's document 
seems to have two purposes: (1) to document this operational reality, and (2) 
to update protocol specifications to reflect that operational reality.

I don't see a conflict or expect a difficulty, but I don't think decisions 
relating to (2) lie solely with PTI; the IETF ought to have a hand in making 
them, which I think is what Kim and Amanda are trying to facilitate here.

Having said all that I think it's possible that the only domain under INT that 
has been implicated in standards-track documents is IP6.INT, and that was taken 
care of long ago. So I am not arguing with you about Informational, which is 
quite possibly the right thing.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Deprecating infrastructure .INT domains

[Joe Abley]

Hi Kim,

I like the idea of cleaning this up.

Choosing nsap.int as an example, I think it would be useful to either update 
RFC 1706 to make it clear that the advice in section 6 of that document no 
longer applies, and that no reverse mapping for NSAP is provided in the DNS. I 
don't think this is a great operational necessity since I imagine the number of 
people who expect this to work is approximately zero but it seems good to be 
tidy.

[I'd suggest reclassifying 1706 to historic but that'd also affect the 
specification for the NSAP RRType; maybe that's a good idea too, but it seems 
outside the scope of what you are trying to achieve, and I don't know how we 
would confirm that it's a good idea.]

Similar comment for other domains where there's similar existing advice.

Happy to offer actual text if that seems useful.


Joe

> On 11 Nov 2021, at 11:38, Kim Davies  wrote:
> 
> Colleagues,
> 
> I wanted to draw your attention to an Internet Draft we’ve developed,
> its goal is to formally deprecate a number of historic “.int”
> domains that were designated for Internet infrastructure purposes
> decades ago and appear for all intents and purposes obsolete. After some
> limited consultation on developing the approach so far, it would be
> useful to get some additional eyes on it so we have greater confidence
> there is nothing we’ve missed.
> 
> Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/
> 
> It’s a short document, but at its heart we’ve identified the
> following domains that are referenced in places but seem to be obsolete:
> 
> atma.int, ip4.int, nsap.int, rdi.int, reg.int, tpc.int
> 
> Most of these are not delegated in the int zone any longer, but there
> are lingering references to them.
> 
> Thanks in advance for any insight, and apologies if you get this message
> in duplicate,
> 
> kim
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Joe Abley]

On Nov 8, 2021, at 17:35, Wessels, Duane 
 wrote:

> Is this better?
> 
>   The use of TLS places even stronger operational burdens on DNS
>   clients and servers.  Cryptographic functions for authentication and
>   encryption requires additional processing.

Require, not requires. I know, I know.

>  Unoptimized connection
>   setup with TLS 1.3 [RFC8446] takes one additional round-trip compared
>   to TCP.  Connection setup times can be reduced with TCP Fast Open,
>   and TLS False Start [RFC7918].  TLS session resumption does not
>   reduce round-trip latency becase no application profile for use of
>   TLS 0-RTT data with DNS has been published at the time of this
>   writing.  However, TLS session resumption can reduce the number of
>   cryptographic operations.

[...]

> Agreed, hopefully this is better:
> 
>   o  Authoritative servers MUST support and service TCP for receiving
>  queries, so that resolvers can reliably receive responses that are
>  larger than what fits in a single UDP packet.

RFC 6891 anticipates reassembly and doesn't advise against setting a UDP 
payload size that would cause fragmentation (although it mentions that people 
should be careful). So "single UDP packet" seems a bit awkward, especially 
since in principle the size limit is 0x octets in both the UDP header and 
the corresponding EDNS(0) pseudo-header.

This paragraph (and the ones that follow) seem like they are implying that 
large responses are the only reason to use TCP (which is surely just a 
side-effect of wording; I'm not suggesting the authors are unaware of other 
reasons). Using truncated responses as an example seems fine though.

I don't think the taxonomy of "authoritative servers", "recursive servers" and 
"forwarders" is necessarily complete. The terminology in common usage is not 
tightly bound by common sense, and there is an apparently unlimited supply of 
words and phrases that people use to mean "a DNS thing attached to a network".

This seems like it could be a job for "initiators" and "responders", except 
that in this case I think we're really talking about all DNS implementations, 
regardless of function. Hooray! Bullet dodged, maybe.

How about something like:

 o All DNS implementations, regardless of function, MUST support and service 
TCP for sending and receiving queries, e.g. to accommodate the sending and 
receiving of DNS messages that are too large to handle using UDP without 
truncation.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Joe Abley]

On Nov 3, 2021, at 08:49, Joe Abley  wrote:

> If there is any concern about DoH not receiving equitable treatment compared 
> to DoT, I think it's sufficient simply to observe that DoH is a horse of a 
> different colour and move on. 

(Those who are not familiar with that final phrase could perhaps Google it 
using Chrome as a worked example of HTTP over QUIC).


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Joe Abley]

On Nov 2, 2021, at 16:00, Roman Danyliw  wrote:

> I believe that if this draft is going to be the BCP to discuss DNS over TCP, 
> all of the flavors of DNS over TCP need to be covered.

I think it's sloppy to characterise DoH as a flavour of DNS over TCP, given 
that the H part doesn't necessarily involve TCP at all (and often doesn't in 
practice, for some ecosystems of clients and servers).

If there is any concern about DoH not receiving equitable treatment compared to 
DoT, I think it's sufficient simply to observe that DoH is a horse of a 
different colour and move on. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

[Joe Abley]

On Oct 7, 2021, at 10:43, Brian Dickson  wrote:

>> Do you mean reliably determine if a resolver is claiming to validate, or 
>> reliably determine whether a resolver is actually validating?
>> 
> Claiming… if the answer is that it is not claiming that, it might simplify 
> some parts of the logic on use of CD.
> 
> If there isn’t any way to reliably determine that it is claiming to validate, 
> that is unfortunate, and then begs the question on whether it is worth doing 
> anything about it.

I'm not sure what value such a claim would have anyway. 

If you need to be sure that something is correct to the extent that you require 
cryptographic proof, then you need cryptographic proof. This surely means you 
need to establish a path of trust from an anchor to the leaf you care about. 

Some unsigned promise from an external system to behave in any particular way 
surely doesn't meet the bar; if it does, then perhaps you don't in fact require 
cryptographic proof. 

So I think your question needs work. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

[Joe Abley]

On Oct 7, 2021, at 09:49, Brian Dickson  wrote:

> Quick question in a top-reply, sorry:
> Mark:
> Is there any combination of flag bits or EDNS options that a stub can use to 
> reliably determine if a resolver is validating?

Do you mean reliably determine if a resolver is claiming to validate, or 
reliably determine whether a resolver is actually validating?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] SHA-1 DS algo in arpa. :)

[Joe Abley]

Hi Paul (W),

On Sep 9, 2021, at 12:05, Paul Wouters  wrote:

> On Thu, 9 Sep 2021, Paul Hoffman wrote:
>> 
>> Did you first ask the administrators of the zone in question before sending 
>> this message to a grooup that has no administrative power over the zone?
> 
> No, I used this group as the umbrella contact, as I assumed the
> knowledgeable people are here.

The IETF (well, the IAB) has administrative control over the contents of the 
ARPA zone. I do not know in practice whether this extends to the machinery of 
how the zone is provisioned. 

The operation of the zone is carried out by PTI, I think. It is distributed to 
its authoritative servers (which are also root servers) in a process that is 
similar in some respects to the way the root zone is managed.

I would drop a note to Kim Davies and ask his advice if you want to make some 
kind of progress. While it seems perfectly plausible to make this kind of 
change by way of a published RFC with IAB review, it's not at all clear to me 
that such a heavyweight approach is necessary. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] DS glue for NS draft

[Joe Abley]

On Aug 18, 2021, at 15:29, Brian Dickson  wrote:

> I'd be interested in pointers if consolidation by authority operators is a 
> privacy concern. Authority operators only see traffic from resolvers, not 
> from end users, and all of the data served is by definition public.

This is a bit of a tangent, but I think it's reasonable to say that it's not 
the public nature of the data being sent in responses that is the concern, it's 
the existence of any particular query and the data derived from that query's 
existence.

For example, Dave Dagon gave a good summary some years ago now about the 
disturbing number of resolvers that happily send host addresses in EDNS(0) 
client-subnet options to authoritative servers. I haven't seen current numbers, 
but I think it's perhaps reasonable to be open to the idea that authority 
servers acquire data from queries that identifies individuals, even if only in 
a minority of queries or if combined with some other dataset that maps personal 
identities to addresses.

The trick here is to be clear about what threat we are trying to mitigate so 
that we can understand the cost and the benefit, who should be able to choose 
to accept the cost and who benefits.

I have not been able to keep up with the thread I'm replying to in all its 
glory since I don't have enough hours in the day to dedicate to dnsop, but I 
think perhaps that this particular fragment of the discussion needs to 
distinguish between what nameservers are called and who runs them. Namespace 
consolidation intended to promote opportunities to return useful glue with 
responses and reduce the need to requery is not the same as one operator 
serving a large number of zones. A nameserver responding on a single address 
can be known by many names.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] DS glue for NS draft

[Joe Abley]

On Aug 16, 2021, at 19:41, Brian Dickson  wrote:

>> On Mon, Aug 16, 2021 at 3:14 PM Ben Schwartz  wrote:
>> 
>> [...]

This thread makes me think draft-jabley-dnsop-refer wasn't as insane and 
operationally complex as I thought.


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Joe Abley]

On Aug 12, 2021, at 16:53, Paul Wouters  wrote:

> On Thu, 12 Aug 2021, Joe Abley wrote:
> 
>> I think the set of acceptable algorithms is constrained sufficiently often 
>> by registries and registrars that it makes little sense to consider any 
>> other case.
> 
> I think this problem is more easilly solved. You can reach out to them.

I wish you every success!


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Joe Abley]

Hi Paul,

On 12 Aug 2021, at 15:48, Paul Wouters  wrote:

> On Thu, 12 Aug 2021, Joe Abley wrote:
> 
>>> This would have been excellent to do when we did DS. It would still be
>>> good to do this now, I agree. But it would be too late for some of the
>>> things discussed now.
>> 
>> Can you talk more about why you think so?
> 
> I did a small presentation during IETF 111 DPRIVE. You can find the
> presentation deck and the recording on the IETF site.

Thanks, I will go and dig that out at some point.

>> Support for novel interpretations of particular DS algorithms will require 
>> support on both the provisioning and consumer side. Is it really that much 
>> more work to specify new DS-like RRTypes?
> 
> It does not neccessarilly require support on the provisioning side, as
> it is "just another DS record" from the provisioning point of view
> unless lawyers insisted the TLD somehow verifies the pubkey is
> pre-published or in an algorithm they 'support' (allow).

I think the set of acceptable algorithms is constrained sufficiently often by 
registries and registrars that it makes little sense to consider any other 
case. But you may have different use-cases in mind.

>> There's truck-roll in both cases. Neither path is really going to make these 
>> features generally available any time soon.
> 
> There is a huge difference between "support for a DS record with
> unknown or unexpected content at the RRR level" and "change all
> DNS and EPP software on the planet". The first one has like 1500
> actors. The second has millions or billions.

I agree, but I don't think that observation is particularly helpful.

My earlier point was that any mechanism that changes the implementation of a 
referral is going to need to be backwards compatible to validators and 
authoritative servers that don't support it. Truck roll is required not to 
maintain the integrity of the DNS, but to enable the new desired functionality.

I think there's a lot of inertia on the provisioning side and no matter what 
mechanism is preferred. It might seem like accepting a new DS algorithm is much 
easier, but in practice it might also be that you only need a new RRType to be 
supported in two or three code bases before substantially all TLDs have 
support. My experience is that it can take years to have new algorithms 
supported by the RR machinery, regardless of how simple they are to express and 
consume in the DNS. It's always worth remembering that registry systems are not 
DNS systems; they are operated and constrained very differently. Without data I 
would suggest it's not especially helpful to predict which path is more rocky.

On the resolver side, a very small handful of resolvers account for the bulk of 
the world's validation. But regardless of what critical mass you identify as 
important to establish, there's substantially the same weight of change 
required on the consumer side. Whether you special-case a DS hack or understand 
what to do with a new RRType received as part of a referral, you still need 
code changes.

> And as I argued, even if we do this by overloading DS or NS, is that
> overloading really something we need? As it is only required for
> privacy to nameservers that are in-bailiwick to the domain, which in
> itself is already pretty much a dead give away even when you only
> can observe encrypted TLS traffic to an IP address of a well known
> published nameserver.

I certainly don't fully understand the degree of risk from subverting a 
resolver to send a query to a bogus authority server. I am not arguing for or 
against any kind of mechanism to mitigate unsigned glue. So I don't have any 
order of preference. However:

> So my own order of preference is likely something like:
> 
> 1) Forget about protecting in-bailiwick nameservers
> 2) Do it securely using DS at parent
>   (only requires new code for validating nameservers that don't exist yet)

I don't understand what the parenthetical comment here means. You're suggesting 
that existing validating resolvers that don't know how to interpret a weird 
algorithm in a DS RRSet received during a referral don't need to be changed?


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Joe Abley]

On Aug 12, 2021, at 10:57, Paul Wouters  wrote:

> On Thu, 12 Aug 2021, Olafur Gudmundsson wrote:
> 
>> The DS record is a unique record that it lives only at the parent side of 
>> delegation, when DNS was defined no such records were
>> envisioned, if more are needed this working should take up a new work item 
>> to 
>> define a sub-set of the RRtype number space as Parent side-only to have a 
>> proper debate on the topic. 
> 
> This would have been excellent to do when we did DS. It would still be
> good to do this now, I agree. But it would be too late for some of the
> things discussed now.

Can you talk more about why you think so?

Support for novel interpretations of particular DS algorithms will require 
support on both the provisioning and consumer side. Is it really that much more 
work to specify new DS-like RRTypes? 

There's truck-roll in both cases. Neither path is really going to make these 
features generally available any time soon.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

[Joe Abley]

Hi Paul,

On Jul 30, 2021, at 14:55, Paul Wouters  wrote:

> We literally had a survey to ask us “what should we kill because we don’t 
> have enough time”

I don't think that's exactly the question I saw, but perhaps I misremember. 

For what it's worth (and as you know from our conversations about it on this 
list) I disliked your delegation-only draft on its merits and not because of 
lack of time. 

If the working group expresses similar sentiments about the 3166 private use 
codepoint draft I will be similarly disappointed, because I think there's 
non-zero value in documenting where we got to and I don't think it will be much 
work to do so. But life will go on. 

It's a shame we have to have these conversations exclusively over email instead 
of in a bar. I'm buying when we get to travel again. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

[Joe Abley]

Hi Paul,

On Jul 30, 2021, at 14:29, Paul Wouters  wrote:

> We are seeing the WG dropping actual protocol work because of these 
> discussions. I now consider these discussions harmful.

I think we've seen the working group drop particular proposed efforts for a 
variety of reasons. I don't think it's accurate to characterize them all (or 
any of them, to be honest) as victims to some special names obsession.

Sometimes the working group just doesn't like particular ideas, and we move on. 
Harmful is in the eye of the beholder, perhaps. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Joe Abley]

Hi Peter,

On 29 Jul 2021, at 14:39, Peter van Dijk  wrote:

> On this version, I see under New Working Group Business a draft (the
> black lies sentinel) that was posted two days ago. Can somebody please
> explain to me what the purpose of the draft cutoff is, if drafts can
> appear in the datatracker, and on an agenda, after the cutoff?

I believe it has long been the case that the IETF resumes accepting new 
documents at the start of IETF week. This allows people to document ideas that 
come up in corridors and in the bar during the actual event.

(Remember actual events? In the Before Times, we had them.)

The purpose of the cut-off as I understand it is that agendas and meeting slots 
are supposed to be organised long in advance of that, and that it's useful to 
suspend new documents to avoid the rug being pulled out from that 
administrative process.

The case where a document is submitted before the deadline and gets agenda time 
but is updated before the meeting is not unremarkable either, I think, although 
I think references to the new version would properly be made informally and 
obviously not in the slides that were definitely submitted well in advance.

I can't speak to the black lies draft, for which I understand new terminology 
is eagerly anticipated before anybody else mentions it, but that's my general 
idea of what is going on in the world.

I miss actual events.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Joe Abley]

On Jul 28, 2021, at 14:00, Paul Wouters  wrote:

> If the zone example contains amongst other content:
> 
> foo.example. IN NS ns0.foo.example.
> foo.example. IN NS ns0.bar.example.
> ns0.foo.example. IN A 1.2.3.4
> ns0.bar.example. IN A 1.2.3.5
> 
> Then for the DNS server returning an NS query for foo.example, it is
> easy to either:
> 
> 1) return ns0.foo.example's A record
> 
> or
> 
> 2) return ns0.foo.example and ns0.bar.example. A records`
> 
> What is harder to do is determining whether it should or should not
> include ns0.bar.example's A record based on whether it is "needed" or
> not, as there are various kinds of loops possible.

So your assumption is that it's easier to return all possible glue for every 
nameserver in the delegation set than it is to return glue for just that subset 
that are subordinate to the zone cut.

Perhaps this is a good opportunity to let actual implementers let us know what 
is what.

>> I don't see where the "extra CPU power" you are talking about comes from.
> 
> To determine if the glue you know you have is "needed or not".

As I said, it seems to me that this is absolutely knowledge that you can gain 
at load time and it's not necessary to wait until response time to do the work. 
So I think the CPU consumption argument is not especially persuasive. However, 
I am not an implementer.

Regardless, it does seem to me that glue for nameservers that are subordinate 
to the zone cut is the MUST and other glue is at best a MAY.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Joe Abley]

Hi Paul,

On Jul 28, 2021, at 10:13, Paul Wouters  wrote:

> Do you want dns servers to spend extra CPU power to lookup whether this is a 
> “non-functional” glue case instead of spending less CPU just looking if it 
> has a glue record and adding it?

I'm not sure I understand your argument about what is more work for the 
authority server.

Checking whether a referral targets nameservers whose owner name is below the 
zone cut seems straightforward. This is work that authority-only servers 
already do. It also seems entirely possible to do this work at load time at 
which point it ought to be clear that the zone cut exists; it's not something 
that must happen at response time.

I don't see where the "extra CPU power" you are talking about comes from.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Joe Abley]

On Jul 28, 2021, at 07:51, Ralf Weber  wrote:

> On 28 Jul 2021, at 5:10, Paul Wouters wrote:

> 
>> First, as Mark said, sibling glue is sometimes needed.
> It is only needed for broken circular dependancies, which we don’t care about.

I tend to agree with this. 

There are a lot of ways a delegation can be non-functional (for example the 
circle of dependencies can be as big as you like, can incorporate third cousin 
twice removed glue, etc) and it makes more sense to me to let all of these 
cases fail rather than incurring the cost of papering over just some of them in 
the authority server.

As many people have pointed out, recursive servers will often ignore 
Kaminsky-looking glue anyway, so the result of including it is going to be very 
much like intermittent failures that are painful to diagnose and have the 
effect of making the DNS less stable.

From this perspective it's a greater kindness to all concerned to fail 
consistently when such configurations are first deployed.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Joe Abley]

On 27 Jul 2021, at 16:15, John Levine  wrote:

>> * Section 5: Promoted or orphan glue
>> The considerations for handling orphan glue will be different for a
>> TLD vs a lower level zone within a domain. I would think that orphan
>> glue in a TLD context should go away when a zone is deleted/expired.
>> Maybe even have sanity checking to prevent such an operation.
> 
> This is a political question, not a technical one. If the DNS operator
> has external knowledge that the orphan's domain has not been delegated
> to someone else, you can make a case to leave the glue. The usual
> example is a name in a TLD which has expired but is still in the grace period,
> but it can happen anywhere someone delegates names; I run registries
> at the third level like watkins-glen.ny.us.
> 
> I don't see how we can offer any more than general and vague advice here.

I agree, and I think the best plan is to remove any mention of it. Orphan glue 
is by definition not glue. It once was glue, but that has no bearing on how to 
craft a referral response. It's out of scope for this document.

At best, I think the term "orphan glue" belongs in a taxonomy concerned with 
registry terminology, not DNS terminology. And although one of the ways in 
which domain registries publish information is in the DNS, it's rarely a good 
idea to conflate the two.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF meeting prep and what

[Joe Abley]

On 30 Jun 2021, at 14:59, Peter van Dijk  wrote:

> I feel that the right mechanism for root key distribution is software 
> distributors. This is working fine for the CA system, and with keys announced 
> far enough in advance, should work fine for DNSSEC. Software distributors 
> have solved this problem; they are very good at distributing things; I 
> suggest we let them solve this for us.

We actually spent some time back in 2009/2010 packaging trust anchors in a way 
that could take advantage of existing (e.g. code-signing) PKIs, specifically to 
facilitate distribution to software vendors. I haven't checked very recently, 
but I don't think there was any sign that the mechanism was being used by 
anybody in the decade or so that followed. See RFC 7958 section 2.3.

I mention this simply because it was our best guess at the time at how to 
distribute trust anchors securely (with a respectable chain of custody) from 
the KMF in which the keys were generated right through to the code publication 
pipeline operated by software vendors. Quite possibly it was a bad guess.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

[Joe Abley]

On 24 Jun 2021, at 19:21, John R Levine  wrote:

>>> I'd also like it to say more clearly up front that .ALT is for names that 
>>> are
>>> totally outside the DNS protocols, not for names handled locally using DNS 
>>> protocols.
>>> It's for things like .onion, not like .local.
>> 
>> Both .onion and .local use protocols other than the DNS, acknowledging of 
>> course that the protocol used for names under .local is quite DNS-like.
> 
> My wording wasn't great -- .local resolves to an IP address while .alt 
> doesn't.

I'm not sure that helps. Some (but, sure, perhaps not all) non-DNS resolution 
protocols can certainly be used to identify IP addresses. Not all queries under 
.local are for addresses, either. PTR, SRV and TXT are common, for example.

>> Did I miss the conversation where the working group decided to pivot? (Not a 
>> rhetorical question! I am very prepared for the answer to be yes :-) If 
>> anybody has a handy pointer to the relevant part of the mailing list archive 
>> I'd appreciate it.
> 
> If you mean draft-arends-private-use-tld, that was tilting at a different 
> windmill.

I'm quite familiar with draft-ietf-dnsop-private-use-tld; I'm a co-author.

draft-ietf-dnsop-alt-tld was adopted by the working group as a way to anchor a 
set of possible namespaces that had no requirements to be globally unique, or 
had no "meaning on the global context" or were not "delegated in the DNS".

   In order to avoid the above issues, we reserve the ALT label.  Unless
   the name desired is globally unique, has meaning on the global
   context and is delegated in the DNS, it should be considered an
   alternate namespace, and follow the ALT label scheme outlined below.
   The ALT label MAY be used in any domain name as a pseudo-TLD to
   signify that this is an alternate (non-DNS) namespace.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/00/ section 3

The document doesn't call it out as an explicit example, but I thought it was 
intended that the set of candidate namespaces included private-use 
(non-globally-unique) namespaces that use the DNS, as well as namespaces that 
use other resolution protocols.

alt-tld-13 makes it much more explicit that .ALT is not intended for namespaces 
that use the DNS. So this is a change from the original document.

It looks like this change happened between -07 and -08 (e.g. "Made it clear 
that this is only for non-DNS" in Appendix A) but I don't recall any 
conversation about reducing the scope on the mailing list. That's what I was 
asking about.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

[Joe Abley]

On Jun 24, 2021, at 14:37, John Levine  wrote:

> It appears that Ben Schwartz   said:
>> I think the "Privacy Considerations" section should probably mention QNAME
>> minimization, which ought to help a little.
> 
> I'd also like it to say more clearly up front that .ALT is for names that are
> totally outside the DNS protocols, not for names handled locally using DNS 
> protocols.
> It's for things like .onion, not like .local.

Both .onion and .local use protocols other than the DNS, acknowledging of 
course that the protocol used for names under .local is quite DNS-like.

More generally, if the intention of the .ALT proposal is to anchor namespaces 
that don't use the DNS protocol then I'm confused. I thought it was intended 
exactly to anchor namespaces that use the DNS protocol, just in a way that 
deliberately didn't provide any guarantee of uniqueness. The -13 text says 
otherwise in the introduction, however, so either my memory is more faulty than 
I thought or the direction has changed.

Did I miss the conversation where the working group decided to pivot? (Not a 
rhetorical question! I am very prepared for the answer to be yes :-) If anybody 
has a handy pointer to the relevant part of the mailing list archive I'd 
appreciate it.

ObReviewContribution: the authors list includes one A. Sullivan; let it be 
known that Mr Sullivan no longer works for Oracle.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF meeting prep and what

[Joe Abley]

On 23 Jun 2021, at 12:28, Vladimír Čunát  wrote:

> On 18/06/2021 19.40, Peter van Dijk wrote:
> 
>> I propose replacing rfc5011-security-considerations with a short document 
>> deprecating 5011 in its entirety. I am happy to write text for that, if 
>> there is an appetite - when the WG queue is small enough!
> 
> I agree that 5011 doesn't seem really useful (anymore).
> 
> We have it in Knot Resolver but recommend not to use it, because it's just 
> more trouble than worth in practice.  Notably, (all) resolver software needs 
> much more frequent updates than the rate of root KSK rollovers, so it's 
> easier to distribute root DS within the updates; some Linux distros even 
> package these separately and share them among different resolver packages.  
> Even if you're conservative and use BIND ESV or similar, I believe it's a 
> better approach than 5011.  For non-root keys there doesn't seem much point 
> nowadays, as getting a chain from root is better.
> 
> (By the way, an "interesting" example: router with DNSSEC validation and 
> factory reset / rollback, commonly shelved for a year, unreliable clock, etc.)

There are a variety of mechanisms available to identify and configure a trust 
anchor to use in a validator, some automatic and some manual; some rely upon 
having an existing, functional trust anchor to introduce a new one, some use 
other trusted paths such as vendor update processes and the web PKI. There are 
almost certainly mechanisms we don't know about, as well as the variety with 
which we are familiar.

There are also a variety of scenarios in which trust anchor maintenance is 
important. Some scenarios involve informed administrators; some involve 
uninformed users; some involve isolated devices that have no immediate human 
administrator or user. Some (as you point out) feature long air-gapped periods 
between configuration and use. We do not have a complete understanding of the 
breadth of the set of scenarios.

Given that there is such a variety of existing mechanisms and possible 
use-cases, and considering the profound lack of measurement which could inform 
us about which mechanisms are being used (or work) and which are not (or 
don't), I think it's premature to start talking about retiring particular 
mechanisms either as operational practice or in the sense of deprecation.

As one of the people who spent painful amounts of time trying to contact people 
by phone and e-mail to find out whether the dirty signals we were worried about 
during the last (and only!) root zone KSK roll, I can attest that RFC 5011 
certainly works well for some people. I think it's fair to say we don't have a 
good way of quantifying that data point into a more general statement that is 
stronger than anecdotal. This is not a firm foundation on which to build a plan.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF meeting prep and what

[Joe Abley]

On Jun 18, 2021, at 16:36, Paul Wouters  wrote:

> Sure, but if we were to deprecate 5011, what would we expect to happen
> when we want to do another rollover ?

To be more clear, I was *not* suggesting that 5011 should be deprecated.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF meeting prep and what

[Joe Abley]

On 18 Jun 2021, at 14:45, Paul Wouters  wrote:

> On Jun 18, 2021, at 13:41, Peter van Dijk  wrote:
> 
>> I propose replacing rfc5011-security-considerations with a short document 
>> deprecating 5011 in its entirety.
> 
> Eh? 5011 is baked into various software. Why would replace 5011 ?
> 
> Did I miss something?

There were some conversations adjacent to the last great root zone KSK roll 
excitement about how a more measurable and reliable mechanism might be useful. 
My memory is that there might be value in specifying a new mechanism that could 
be used as an alternative to or in conjunction with 5011, though, not that 5011 
was fundamentally unsound and deserved to be deprecated.

I agree that, in the end, 5011 seems to have done a reasonable job -- it was 
just hard to predict with any degree of comfort or certainty.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial

[Joe Abley]

Hi Hugo,

On 1 Jun 2021, at 10:05, Hugo Salgado  wrote:

> On 13:20 01/06, Peter van Dijk wrote:
> 
>> I like this. I suspect defining it well for answers from resolvers to
>> clients would open up a big can of worms that could kill the draft,
>> like many other drafts that have been crushed under the sheer weight of
>> scope creep.
> 
> Yes, fair enough. Furthermore, the draft currently avoids talking about
> "client" and uses "querier", which from the authoritative point of view
> could be a debugging human or a resolver.

Some DNS documents have used the words "initiator" and "responder" to describe 
the actors involved in either side of an exchange of DNS messages. That might 
be worth considering.

I agree that avoiding the complication of caches makes sense. Perhaps linking 
the behaviour to AA header bit processing would be useful. An individual DNS 
server might be principally a resolver by function but might also respond 
authoritatively (AA=1) to some queries. Those queries ought to be in-scope for 
your mechanism, I think.


Joe


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

On 12 May 2021, at 17:39, John Levine  wrote:

> It appears that Joe Abley   said:
> 
>> Do you know of an example of a DNS authoritative or recursive server that 
>> does return truncated RRSets in the ANSWER section?
> 
> A lot return truncated glue in the ADDITIONAL section.  Are we sure that 
> wouldn't be an issue with SVCB?
> I honestly don't know.

I agree that truncation in the ADDITIONAL section is expected. Since the SVCB 
is expected to be used in RRSets with more than one member RR (different SVCB 
RRs with the same owner name and class are explicitly contemplated by the 
draft) it already has to accommodate that (which I think is probably a noop, 
since it doesn't seem to me that SVCB has different requirements in that regard 
to any other RRType).

I think Brian's point was that you can rely upon RRSets being intact in the 
ANSWER section.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

On 12 May 2021, at 17:03, Eric Orth  
wrote:

> On Wed, May 12, 2021 at 4:28 PM Brian Dickson  
> wrote:
> 
>> Responses including partial RRsets are as unlikely (and as illegal) as a 
>> response to a query for SVCB being a TXT record saying "I'm a teapot".
> 
> Agreed that there is no such issue with either wire format if all parties in 
> the ecosystem are bug-free and RFC-compliant.

Do you know of an example of a DNS authoritative or recursive server that does 
return truncated RRSets in the ANSWER section?

I appreciate the value of scepticism when it comes to these kinds of things, 
but I have never seen any data to suggest that this happens. So much of the DNS 
depends on correct behaviour here that I'm dubious that this is a real concern. 
If it's not a real concern, using it as justification for a particular design 
decision seems worth questioning.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

On 11 May 2021, at 12:32, Ben Schwartz  wrote:

> On Tue, May 11, 2021 at 9:20 AM Joe Abley  wrote:
>> On 11 May 2021, at 12:08, Ben Schwartz  
>> wrote:
>> ..
>>> * It saves at least 11 bytes of overhead per parameter by avoiding 
>>> repetition of
>>>   the name, type, class, TTL, and inter-pair binding ID.
> 
> ... but it inflates response volume in the case where a separate SvcParams 
> RRSet is able to be cached significantly longer than the SVCB RRSet.
> 
> It sounds like you're proposing a design in which the information in one SVCB 
> record is not just spread across multiple records in an RRSet, but actually 
> across multiple RRSets.

Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR 
becomes a pointer to a second RRSet with a different RRType. So the SvcParams 
information is spread across multiple records in a a different RRSet from the 
SVCB RRRSet. If it's still not clear what I mean, I can try again.

Note that I'm not proposing a change to the spec, just illustrating that 
different design choices were possible that avoid the need for delimiters or 
escaping.

While we're on the topic of RRSets and multiple RRTypes, the way that AliasMode 
and ServiceMode are distinguished is also a bit clunky; what are the 
implications of needing to remove all ServiceMode RRs in an RRSet in the event 
that one of them is found to be in AliasMode if we imagine that some consumers 
of these responses will get it wrong? Was there any thought given to an RR 
schema that prevented such ambiguities from being published?

>  That is not just a variation on SVCB, but an entirely different proposal.

I'm not sure how you think of those two things as different. Isn't every 
variation of something a new something?

>>> * It provides a wire format whose structural nesting matches the logical 
>>> scope
>>>   of each key=value pair, and avoids requiring cross-RR reconstruction of
>>>   bindings by the client.
>> 
>> This seems like it is documenting a design choice rather than explaining it. 
>> The decision to include a list of key-value pairs in the SVCB RDATA is good 
>> because it avoids having to do something different?
> 
> To restate this sentence, it is good because the concrete syntactical 
> structure matches the abstract conceptual structure, and (relatedly) because 
> it simplifies client implementation.

What are the concrete syntactical structure and the abstract conceptual 
structures? If those are terms of art I apologise; I'm not familiar with them.

What are you comparing the client implementation to in your final comment? What 
other design option was found to be more complex to implement on the client 
side?

I'm sure it feels frustrating to get all these questions at the last minute, 
and I apologise (as I think I said before) that I did not follow this work more 
closely, earlier.


Joe


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

Hi Ben,

On 11 May 2021, at 12:08, Ben Schwartz  
wrote:

> OK, I've proposed text documenting the reasoning here: 
> https://github.com/MikeBishop/dns-alt-svc/pull/323/files 
> .

I definitely appreciate the effort, since I think I agree that documenting the 
design decisions are a good idea. However, I think perhaps the reasoning needs 
more work (see below).

> The proposed text is:
> 
> Storing a key-value map within a single RR, rather than placing each key-value
> pair in a separate RR, provides the following advantages:
> 
> * It enables a familiar key=value zone file syntax that matches zone authors'
>   experience with command-line arguments and other typical key-value mappings.

Since zone files generally don't include any key value pairs of the kind SVCB 
currently specifies, I don't understand this point. Surely the unfamiliarity 
with how to parse this kind of syntax illustrates that this is not familiar?

> * It avoids requiring zone file authors to manage inter-pair binding IDs.

I think you will have to expand that point, since I'm not convinced I 
understand what you mean.

> * It makes each record independently meaningful, consistent with the usual
>   convention for DNS records (c.f. SRV, MX, , etc.).

If you think of the DNS itself as a key-value store, with keys of the form 
(QCLASS, QTYPE, QNAME) then the corresponding value is an RRSet, not an 
individual resource record. Individual RRs are not returned in responses; 
RRSets are (understanding that the results are not functionally different in 
the case of an RRSet with a single member).

Your examples of SRV, MX and , somewhat ironically, are all prime examples 
of why the whole RRSet matters and you can't rely on a single RR from a set in 
a respose.

> * It saves at least 11 bytes of overhead per parameter by avoiding repetition 
> of
>   the name, type, class, TTL, and inter-pair binding ID.

... but it inflates response volume in the case where a separate SvcParams 
RRSet is able to be cached significantly longer than the SVCB RRSet.

> * It provides a wire format whose structural nesting matches the logical scope
>   of each key=value pair, and avoids requiring cross-RR reconstruction of
>   bindings by the client.

This seems like it is documenting a design choice rather than explaining it. 
The decision to include a list of key-value pairs in the SVCB RDATA is good 
because it avoids having to do something different?


Joe


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

Hi Ben,

On 10 May 2021, at 12:56, Ben Schwartz  wrote:

> I don't support breaking the SvcParams into separate RRs across the RRSet.  
> This would be an extremely inefficient encoding in wire format,

I think that assertion may well be worth challenging, and...

> and would conflict with the usual understanding of resource records as 
> independently meaningful alternatives.

... I think we disagree about how we usually interpret the use of RRSets with 
more than one member RR.

>  It would also require a dramatic rewrite of a specification that is now 
> widely deployed.

However, this seems clear (see my earlier horse/sailed comment). Given that the 
draft semantics of SVCB have already seen some implementation, any new 
semantics would need a new RRType (SVCC? :-)

I admit I have a certain aesthetic bias here since I find the entire concept of 
embedding a list of parameters inside a single RR to be very un-DNS-like. 
However, I found Mr Wouter's concerns (paraphrasing, "perhaps we should 
pre-allocate a set of CVE numbers for this") worth considering, and would hope 
that if there is a reason to burn the current RRType on security grounds (or 
any grounds more compelling than aesthetic) that we would do so.


Joe


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Joe Abley]

Hi Vladimir,

On 10 May 2021, at 04:32, Vladimír Čunát  wrote:

> On 10. 05. 21 10:19, Petr Špaček wrote:
>> I think the proper solution should be a real multi-query option, which 
>> incidentally provides a superset of RRSERIAL capabilities.
> 
> If multi-queries require the records being in sync (if from the same zone), I 
> really dislike the implications of them being sent to resolvers, especially 
> for many questions at once.  Caching, in particular.

Yes, I agree with that. Perhaps we could specify that a request for an RRSERIAL 
MUST only be satisfied for a response with AA=1, so that only servers that are 
able to provide an authoritative response to the original query will return it.

In contrast, I think there are probably use cases for a server that can't 
provide an authoritative response (e.g. a recursive server) to process a more 
generic multi-question query. So this seems like a reason to consider the two 
problem statements separately. I don't know exactly what use cases Petr had in 
mind for that though, so I'm guessing slightly.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

Hi Pieter,

On 10 May 2021, at 11:23, Pieter Lexis  wrote:

> You then invite the following issues:
> 
> Clients need to match the tuple (ownername + prio + target) and get all
> data from all matched rrsets, whereas now you get all that data in one
> piece of rdata.

Inviting that issue is also a potential benefit, but I agree that the 
implication exists. For example, the ability to publish sets of SvcParams with 
long TTLs ought to increase the probability of cache hits for that data and 
reduce SVCB response sizes.

> A client also can't figure out (if not doing DNSSEC valdiation
> themselves) if you have received all the SVC data for a certain name.

A client can't figure out without DNSSEC whether anything they have received is 
correct in, in general. So setting aside that more general authentication 
problem, I don't think it's correct to say that a client cannot tell whether 
they have received a complete RRSet in the answer section of a response. It's 
either there and complete or it's absent (and perhaps TC=1 if the reason for 
its absence is message truncation).

There should be no response possible in an implementation that adheres to the 
protocol in which a truncated RRSet appears in the answer section. If we're 
widening the net to implementations that don't follow the rules then I agree 
anything is possible.


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

On May 10, 2021, at 05:42, Pieter Lexis  wrote:

>> On 5/9/21 2:01 PM, Dick Franks wrote:
>> Pre-processing of '\\,' into the RFC1035 standard '\,' is
>> superficially attractive, but also fraught with danger.
>> 
>> A parser could have some fun with this one:
>> 
>>$ORIGIN example.com
>>@   SVCB   1 foo
>> key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000"
>>; a.k.a.   ipv6hint=2001:db8::5c5c:2c00
> 
> A zone owner/editor would never even think of typing in IP addresses
> like that.

Right, but an attacker who wants to take advantage of the impact of that 
observation in the construction of some parser might, which is why it's a 
security concern. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Joe Abley]

On May 9, 2021, at 19:27, Paul Hoffman  wrote:

> If I'm wrong about this being as good as it can be, there must be an item 
> delimiter that is better than a comma. I am not thinking creatively enough to 
> figure out what might be better than a comma. I'd be happy to hear proposals 
> for a better item delimiter. 

I am quite behind on this topic, but I presume there's a reason to put all 
these key-value pairs in a list in one RR?

If we compare the two fictional RRTypes EG1 and EG2 illustrated below:

example.com. EG1 key1=value1,key2=value2,...

example.com. EG2 key1 value1
example.com. EG2 key2 value2

It seems to me that EG2 avoids the need for delimiters at all. There's a bit of 
overhead resulting from the need for a larger RRSet but it's not obvious that 
that's a problem. 

If the SvcParams field of the SVCB RR was a domain name rather than an explicit 
list this would all look a lot more DNS-like as far as parsing goes. This would 
also allow a single set of SvcParams key-value pairs to be included in 
different service bindings without having to be sent each time or to be bound 
to something provided a service provider (SVB in customer.org zone that refers 
to SvcParams.provider.com) giving the provider some ability to maintain some 
aspects of the service).

Perhaps this horse has already sailed but I thought I'd mention it. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Joe Abley]

On 7 May 2021, at 13:39, John Levine  wrote:

> It appears that Hugo Salgado   said:
>> -=-=-=-=-=-
>> 
>> I'll upload a new version to revive it, and ask for a slot
>> in IETF111 for further discussion!
> 
> It looks like it's worth considering, but I also wonder how
> relevant it is for DNS servers that don't use AXFR/IXFR and SOA
> serial numbers to keep versions in sync.

SOA serial numbers are definitely useful for the apex SOA/IN queries that are 
prerequisites to zone transfers. However, they're also really useful 
information for any dynamic zone that you're trying to troubleshoot. Successive 
queries are not necessarily going to return matching information.

By analogy, you can send a query to a nameserver and get a troublesome 
response, and debug with a HOSTNAME.BIND/CH/TXT query to see what server it 
was. But for a nameserver provisioned with anycast or as part of a cluster, 
those data points are not necessarily going to match, which is why NSID is good.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Joe Abley]

Hi Hugo,

On 7 May 2021, at 12:47, Hugo Salgado  wrote:

> I'll upload a new version to revive it, and ask for a slot
> in IETF111 for further discussion!

Just to add my voice to the chorus, I missed this the first time around so 
thanks, Mauricio, for mentioning it.

I haven't read the draft in detail but I do like the idea and could think of 
many times this would have been useful for data collection, debugging, etc.


Joe



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Comment: (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

[Joe Abley]

On 6 May 2021, at 14:48, IAB Executive Administrative Manager  
wrote:

> This is an announcement of an IETF-wide Call for Comment on 
> draft-iab-arpa-authoritative-servers-00.
> 
> The document is being considered for publication as an Informational RFC 
> within the IAB stream, and is available for inspection at:
> 
> 
> The Call for Comment will last until 2021-06-03. Please send comments to
> architecture-disc...@ietf.org and i...@iab.org.

I have read this document. It is good to see this work proceeding. It has been 
in the fridge for a long time and it's good to get it on the stove.

I have a few minor suggestions that the authors might like to consider.

1. In various places the text refers variously to phrases like "root 
operations" and "root server operations". I think the terminology could use 
some consistency; there are differences between the management of the root zone 
as a data object, its provisioning through the IANA functions operator and the 
Root Zone Maintainer and serving it on nameservers operated by Root Server 
Operators. If the document has things to say about this, even at a high level, 
I don't think there is harm in being clear. The authors are more aware of these 
differences than most other people and I don't think they need my editorial 
suggestions in this regard, but if it seems like it would be helpful to be more 
explicit by way of illustration I'd be happy to.

2. RFC 5855 which the document cites uses a naming scheme for the IP6.ARPA 
servers of the form .IP6-SERVERS.ARPA, and 
.IN-ADDR-SERVERS.ARPA for the IN-ADDR.ARPA servers. It seems to me that 
it would do no harm to choose a scheme for ARPA of the form 
.ARPA-SERVERS.ARPA for the ARPA zone; response size differences are 
minimal thanks to label compression and I think the scheme is more consistent 
(also with the names of the root servers). It also helps, I think, to give the 
impression that these servers are intended for a single purpose and are not 
general-purpose nameservers intended also to host other zones in the future 
(which I think would be a mistake).

3. This document describes a naming scheme under NS.ARPA (but see 2, above) 
without specifying whether it should be provisioned within the ARPA zone, or in 
a separate zone as was specified in RFC 5855. If the practice established in 
RFC 5855 (and in the root zone before it) was continued, this would be a 
separate zone hosted on the same servers as ARPA. If this ambiguity is 
deliberate (if it's desirable to leave this up to the whim of the IANA 
functions operator) then it would be good to document why. I think there are 
operational advantages to having zone cuts in the namespace, e.g. to preserve 
the possibility of hosting the child zones elsewhere, perhaps because it 
becomes operationally useful to sign them differently, speaking of which:

4. There's no mention of whether NS.ARPA (again, see 2, above), if it is 
provisioned as a separate zone, should be signed. Given the ambiguity in (3) I 
think this is a gap that could usefully be filled. I think it should be signed.

5. The term "in-bailiwick" feels awkward to me in the context of section 3.1, 
since to me it's a term associated with response construction and what is being 
discussed in that paragraph is namespace. However, since every TLD requires 
glue in the root zone I think the whole of the last paragraph could be safely 
removed. It's sufficient that ARPA be delegated according to normal practices 
for handling TLDs, and I don't think it makes sense to give the appearance of 
including special requirements for ARPA in this document, even if today they 
match everything else.

Hope this is helpful, and once again I'm glad to see this work is moving 
forward.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

[Joe Abley]

On 28 Apr 2021, at 08:29, Jaap Akkerhuis  wrote:

> Let me make some pedantic remarks about the terms used in this
> discussion.

Thanks Jaap, I welcome the accuracy :-)


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

[Joe Abley]

Hi Donald,

On 27 Apr 2021, at 22:34, Donald Eastlake  wrote:

> I am not comfortable with grabbing all the permanently unassigned 2-letter 
> country codes for DNS private use.
> 
> Note: I was the primary author of RFC 2606 and have been involved in this 
> sort of thing before. See
> https://datatracker.ietf.org/doc/draft-eastlake-2606bis/
> https://datatracker.ietf.org/doc/draft-ellermann-idnabis-test-tlds/
> https://datatracker.ietf.org/doc/draft-ietf-dnsind-local-names/
> 
> At one early point I considered the addition of a number of additional TLDs 
> for testing purposes to the draft that became RFC 2606 including, as I 
> recall, one that was 63 octets long and a number 2-letter codes taken from 
> the permanently unassigned 2-letter ISO country codes. John Postel rejected 
> such efforts and in particular, if I recall correctly, indicated that as IANA 
> (at the time when essentially all registries were Expert Review and John was 
> the universal expert) he would reject any effort to assign any DNS use to any 
> ISO 2-letter code, other than as a national country code, unless a liaison 
> was received from ISO explicitly permitting such use regardless of public 
> statements by ISO that ISO would not assign a use to such any or all such 
> code in the future. That may have been an earlier era but I think John 
> Postel's position should still have some weight. And I would note that more 
> recently, the IESG has wanted a liaison to be crystal clear about permissions 
> from other standa
 rds development organizations for anything that is at all questionable.

Thank you for that. I think that's helpful.

There is much that is anecdotal and surprisingly informal in the way that 
decisions around top-level domains are made, and it is not surprising to me 
that this topic is difficult to address as an engineering problem.

The current co-editors of this draft are not in tight agreement about the 
correct path forward. One of us, in fact, (not me) is waiting for public, 
crystal clarity from ISO about their future plans, for example. We have asked 
the working group in past meetings what their preference is, but I don't think 
we asked clearly, one of the presenters had connectivity issues during the 
working group slot, etc. The document is not currently clear on its approach 
and it is unsurprising that people are expressing a variety of discomfort.

Personally, I favour the approach that if the IETF has anything useful to say 
it should minimise the scope of its pronouncements with the goal of balancing 
useful engineering with the avoidance of politics. My suggestion was that there 
is a logical argument here that doesn't involve assignment ("grabbing") but is 
still useful. Here it is:

1. Certain ISO-3166-2 codepoints are designated as being for private use by ISO 
and will not be assigned for use by countries, economies, etc;

2. Those ISO-3166-2 codepoints continue to be used for correspondingly-private 
applications in a variety of applications that have nothing to do with the DNS, 
so the designation from (1) is recognised and widely used;

3. ICANN does not assign two-character labels as TLDs except by reference to 
ISO-3166-2;

4. Use of ISO-3166-2 private-use codepoints will not clash with any TLD 
assigned for use in the public DNS.

[So far all we have done is made reference to other organisations' policies and 
observations about how those policies are used. We have not assigned or 
recommended anything.]

5. Since the policies referred to by (1) and (3) have existed for some time in 
the past, it is possible that people have used these codepoints as private-use 
TLDs, and (perhaps more importantly) we cannot know that they have not been 
used in this way;

[This argument makes no assumptions about ICANN or ISO policy in the future; it 
simply observes that certain policies have existed in the past.]

6. Collisions between private-use namespaces and the public DNS namespace are 
harmful;

7. The IETF restricts future use of these code-points in protocols in order to 
avoid the possibility of collisions: the public DNS namespace should not 
include these code-points.

This argument, I think, opens the door for the IETF to say something useful but 
does not need to predict future policy decisions by other organisations or 
impinge on any other organisation's policy agenda: the IETF retires code-points 
all the time because they have been burnt in the wild, and this is just another 
example.

I think even without declaring these code-points to be assigned for private use 
in the DNS, such a document would be sufficient to document their use for that 
purpose and to be explicit that such use will continue to be possible and safe 
from collisions with the public DNS namespace.

As I mentioned earlier, this is just my opinion of how to proceed. The current 
draft contains a mixture of various approaches and the result, I think, is 
unsatisfying. I am very prepared to be wrong here, however, 

Re: [DNSOP] [Ext] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

On 21 Apr 2021, at 14:27, Paul Hoffman  wrote:

> On Apr 18, 2021, at 4:17 PM, Suzanne Woolf  wrote:
>> We’d like to advance this but it needs some active support, so we need to 
>> hear from folks who have found it useful, especially implementers.
> 
> It is indeed useful, and should be published. However, the wording in the 
> draft needs to be updated about living in the world where TCP is already 
> required. RFC 7766 has been a standard for over five years, but some parts of 
> draft-ietf-dnsop-tcp-requirements, notably the abstract and introduction, use 
> words that indicate that support for TCP is not necessary mandated.

The nuance that jtk pointed out on Monday was that 7766 largely punts on 
requirement for operators and instead focuses on requirements for implementers 
with updates on the standards track:

   Whilst this document makes no specific requirements for operators of
   DNS servers to meet, it does offer some suggestions to operators to
   help ensure that support for TCP on their servers and network is
   optimal.  It should be noted that failure to support TCP (or the
   blocking of DNS over TCP at the network layer) will probably result
   in resolution failure and/or application-level timeouts.

This document seeks to provide the same strong requirements language for 
operators, with updates as a BCP. That seems reasonable to me. The operational 
guidance in this document certainly seems to me usefully to fill a gap.

I think I just spaced on the distinction during my Monday-morning review, but I 
suppose I might not be the only one, and that might be a sign that this 
document needs to make that point more forcefully.


Joe


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

On 19 Apr 2021, at 12:40, Peter van Dijk  wrote:

> This note on statelessness is good, but I don't think it should be tied to 
> IPv6. Packets get lost in IPv4 too, especially when they are big, and even if 
> such evens trigger a report in the form of an ICMP message, the same 
> lack-of-state problem applies.

In IPv4, datagrams that need to be transmitted over a link with an MTU is too 
low are fragmented by the router attached to the link, assuming DF=0. There is 
no signal sent back to the source in that case. In IPv6 that doesn't happen.

In the v4 case a large DNS message (large enough to require fragmentation along 
the path) can be transmitted without the source having to retain any state. 
That's not true in v6.

So I think the v4 and v6 cases are different. That's why I attached that 
comment to the v6 case.

DNS messages can be lost in both v4 and v6 for a variety of other reasons, I 
agree.

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ even 
> proposes setting DONTFRAG socket options, and some servers out there already 
> send IPv4 replies with the DF bit set (the two I can verify immediately are 
> OpenDNS, and whatever is running on the router my provider gave me, but most 
> likely there are others too).

Setting DF=1 does seem like it would avoid the differences I was trying to 
allude to above, I agree. With DF=1 fragmentation (or not-fragmentation) is 
just another reason for a packet to get dropped.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

On 18 Apr 2021, at 19:17, Suzanne Woolf  wrote:

> We’d like to advance this but it needs some active support, so we need to 
> hear from folks who have found it useful, especially implementers.

I didn't mention explicitly before, sorry, but I think this is a good document, 
it's useful and it should be published.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

Hi John,

On 19 Apr 2021, at 07:57, John Kristoff  wrote:

> On Mon, 19 Apr 2021 07:31:49 -0400
> Joe Abley  wrote:
> 
>> NEW:
>> 
>>   The specification of the DNS allows both UDP and TCP to be used 
>>   as transport protocols for exchanging unencrypted DNS messages.
>>   However, for various reasons, the availability of TCP transport
>>   has sometimes been interpreted as being optional.  This document 
>>   clarifies the need to provide TCP transport for both clients and
>>   servers and strengthens the requirement of DNS implementations
>>   to support both.
> 
> Thanks for your careful read and thoughtful comments.  I would just
> point out that there is already a document that specifically requires
> this of the implementations, IETF RFC 7766.  This draft was
> specifically aimed at operators, which have that document had
> sidestepped "this document makes no specific requirements for
> operators".  So maybe a simple "implementations" to "operators" change
> of your text would work?

Oh, I missed that, sorry. Yes, I agree, "operators" makes sense.

Someone is going to ask whether this document, as a BCP, can update 1123 which 
pre-dates such designations as standard track. That person is not going to be 
me, however.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

Hi Suz,

On 18 Apr 2021, at 19:17, Suzanne Woolf  wrote:

> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
> )

I have read draft-ietf-dnsop-dns-tcp-requirements-07 and have the following 
comments, in flagrant defiance of George's advice to ship the document based 
mainly on considerations of age. :-)

I think these are all fairly minor.


Abstract, Section 4.4 "DNS-over-TLS"

The abstract includes the sentence "This includes both DNS over unencrpted TCP, 
as well as over an encrypted TLS session." The later section 4.4 says "this 
document applies equally well to DNS-over-TLS'.

The inclusion of DoT looks like an afterthought that has not been entirely 
afterthought-through. The procedural updates to 1034 in section 3 clearly don't 
apply to RFC 7858; the justifiable confusion about transports in the DNS (the 
main topic of this document) also doesn't apply to 7858 which only specifies 
use of TLS, not DTLS.

I suggest that this document is really only concerned with strengthening the 
requirements around the use of TCP transport as described in 1034 and 1035 and 
that mentioning any other transport is unhelpful and arguably introduces more 
confusion. I think that sentence should be changed in the abstract to reflect 
that and section 4.4 should be removed. I would not be surprised to hear that 
this DoT text was added precisely to address some other earlier reviewer's 
opinion to the contrary, but this is what I think.

While we're at it, I think this document *requires* the practice of permitting 
TCP transport; it doesn't simply encourage it. So how about:

OLD:

   This document encourages the practice of permitting DNS messages to
   be carried over TCP on the Internet.  This includes both DNS over
   unencrypted TCP, as well as over an encrypted TLS session.  The
   document also considers the consequences with this form of DNS
   communication and the potential operational issues that can arise
   when this best current practice is not upheld.

NEW:

   The specification of the DNS allows both UDP and TCP to be used 
   as transport protocols for exchanging unencrypted DNS messages.
   However, for various reasons, the availability of TCP transport
   has sometimes been interpreted as being optional.  This document 
   clarifies the need to provide TCP transport for both clients and
   servers and strengthens the requirement of DNS implementations
   to support both.


2.3 EDNS0

RFC 6891 uses the notation EDNS(0), not EDNS0. Since 6891 obsoletes 2671 it 
seems reasonable to adopt its notation. I suggest going all search and replace 
on that.


2.4 Fragmentation and Truncation

The second paragraph does not mention another fundamental problem with 
stateless protocols over IPv6 when datagrams require truncation, which is that 
the requirement in v6 to fragment and resent from the source is not possible 
when the source has not retained any state regarding to the response that was 
just sent. While I had my hands in the patient I also added a small reference 
to tunnel encaps in IPv4.

OLD:

   For IPv4-connected hosts, the de-facto MTU is often the Ethernet
   payload size of 1500 bytes.  This means that the largest unfragmented
   UDP DNS message that can be sent over IPv4 is likely 1472 bytes.  For
   IPv6, the situation is a little more complicated.  First, IPv6
   headers are 40 bytes (versus 20 without options in IPv4).  Second, it
   seems as though some people have mis-interpreted IPv6's required
   minimum MTU of 1280 as a required maximum.  Third, fragmentation in
   IPv6 can only be done by the host originating the datagram.  The need
   to fragment is conveyed in an ICMPv6 "packet too big" message.  The
   originating host indicates a fragmented datagram with IPv6 extension
   headers.  Unfortunately, it is quite common for both ICMPv6 and IPv6
   extension headers to be blocked by middleboxes.  According to
   [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to
   receive a fragmented IPv6 packet.

NEW:

   For IPv4-connected hosts, the MTU is often the Ethernet payload
   size of 1500 bytes.  This means that the largest unfragmented
   UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
   although tunnel encapsulation may reduce that maximum message
   size in some cases.

   For IPv6, the situation is a little more complicated.  First,
   IPv6 headers are 40 bytes (versus 20 without options in IPv4).
   Second, it seems as though some people have mis-interpreted
   IPv6's required minimum MTU of 1280 as a required maximum.  Third,
   fragmentation in IPv6 can only be done by the host originating
   the datagram.  The need to fragment is conveyed in an ICMPv6
   "packet too big" message.  The originating host indicates a
   fragmented datagram with IPv6 extension 

Re: [DNSOP] draft-ietf-dnsop-delegation-only is still not useful

[Joe Abley]

On 7 Mar 2021, at 15:23, Paul Wouters  wrote:

> Note that the count presented has other issues too. For example,
> the first pseudo random domain I picked to look further from the top
> of the file:
> 
> info.txt.gz:ns1.breeat.info.  86400   in  rrsig   a   7   3   
> 86400   20201123152255  20201102142255  27464   info.   
> cDhuFyGRJqi2uJnAuYMuHguwvHQx498oIQawSOXNBMxewSnudEeeElsgXXw3vuN1t+tOX2v9Y+WMdB5Wh3I1gkon3xxC6ZX2njDq5wcqDNFIm/pGpZkM2Bwv/7uzU9Hx8r+Lmn3lNgyhEKFc0f/H8ESveGw93jK/bkoQnjQf5qI=
> info.txt.gz:ns1.breeat.info.  86400   in  rrsig   a   8   3   
> 86400   20201123152255  20201102142255  44286   info.   
> Kx2nR9MxG2NDbO8pYGlwET5JFjvIJnYMswvptkU/oqj2a5bb4i1qU9cBQg6P5zZ7ekstxCJjV08HyUkh30b9Sn/sCJovVA+OEoOEef4r+yij2XQN93kvli19fqNDfNPEnO8fQqZ3ifcvFvs8S1EEJKlcPVSsnlSVnFPPRVlye/U=
> info.txt.gz:ns2.breeat.info.  86400   in  rrsig   a   7   3   
> 86400   20201123152255  20201102142255  27464   info.   
> mVxcu2heoUVOuahh9GODtZBMomdYZ1MsiJ41nYAgf0SCUy8oD9qJ/7yCFZg7WOyiGNUHEtuyBBAyj6DxKbSURDOhZ3Auarha298bo2z4n8Q4HIBMjFWE4imQ9K9ZayB8j2uG8i7V8l7asnbGKvM1b4C7fnB43pY7L9pt8xcAIZc=
> info.txt.gz:ns2.breeat.info.  86400   in  rrsig   a   8   3   
> 86400   20201123152255  20201102142255  44286   info.
> 
> These are 4 RRSIG for 2 name servers with an A record for which the
> domain no longer exists.

Just a point of clarification -- the domain does exist; it's just suppressed 
from publication in the DNS.

jabley@manta ~ % whois -h whois.afilias.net breeat.info | fgrep Status
Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited
Domain Status: serverHold https://icann.org/epp#serverHold
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
jabley@manta ~ % 

When it comes to TLD zones, it's necessary to consider the registry data as 
well as the DNS if you want to be sure you are seeing the whole picture.

>  Note that ns1 and ns2 point to the same single
> IP address. I don't know how many other zones use these two nameservers,
> but a quick check shows that there are no DNS server running on that IP
> address anyway.
> 
> The TLD might as well just remove the glue. It is just garbage. It only
> causes users longer timeouts into the inevitable failure of reaching those
> nameservers. That is, actually not having these records is an _advantage_
> over having them.

gTLD operators can't just remove things that in its opinion are not working or 
not necessary. The things they can and can't do are constrained by contract. I 
appreciate that there are many registries that are not run by contracted 
parties, of course.

In general, it's difficult to know for sure what the impact of removing a 
linked glue record is. A nameserver that doesn't respond today might be fixed 
tomorrow, or might never be fixed for particular clients due to some other 
local policy. There may well be extraneous orphan glue records (in the DNS 
sense) in the ORG zone that could safely be removed, but it's difficult to know 
for sure unless you have certain knowledge about the names concerned and the 
intensions of the organisations involved in them. There are definitely orphan 
glue records (same sense) whose removal would cause operational problems for 
other domains.

[...]

> Regardless, as explains before. The problem is not hard to solve by
> moving the signed glue into its own delegated special zone, which would
> have the benefit of _clearly_ indicating to anyone who sees these NS
> records that the domain is about to fall over. It is an improvement to
> do this even if you don't do it to prepare for being a delegation_only
> zone.
> 
> Based on this and the recent .org glue cleanup, I think there might even
> be a good reason to write up a new draft about promoting-stale-glue-is-bad.

You should feel very free to write up whatever you want :-) but as I have 
mentioned a few times, so long as there are reasons to suppress publication of 
zone cuts for particular domains, e.g. for reasons of abuse management, and so 
long as it's possible to link subordinate host objects to other domain objects 
that *are* published, and so long as the data model specified in EPP remains as 
it is, the number of promoted glue records in zones like ORG are not going to 
reach zero and suppressing orphan glue (orphan in the DNS sense, not the 
registry sense) definitely has the potential to break things.

I don't think you make something a problem by calling it one. These things are 
only problems because you have a use-case for zones like these being delegation 
only, and the reality of how these zones are constructed doesn't fit nicely 
with that. I also don't think you can solve a problem by declaring the solution 
to be simple on the grounds that you've ignored all the things that would 
otherwise make the solution complicated :-)


Joe

___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] [Ext] DNSSEC Strict Mode

[Joe Abley]

Hi Ulrich,

On Mar 1, 2021, at 05:43, Ulrich Wisser  wrote:

> On 25 Feb 2021, at 16:11, Joe Abley  wrote:

> 

>> On Feb 25, 2021, at 06:53, Ulrich Wisser  
>> wrote:

>> 
>>> But this is a real world problem, one that is holding DNSSEC back.
>>> If you buy DNS operations the operator will usually tell you what algorithm 
>>> they use, you have no choice in that.
>> 
>> This feels like one of those areas where more specificity is needed. "DNS 
>> operations" is is over-broad; what you mean, I think, is "if you outsource 
>> zone-signing". If you sign yourself and distribute your zone to external DNS 
>> operators then you can add and drop vendors without worrying about key 
>> rollovers, for example.
> 
> Ok, I can be more specific. 
> 
> As a small business owner you have no way to move your hosting company to 
> change their DNSSEC configuration. (Besides that you most probably have no 
> idea that it exists.) You should be able to switch hosting providers without 
> thinking about security, a secure transition should be guaranteed by the 
> hosting companies, who can only do it if it is enabled by the protocol.

Even this really requires more specificity. What is a "hosting company"?

I think a lot of the problems we face with these kinds of scenarios is that 
various functionally-overlapping industries have sprung up without DNSSEC being 
much more than an afterthought in the way that products are structured and 
sold. It's perhaps unremarkable that the mechanics of offering these services 
are not a great fit.

We can try harder and harder to shoe-horn DNSSEC into products that don't 
easily accommodate it, for sure. However, there's an attendant risk that by 
doing so all we really achieve is making DNSSEC more operationally complex than 
it already is, and I think there's an argument that such an outcome would not 
make it easier to deploy.

> As a larger entity you might have compliance requirements for dnssec.

[As an entity large enough to pay significant fees for enterprise DNS service, 
the reality today is that you probably don't use DNSSEC at all.]

>> DNSSEC is normally part of a layered set of defences. In such an 
>> architecture relaxing one layer for a period in order to fix a problem or 
>> avoid a more complicated transition can be a perfectly acceptable answer. 
>> Going insecure for a short period in that context is not necessarily a 
>> cop-out; it could well be smart thinking.
> 
> I totally disagree. When has switching off security ever been a smart option?

If security was the only consideration, then nobody would connect anything to a 
network in the first place.

> It is only considered smart because the process of moving is so complex and 
> error prone. 
> And that is a “feature” of the protocol design. It’s not a law of nature.
> We could change the design to allow for secure transfer.

... and by doing so we could increase the complexity somewhere else.

I'm really just pushing back on the idea that going insecure for a planned, 
controlled period of time is necessarily a terrible idea. I often see these 
kinds of reactions from people seeing particular security measures as binary 
options, instead of taking a more holistic and risk-based approach, which is 
why my knee is jerking (I'm not suggesting that you are one of them).

If I rely upon a DNS vendor to sign my zone and I want to change vendors for 
some business reason, being able to switch easily at the cost of going insecure 
for 6 hours might be a much better answer than not being able to switch at all, 
or even having the cost of switching amplified by 100 person-hours of planning, 
or dealing with the risk of going dark to users downstream of 8.8.8.8 when it 
turns out that the change triggers another corner-case in Google's code base.

To the end-user, I can see why having a protocol element designed to make this 
easier and avoid the practical need to go insecure seems highly attractive, but 
we're really just shifting the cost of dealing with what might very well be a 
somewhat rare corner case to the developers, operators and users of every DNS 
server that supports DNSSEC. Even if the costs are low in the latter case, I 
think it's reasonable to say they are non-zero and universal, which means they 
might not be so low in aggregate.

In this context, the determination of what is smart and what is silly seems a 
little more grey to me than your message ("totally") suggests.


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] DNSSEC Strict Mode

[Joe Abley]

Hi Ulrich,

On Feb 25, 2021, at 06:53, Ulrich Wisser  
wrote:

> But this is a real world problem, one that is holding DNSSEC back.
> If you buy DNS operations the operator will usually tell you what algorithm 
> they use, you have no choice in that.

This feels like one of those areas where more specificity is needed. "DNS 
operations" is is over-broad; what you mean, I think, is "if you outsource 
zone-signing". If you sign yourself and distribute your zone to external DNS 
operators then you can add and drop vendors without worrying about key 
rollovers, for example.

> Now if your new operator doesn’t use the same algorithm you can’t switch 
> without going insecure.
> I don’t think this is an acceptable situation.

I agree that this is a factor that ought to be included in the process of 
deciding to move vendors. If your proposed new vendor can't do what you want, 
then presumably you don't move there. While it's always possible to make 
mistakes, it's not at all clear to me that particular problem is something that 
needs protocol-level mitigations.

DNSSEC is normally part of a layered set of defences. In such an architecture 
relaxing one layer for a period in order to fix a problem or avoid a more 
complicated transition can be a perfectly acceptable answer. Going insecure for 
a short period in that context is not necessarily a cop-out; it could well be 
smart thinking.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refer-00.txt

[Joe Abley]

On 12 Feb 2021, at 17:33, Paul Wouters  wrote:

> I think for the special processing this introduces, it doesn’t solve enough 
> problems.

Oh, I see what you mean. I was reading dangers vs. gains as risk vs. benefit.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refer-00.txt

[Joe Abley]

On 12 Feb 2021, at 15:37, Paul Wouters  wrote:

> On Fri, 12 Feb 2021, Joe Abley wrote:
> 
>> I have discovered that without liberal access to bars and hallways at 
>> in-person IETF meetings, I no longer know how to tell the difference
>> between ambition and insanity when it comes to technical proposals. I am 
>> quite prepared to find out that in this case the needle is at the crazy
>> end of the scale.
> 
> So I think execsum is, REFER is like NS for client, but signed like DS.
> 
> What does that buy us.

The draft has a section that describes a couple of other possible advantages, 
chiefly in avoiding the overloading of a single RRtype which consequently 
requires special handling downstream of the authority server; the kinds of 
problems that draft-ietf-dnsop-ns-revalidation hoped to solve, for example.

[...]

> Seeing how things would likely misimplement REFER, or run into issues
> because it gets semi supported through generic records and just flies
> along the wrong side of the zone cut, I'd say the dangers of this do
> not outweigh the gains.

Just so I understand your reaction, do you mean the dangers *do* outweigh the 
gains?

> If we do something drastic like this, at least provide not only the
> validatable child NS records, also provide whatever is needed to setup a
> fully encrypted connetion to the child's nameserver's so we can get
> a fully private query chain with no leaks.

I will have to think more about the extent that I think these different 
solutions overlap.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Joe Abley]

Hi all,

I have discovered that without liberal access to bars and hallways at in-person 
IETF meetings, I no longer know how to tell the difference between ambition and 
insanity when it comes to technical proposals. I am quite prepared to find out 
that in this case the needle is at the crazy end of the scale.

Happy Friday!


Joe

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-jabley-dnsop-refer-00.txt
> Date: 12 February 2021 at 10:52:38 EST
> To: "Joe Abley" 
> 
> 
> A new version of I-D, draft-jabley-dnsop-refer-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Name: draft-jabley-dnsop-refer
> Revision: 00
> Title:REFER: A New Referral Mechanism for the DNS
> Document date:2021-02-12
> Group:Individual Submission
> Pages:14
> URL:
> https://www.ietf.org/archive/id/draft-jabley-dnsop-refer-00.txt
> Status: https://datatracker.ietf.org/doc/draft-jabley-dnsop-refer/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer
> Htmlized:   https://tools.ietf.org/html/draft-jabley-dnsop-refer-00
> 
> 
> Abstract:
>   The Domain Name System (DNS) incorporates a namespace that is
>   comprised, in practice, of multiple so-called zones.  Each zone is,
>   in principal, a finite tree structure which can be administered
>   autonomously, and is connected to exactly one parent zone and zero or
>   more child zones.  These connection points are known as zone cuts; a
>   parent zone contains information that allows the servers responsible
>   for the child zone to be found.
> 
>   The current DNS specification encodes that information about child
>   zones using an "NS" resource record set in the parent zone, and a
>   corresponding "NS" resource record set in the child zone.  These two
>   resource record sets have identical owner names, class, and resource
>   record type but can differ in other respects such as the time-to-live
>   (TTL) attribute, the resource record data associated with each set
>   and the availability of cryptographic signatures.  This property of
>   being similar, related but potentially different has led to
>   operational complexity.
> 
>   This document proposes a change to how zone cuts are encoded in the
>   parent zone, allowing the resource records in the parent and the
>   child zone to be more clearly distinguished and protected separately
>   using cryptographic signatures.
> 
>   It is not at all clear that this is a good idea.  To restate in
>   stronger terms, the goal of the experiment described in this document
>   is to determine just how bad an idea this is.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Joe Abley]

On 6 Jan 2021, at 15:48, Ben Schwartz  wrote:

> On Wed, Jan 6, 2021 at 3:37 PM Joe Abley  <mailto:jab...@hopcount.ca>> wrote:
> On Jan 6, 2021, at 14:45, Ben Schwartz  <mailto:40google@dmarc.ietf.org>> wrote:
> 
> > That model works well when (a) all validators implement an algorithm you 
> > like OR (b) you view each algorithm as either "definitely strong" or 
> > "worthless" (no middle ground).
> 
> We are in scenario (b).
> 
> I think the long half-life of RSA-1024 is an example of a violation of (b).

Can you explain that in more detail?

A zone administrator today might decide that RSA with 1024 bit keys is 
sufficient, or that SHA-1 is reasonable.

A validator administrator might decide otherwise, and decline to gauge 
authenticity using those signatures.

These are both reasonable local policies. It's ok that they disagree.

> I don't think it is orthogonal.  The prevalent local validator policies 
> change the effect that zone owner choices will have, so zone owners need to 
> know what those policies are.

I agree it's useful to encourage local policies to be sane. I'm not sure why 
making the kind of change you are talking about achieves that.

It seems clear to me that changing the behaviour in validators would break some 
things; it's less clear that a change of the kind you suggest would make 
anything better. I am definitely not yet firing on all cylinders though, this 
year, so I am fully prepared to discover that I am missing something. :-)


Joe



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Joe Abley]

On Jan 6, 2021, at 14:45, Ben Schwartz  
wrote:

> That model works well when (a) all validators implement an algorithm you like 
> OR (b) you view each algorithm as either "definitely strong" or "worthless" 
> (no middle ground). 

We are in scenario (b).

When you sign a zone you choose one or more algorithms that are individually 
sufficient. Their relative strength is not important.

> Otherwise, the zone owner has a dilemma.  Should I protect fewer users with 
> higher confidence, or more users with lower confidence?  I think that is the 
> sticking point in this conversation.

I think zone owners are not protecting anybody; they are including a means to 
gauge authenticity in their responses so that validators can protect users.

There's nothing practically preventing validators from applying local policy in 
the way they determine whether a response is authentic. Whether or not that's a 
good idea is an interesting question, but I think it's orthogonal to how 
individual RRSets are signed. 

> Telling validators to "insist" that all signatures are valid would resolve 
> this dilemma.  Zone owners could add algorithms without weakening anything.

How do you deploy a new signing algorithm alongside an established one without 
going dark to users using validators that don't support it, in that case?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

[Joe Abley]

On 10 Dec 2020, at 19:41, Paul Hoffman  wrote:

>> "Authenticate authoritative servers" is a bit vague for me. Parent and child 
>> are namespace concepts and not relying parties that you'd ordinarily expect 
>> to be able to authenticate anything.
> 
> A resolver asks a parent what the NS records are for the child. Today, an 
> on-path attacker can change the answer and the resolver would not be the 
> wiser, so the resolvers cannot trust such answers to do things like look up 
> TLSA records. There is a desire for resolvers to be sure that what the child 
> NS records they receive from the parent is what the parent has in its zone 
> for the child so they can use this information to ask for TLSA records.

The problems that DNSSEC is trying to solve are with identifying inauthentic 
data ultimately requested by applications. If an intermediate referral response 
includes an inauthentic NS RRSet with no RRSIGs it cannot be identified as 
inauthentic, but it doesn't really matter because any data that is expected to 
be signed from the inauthentic servers will fail validation and the application 
will be protected.

The problems that dprive is trying to solve concern surveillance opportunities 
and information leakage. that if an imtermediate referral response includes an 
inauthentic NS RRSet with no RRSIGs it could cause queries on behalf of an 
application to be harvested by an untrusted third party at one of those 
inauthentic servers, which could represent a surveillance opportunity.

The proposal is hence to provide a way for an intermediate referral response 
that includes an inauthentic NS RRSet to be identified as inauthentic so that 
subsequent queries to the untrusted third party servers can be suppressed.

Did I read that back correctly?

I've now typed "inauthentic" enough that I am starting to doubt that it is a 
word, but "bogus" has a particular and different meaning in DNSSEC so I was 
trying to avoid it.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

[Joe Abley]

On Dec 10, 2020, at 19:25, Paul Hoffman  wrote:

> In DPRIVE, there is a desire to TLSA records to authenticate authoritative 
> servers. In order to do that without getting into a chicken-and-egg loop, the 
> parent needs to authenticate the NS records of the child authoritative server.

I haven't been following dprive recently. Is there a particular document that 
expresses the problem statement above in more detail?

"Authenticate authoritative servers" is a bit vague for me. Parent and child 
are namespace concepts and not relying parties that you'd ordinarily expect to 
be able to authenticate anything.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

[Joe Abley]

On Dec 10, 2020, at 19:14, Mark Andrews  wrote:

> Before going on I would really like to know what operational problem is being
> attempted to be solved by signing delegating information?

+1
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Tell me about tree walks

[Joe Abley]

On 11 Nov 2020, at 17:08, Paul Vixie  wrote:

> if you guys are going to automate and secure the public suffix list
> functionality, please spare a thought for automated / at-scale ("not
> in whois") identification of the domain's registrar and registrant.

I understand the reason why being able to identify the registrar for a 
particular domain is useful (or "necessary" depending on your perspective). I 
don't understand the overlap between this problem and the problem that John is 
trying to solve, though. Could you explain?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hey,

On 3 Nov 2020, at 10:49, Joe Abley  wrote:

>>> Well, 200+ TLD's are now removing this problematic orphan glue due to
>>> security reasons unrelated to this draft.
> 
> I have not done a survey of other TLD zones, but perhaps if I have a few 
> spare minutes I'll take CZDS for a spin and see what I can see there.

I don't have access to all zone data in CZDS since some registries take longer 
to approve access than others. It's perhaps also worth mentioning that CZDS 
doesn't carry any ccTLD zone data. This is not a representative sample.

From a quick look (with very little checking, and more than a little crude 
scripty hackery) it looks to me like 217 TLDs have at least one orphan glue 
record and 872 have none, based on this incomplete sample.

jabley@manta bin % jq '.zones | map_values(select(.orphans > 0)) | keys | 
length' zonedata.json
217
jabley@manta bin % jq '.zones | map_values(select(.orphans == 0)) | keys | 
length' zonedata.json
872
jabley@manta bin % 

See attached, if you feel like slicing the data some other way (or checking it).


Joe



zonedata.json
Description: application/json
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Paul,

On 3 Nov 2020, at 09:59, Paul Wouters  wrote:

> You never replied to this. I would really appreciate an answer so that
> the Working Group knows whether or not your objection is still relevant,
> based on the below developments of the Registry that is running the
> TLD for which you were speaking.

Sorry about that, wasn't intentional. See below.

> On Tue, 11 Aug 2020, Paul Wouters wrote:
> 
>> So this statement aged badly with today's announcement from Afilias:
>> 
>> http://www.circleid.com/posts/20200811-afilias-to-protect-tlds-against-potential-orphan-glue-exploits/
>> 
>>   Afilias has informed registrars and registry clients that it is
>>   taking steps to remove orphan glue records from 200+ TLD zones
>>   in its care. This will eliminate the potential for a handful of
>>   domain names to be misused.
>> 
>>  Afilias identified a handful of domain names among the 20 million names

I am familiar with the contents of that blog post and the circumstances 
surrounding it. My position on the usefulness of this draft has not changed. 
See below for more detail.

PIR and Afilias identified a software defect that in certain cases allowed glue 
records to remain in the zone even though they had been removed from the 
registry. Since the ORG zone is relatively large and since the defect had 
existed for a long time, the number of lingering orphan glue records was 
significant, even though the circumstances by which they showed up were 
relatively rare.

The software defect was eliminated and the glue records associated with the 
defect were removed.

However, even a cursory look at the ORG zone today, long after these records 
were removed, reveals that there are many orphan glue records (in the DNS 
sense, not in the registry sense) that remain. An example of the circumstances 
that lead to these remaining glue records being present in the zone is the case 
where a domain is suspended for abuse according to our published procedures; in 
those circumstances the delegation is removed from the zone but any subordinate 
glue records that might exist will remain.

On 2020-09-22 there were 7207 such orphan glue records in the ORG zone.

On 2020-11-03 (today, zone serial 2014131123) there are 8155 such orphan glue 
records in the ORG zone.

>> Well, 200+ TLD's are now removing this problematic orphan glue due to
>> security reasons unrelated to this draft.

I have not done a survey of other TLD zones, but perhaps if I have a few spare 
minutes I'll take CZDS for a spin and see what I can see there.

>> So my question to Joe is, did you have any other concerns with allowing
>> this draft to move forward?

ORG is not a delegation-only zone today, and we do not expect it ever to be a 
delegation-only zone. Correspondingly, this is not a mechanism we would use in 
ORG.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use

[Joe Abley]

On 2 Nov 2020, at 12:56, Joe Abley  wrote:

> On 2 Nov 2020, at 12:19, Paul Wouters  wrote:
> 
>> On Mon, 2 Nov 2020, Roy Arends wrote:
>> 
>>> As for version -01, the authors propose to separate the document into two:
>>> 
>>> (1) A document that discusses the motivation for private space top level 
>>> domains, provides recommendations for people setting them up, etc.
>> 
>> The IETF / DNSOP should not recommend setting up private space TLDs by
>> instructing people how to do this.
> 
> We anticipated that there would be differences of opinion around this set of 
> topics that might be difficult to resolve. This is the motivation of 
> splitting the issues into different documents, really.

And to make this more clear, while the authors are proposing that the issues be 
split into multiple documents, that doesn't mean we've already decided to do 
so. This is a working group document and we will take direction from the 
working group about how to proceed.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use

[Joe Abley]

Hi Paul,

On 2 Nov 2020, at 12:19, Paul Wouters  wrote:

> On Mon, 2 Nov 2020, Roy Arends wrote:
> 
>> As for version -01, the authors propose to separate the document into two:
>> 
>> (1) A document that discusses the motivation for private space top level 
>> domains, provides recommendations for people setting them up, etc.
> 
> The IETF / DNSOP should not recommend setting up private space TLDs by
> instructing people how to do this.

We anticipated that there would be differences of opinion around this set of 
topics that might be difficult to resolve. This is the motivation of splitting 
the issues into different documents, really.

>> (2) A document to note that ISO policy supports using ISO3166 User Assigned 
>> code elements to anchor private namespaces, recognise that use and, finally, 
>> recommend against use of these code elements for any other purposes that 
>> cause operational or security problems (e.g. due to collisions with 
>> delegations in the root zone).
> 
> I still don't see the value in this, but there is also no harm done
> describing this. So I am ambivalent on this.

It seemed to us that the needle of consensus might be more consistently in that 
kind of green arc for this topic, too.

> In general, I'm mostly afraid that this/these document(s) will eat up a
> lot of DNSOP resources/time, seeing more Special Domain discussions and
> all, while naming things is really outside of IETF/DNSOPS area.

I am confident that our chairs are listening and are aware of the lack of 
jurisdictional clarity on this point.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] zone contents digest and DNSSEC stuff

[Joe Abley]

Hi Libor,

On Sep 29, 2020, at 05:51, libor.peltan  wrote:

> Often the zone operators work with both un-signed and signed "versions" of 
> their zone. The un-signed version usually comes from a registry system or a 
> database, whereas a "signer" server adds "the DNSSEC stuff", like DNSKEYs, 
> RRSIGs, NSECs, etc. It's also usually possible to do the reverse: strip 
> DNSSEC-related records from signed zone, if needed.
> 
> I feel like it would be equally useful to maintain a digest of the un-signed 
> and signed version of the zone, respectively.

Others may have different ideas about this, but to me it makes the most sense 
for a particular zone that contains a ZONEMD RRSet to use it to carry a 
checksum of itself, not some other zone. 

The unsigned zone, as you have described it, is a different zone from the 
signed zone; it contains different resource records. It could contain its own 
ZONEMD RRSet, but that would reflect its own checksum. Since it's unsigned, its 
ZONEMD would also have no authenticity protection, but there could be internal, 
trusted environments where that was not a concern and the unsigned ZONEMD could 
still be useful.

For example, you could still compute a ZONEMD for an unsigned zone in order to 
use it to check that the zone was intact within the internal registry/signer 
machinery. You would replace it with a newly-computed ZONEMD once the zone had 
changed through the process of signing (the new ZONEMD reflects those changes).

The other use case I seem to think you're implying is that a consumer of the 
signed zone could verify that it was intact using the signed-zone ZONEMD, then 
strip the DNSSEC RRs and retain the ability to verify that the result was an 
accurate representation of the unsigned zone using the unsigned-zone ZONEMD. 
This seems like a slightly odd thing to want to do, but perhaps I'm just not 
thinking hard enough?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Authoritative servers announcing capabilities

[Joe Abley]

On Sep 12, 2020, at 02:47, Paul Vixie  wrote:

> On Sat, Sep 12, 2020 at 09:40:11AM +1000, Mark Andrews wrote:
>> and why is it a RR type at all.  An EDNS option or a opcode is better suited
>> for this sort of thing.
> 
> +1.

Plus lots. See below for TL;DR.

Operational reality is that there are often a different set of nameservers 
authoritative for the zone than are anticipated by whomever is responsible for 
the zone contents. Examples are mismatches between NS RRSets above and below 
the zone cut, and people opportunistically serving zones from from their own 
authoritative servers for their own local reasons (e.g. RFC 8806).

It's not reasonable to assume that all authoritative servers for any particular 
zone have the same server characteristics. Almost by definition, different 
servers live in different places with different local conditions in all layers 
up to and beyond 9, operated by different people with no existing requirement 
to centralise operational changes with the people responsible for zone data. To 
address the example given in the draft, it's ok some authoritative servers for 
a zone support ECS and others do not; some will give ECS-specific answers and 
some will not. Clients will still get answers. More generally, if the goal is a 
general mechanism that might be used to describe as-yet-unknown characteristics 
about a server, it ought to allow individual servers to be described.

It's not reasonable to assume that an individual hostname as exposed in a 
single NS RR corresponds to a single server. Authoritative servers are 
routinely provisioned as clusters or anycast clouds, and the details of what 
individual server might look like can change between successive queries.

It's always possible to imagine a very simple set of authoritative servers for 
a particular zone which would not run into these kinds of problems. However, 
such a mechanism would fail in exciting ways for pretty much any zone you can 
imagine that sees any real traffic. High-traffic zones with twitchy end-users 
are not usually provisioned in onto static, simple sets of authoritative 
servers.

If there is to be a general mechanism that describes the characteristic of an 
individual authoritative server, it ought to be one that embeds information in 
a specific response in such a way that it will never normally be cached.

Whether there is a convincing use-case for such a mechanism is a separate 
question. The example given in the draft does not seem very convincing, simply 
because there is an existing mechanism to achieve the same thing (see RFC 7871 
section 7.2.1).


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 30 Jul 2020, at 17:10, Paul Wouters  wrote:

> On Thu, 30 Jul 2020, Joe Abley wrote:
> 
>> 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.
> 
> 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.

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

> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 30 Jul 2020, at 16:36, Paul Wouters  wrote:

> 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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 30 Jul 2020, at 16:36, Paul Wouters  wrote:

> On Thu, 30 Jul 2020, Joe Abley wrote:
> 
>>> 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.
>> 
>> 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.
> 
> 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/ records 
suddenly stopped resolving.

>>> 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?
>> 
>> 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.
> 
> 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.

> Although please clarify what you do if there are DS records for
> 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/>.

>> 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.
>> 
>>> 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?
>> 
>> 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?

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.

> 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?

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___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Paul,

On 30 Jul 2020, at 16:28, Paul Wouters  wrote:

> On Thu, 30 Jul 2020, Ben Schwartz wrote:
> 
>>  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.
>> 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  TLSAblob   + RRSIG(key of .ca)
>   www.nohats.ca   IN  A + RRSIG(key of 
> .ca)
>   nohats.ca   IN  MX 0tapbox.ca.  + RRSIG(key of .ca)
> 
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Paul,

On 30 Jul 2020, at 15:43, Paul Wouters  wrote:

> You are mixing up the generic policy of delegation only with the exact
> 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
> delegation-only domain. Now let's examine the corner case you have
> and see if/what we can do.

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.

> 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".

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

> 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?

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.

> 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?

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Paul,

On 30 Jul 2020, at 13:20, Paul Wouters  wrote:

> On Thu, 30 Jul 2020, Petr Špaček wrote:
> 
>> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question regarding RFC 8499

[Joe Abley]

Hi Evan,

On 23 Jul 2020, at 14:34, Evan Hunt  wrote:

> On Thu, Jul 23, 2020 at 01:38:58PM -0400, Joe Abley wrote:
>> I don't think primary/secondary are exact substitutes for master/slave in
>> the way that those four terms are commonly used today.
> [...]
>> If we are looking for alternative terminology to master/slave (which I am
>> not against, because change is a constant and inclusiveness and awareness
>> amongst all industries is surely to be supported and encouraged) in my
>> opinion we should find new words and not redefine or overload the common
>> meaning of primary and secondary.
> 
> I share the desire for perfection, but IMHO the transition from "master"
> to "primary" and "slave" to "secondary" is far enough under way and well
> enough understood at this point that I suspect it would be easier to add
> modifiers when necessary than to try to deploy new vocabulary entirely.

Oh, that's something I wasn't aware of. Do you have any examples of people 
moving from master/slave to primary/secondary?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question regarding RFC 8499

[Joe Abley]

On 23 Jul 2020, at 13:44, Tim Wicinski  wrote:

> On Thu, Jul 23, 2020 at 1:39 PM Joe Abley  <mailto:jab...@hopcount.ca>> wrote:
> 
> If we are looking for alternative terminology to master/slave (which I am not 
> against, because change is a constant and inclusiveness and awareness amongst 
> all industries is surely to be supported and encouraged) in my opinion we 
> should find new words and not redefine or overload the common meaning of 
> primary and secondary.
> 
> 
> Actually, that does make sense. Though we also have to expect that these 
> existing terminology will not be replaced in the lexicon overnight.
> 
> The Chairs plan on having a few slides on this whole topic, as we've been 
> thinking about it for some time. 

Allow me to preempt the inevitable infinite descent into the infinite rabbit 
bikeshed of naming and suggest upstream and downstream for master and slave. I 
feel like the DNS needs more fish analogies, even as I appreciate that we need 
to turn a blind eye to the shenanigans of frisky salmon as we firmly imagine 
data flowing only from the former to the latter.


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop