Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
> Em 6 de mai. de 2023, à(s) 12:20, John Levine escreveu: > > It appears that Joe Abley said: >> Pre-delegation checks add friction to the domain registration process. They >> further complicate the commuications between different actors in the >> commercial graph >> (registrars, registries, resellers, DNS operators, hosting companies) and >> introduce delay and manual intervention into what might otherwise be a >> fairly automated >> or at least automatable process. ... > > Thirty years ago, when you did domain registrations by e-mail, the > registry which was then called Network Solutions did indeed check that > your name servers were active before delegating the domain. It was not > an accident that they stopped doing so, and it seems vanishingly > unlikely that any gTLD registry would do so now, regardless of > what people here might think. Actually, there is one gTLD that does that: .rio. A domain can be registered without working DNS servers, but it won’t be delegated until DNS servers answer with authority for that domain. .rio also checks DNS authority when a domain updates its delegation set, and promptly denies the update if not (different from the create where there is a continuous check waiting for authority to appear). But this is likely due to .rio getting infrastructure from a ccTLD operator that happens to do similar checks… although in .br lack of DNS authority prevents registration, different from .rio. It’s not that pre-delegation checks add friction per se; it does if TLDs A, B, C do not perform them and TLDs X, Y and Z perform such checks. This makes other parties in network the graph (regardless of them being commercial, education, non-profit etc.) expect one behavior or the other, and fail in some regard when the practice of a TLD is different. But I will add one other party to the network graph that benefits from pre-delegation checks: Internet connectivity providers. Lame delegation makes DNS recursive servers to spend more resources to get no usable response, transferring load from registries/DNS operators/hosting companies to them. So, it would be really interesting if a standards-track document defines which behavior to follow so everyone can sing the same song. I just don’t see that happening. Rubens ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
> On 12 May 2023, at 12:09, John R Levine wrote: > >>> Yeah, that's a better way to put it. But the main point still stands, >>> that it would be a signficant operational change to insist that all >>> delegated NS be active when delegated, and even moreso to insist that >>> they continue to be active. >> >> No, it is not a “significant” change. It should just be a minor extension >> of the existing requirement to keep the NS and glue records consistent. >> >> Even if it was you just introduce it with a soft start. Just start checking >> the delegations of every TLD like zone then report the broken servers >> publicly and email the contacts for the delegation. The tools for checking >> already exist. > > Well, OK, you do that, half the emails bounce, half of what's delivered is > reported as spam, and the third half are ignored. Now what? In practice it isn’t quite as bad as that. Require registrars to refuse renewals until the issues are addressed. This is no different to not getting your car’s registration renewed until it has past its safety inspection. Mark > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
Yeah, that's a better way to put it. But the main point still stands, that it would be a signficant operational change to insist that all delegated NS be active when delegated, and even moreso to insist that they continue to be active. No, it is not a “significant” change. It should just be a minor extension of the existing requirement to keep the NS and glue records consistent. Even if it was you just introduce it with a soft start. Just start checking the delegations of every TLD like zone then report the broken servers publicly and email the contacts for the delegation. The tools for checking already exist. Well, OK, you do that, half the emails bounce, half of what's delivered is reported as spam, and the third half are ignored. Now what? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
> On 12 May 2023, at 11:35, John Levine wrote: > > It appears that Mark Andrews said: >>> Oh, I completely agree. My point was just that even in the root which is >>> small and you >>> would hope would change slowly, it's still a challenge to track what's lame. >> >> It’s not a challenge to track what is lame. It’s dead simple. You just >> have to look. Getting >> it addressed is the challenge. > > Yeah, that's a better way to put it. But the main point still stands, > that it would be a signficant operational change to insist that all > delegated NS be active when delegated, and even moreso to insist that > they continue to be active. No, it is not a “significant” change. It should just be a minor extension of the existing requirement to keep the NS and glue records consistent. Even if it was you just introduce it with a soft start. Just start checking the delegations of every TLD like zone then report the broken servers publicly and email the contacts for the delegation. The tools for checking already exist. RFC 4034, 4.2.2. As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. > Back in the 1990s when you registered names by email, NetSol checked > that your NS were active before accepting them, but that was back when > it was normal for the back and forth for registering a name to take a > week. > > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
It appears that Mark Andrews said: >> Oh, I completely agree. My point was just that even in the root which is >> small and you >> would hope would change slowly, it's still a challenge to track what's lame. > >It’s not a challenge to track what is lame. It’s dead simple. You just have >to look. Getting >it addressed is the challenge. Yeah, that's a better way to put it. But the main point still stands, that it would be a signficant operational change to insist that all delegated NS be active when delegated, and even moreso to insist that they continue to be active. Back in the 1990s when you registered names by email, NetSol checked that your NS were active before accepting them, but that was back when it was normal for the back and forth for registering a name to take a week. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Comments on draft-ietf-dnsop-dnssec-validator-requirements-04
> Recommendations for DNSSEC Resolvers Operators >draft-ietf-dnsop-dnssec-validator-requirements-04 Before I dive into some paragraph-by-paragraph details, and bury the lede, my main high-level issue is with sections 9, primarily on substance, but also for IMHO notably stilted and fuzzy language. The most significant issue is that the I-D recommends at the bottom of section 9 to cap the TTLs of all dependent RRsets by the TTLs of the DS, KSK and ZSK records. > RUNTIME: > > * To limit the risks of incoherent data in the cache, it is > RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of > the DS, KSK and ZSK. RRsets TTL SHOULD NOT exceed the DS, KSK or > ZSK initial TTL value, that TTL SHOULD trigger delegation > revalidation as described in [I-D.ietf-dnsop-ns-revalidation]. > TTL SHOULD NOT exceed the signature validity. This is not necessary for correctly operated authoritative zones, that retain "inactive" ZSKs and KSKs in the DNSKEY RRset for a few TTLs after the keys become inactive, and likewise drop hashes of inactive KSKs from the DS RRset only after new KSKs have been published for a sufficient time. What we'd need instead of TTL capping is more akin to "revalidation" where under normal/expected conditions, cached RRsets continue to "enjoy" their natural TTL (as tweaked by any resolver limits). That TLL can for many RRsets be higher than e.g. the TTL of the parent zone DS RRset. With "revalidation", if a DS record refreshed after TTL expiration is (as is typically the case) identical to its previous value, or in any case continues to establish a chain of trust to the cached DNSKEY RRset, nothing needs to happen to the caching of the descendent records. Similarly, DNSKEY RRset refreshes that still include the ZSK originally used to validate a cached RRset need not have any affect on the validity of the signed data. The above DS and ZSK continuity conditions are expected standard practice from the signer. So long as these hold, validated records should be cached for their advertised TTLs as bounded by the signed origin TTLs and resolver cache time limits. Resolvers *MAY* take action to revalidate cached data should abrupt changes take place in the DS RRset (no longer building a trust path to the cached DNSKEYs) or abrupt changes in the DNSKEY RRset (no longer validating cached RRSIGs), but should not be expected to do so. As resolvers gain implementation experience with this revalidation generally, and DNSSEC trust chain revalidation specifically, and are seen to perform revalidation safely and scalably (without thundering herd query storms), and revalidation becomes a common implementation feature, perhaps then we might reconsider resolver cache expectations. We're not there yet, and in the meantime crude truncation of all TTLs to the smaller of the DNS/DNSKEY TTLs is IMHO not a good outcome. Moreover, this recommendation would be a barrier to shorter DS TTLs, which are necessary to reduce mean time to recovery, making enabling DNSSEC less daunting to risk averse authoritative zone operators. > Abstract > >This document clarifies the scope and responsibilities of DNSSEC >Resolver Operators (DRO) O.K. so far. > as well as operational recommendations that >DNSSEC validators operators SHOULD put in place in order to implement >sufficient trust that makes DNSSEC validation output accurate. There's a missing verb in this part of the sentence. "As well as ???" Also: s/DNSSEC validators/DNSSEC validator/ > 1. Introduction >The purpose of a DNSSEC Resolver Operator (DRO) is to provide DNSSEC >validation in to their users. Well, the purpose is to provide DNSSEC resolution. DNSSEC validation is a part of that, but isn't the whole. >By validating with DNSSEC a received Resource Record Set (RRset), the >resolver provides a high level of certainty that the information >carried by the RRset is effectively as published by the legitimate >owner of the RRset. s/certainty/assurance/ > The act of DNSSEC validation [RFC4033][RFC4035] >can be broken into two part: A _Signature Validation_ which binds the >RRset to a private key as well as _Trust_ in the owner of the private >being the legitimate owner. This is very clumsy. Suggested: The act of DNSSEC validation [RFC4033][RFC4035] can be broken into two parts: _Signature Validation_ which binds the RRset to a public key as well as establishing a _Trust Chain_ authenticating that public key as an authorised signer for containing zone. >Signature Validation consists in checking the cryptographic signature >of a RRset and involves among other parameters a DNSKEY Resource >Record (RR) and RRSIG RR and the RRset itself. The signature >validation process results in designating the owner
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
> On 9 May 2023, at 03:13, John Levine wrote: > > It appears that Kim Davies said: >> With that said, I think the root zone is probably not an instructive >> use case for the broader question. Unlike typical zones, at the root it >> can be said every delegation is to critical Internet infrastructure and >> therefore the calculus around process complexity and efficiency would be >> weighted differently. > > Oh, I completely agree. My point was just that even in the root which is > small and you > would hope would change slowly, it's still a challenge to track what's lame. It’s not a challenge to track what is lame. It’s dead simple. You just have to look. Getting it addressed is the challenge. https://ednscomp.isc.org/compliance/tld-fullreport.txt has been generated daily for the last 5 years and the broken behaviours have stood out like sore thumbs the entire time. It only takes a couple of minutes to generate that report and that isn’t trying to go as fast as possible. > R's, > John > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Dnsdir last call review of draft-ietf-dnsop-glue-is-not-optional-08
Reviewer: Nicolai Leymann Review result: Ready Hi, I was assigned as the dnsdir reviewer for ietf-dnsop-glue-is-not-optional. The document is on standards track and describes the DNS Glue requirements in Referral Responses. It updates RFC1034 (one of the core RFCs for DNS). The draft is well written and easy to understand. The document is ready for publication. Major issues: none Minor issues: none Nits: RFC1034 uses "in domain" (section 3.5) but the proposed change uses "in-domain". Regards Nic ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title : Compact Denial of Existence in DNSSEC Authors : Shumon Huque Christian Elmerot Olafur Gudmundsson Filename: draft-ietf-dnsop-compact-denial-of-existence-00.txt Pages : 8 Date: 2023-05-09 Abstract: This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimal NSEC record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-compact-denial-of-existence-00.html Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
