Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
Hi Wes, I’m having a hard time understanding the two proposed deployments in this document. In 2.2.1 it states that .internal does not exist in the GID. Yet in the Summary section immediately after it states that .internal is an unsigned TLD. Which is it? In 2.2.2 it states that .zz is an unsigned delegation in the GID’s DNS root. Yet in the summary section it states that “.zz is a special-use-like TLD that MUST never be assigned”. Which is it? My understanding of an unsigned TLD is that it is delegated in the root zone unsigned. And I take it that GID is simply a synonym for what many call The Public DNS. Thanks, Andrew On 2 Nov 2020, at 23:50, Wes Hardaker wrote: I've been thinking for a while what approach to take with respect to private name spaces. This document summarizes some of my thinking, and draws some conclusions (that will likely poke some bears and beehives at the same time). -- A new version of I-D, draft-hardaker-dnsop-private-namespace-options-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Name: draft-hardaker-dnsop-private-namespace-options Revision: 00 Title: DNS Private Namespace Options Document date: 2020-11-02 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-hardaker-dnsop-private-namespace-options-00.txt Status: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-private-namespace-options/ Htmlized: https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-private-namespace-options Htmlized: https://tools.ietf.org/html/draft-hardaker-dnsop-private-namespace-options-00 Abstract: This document discusses the trade-offs between various options about creating a private namespace within top level domains within the root zone. 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 -- Wes Hardaker USC/ISI ___ 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] Going forward on draft-ietf-dnsop-private-use
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] Questions on draft-ietf-dnsop-delegation-only
Joe, 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. As this seems to be the only outstanding technical issue with the draft, it would be nice to get this answered. The remaining question then becomes if the draft is worth it to enable the feature for those who see value in it. Regards, Paul On Tue, 11 Aug 2020, Paul Wouters wrote: On Thu, 30 Jul 2020, Joe Abley 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. 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. 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 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. Well, 200+ TLD's are now removing this problematic orphan glue due to security reasons unrelated to this draft. So my question to Joe is, did you have any other concerns with allowing this draft to move forward? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-iana-class-type-yang
Dear WG, The WGLC period for draft-ietf-dnsop-iana-class-type-yang has finished. From the comments on the mailing list of DNSOP participants who contributed and/or provided feedback on the document, I conclude that the authors have included and processed their comments. The chairs feel that the draft is ready to move forward. Thanks for the reviews, — Benno On 16/10/2020 15:49, Paul Wouters wrote: On Fri, 16 Oct 2020, Ladislav Lhotka wrote: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ This looks good to me. One minor item. Is it possible to add text in a way that instructs implementer they SHOULD NOT add "Obsolete" entries when populating? I think we need to assume that an implementer is familiar with the YANG spec, and this is just one of the rules to follow. Specifically, RFC 7950 says: o "obsolete" means that the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations. This should IMO be sufficient and we needn't repeat in in this document. Ah yes. And 7950 is referenced in the introduction, so I guess that should be enough. Thanks, Paul ___ 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] Questions on draft-ietf-dnsop-delegation-only
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] Questions on draft-ietf-dnsop-delegation-only
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] draft-ietf-dnsop-delegation-only is still not useful
In article <1a141a5b-fd68-4991-bd90-dfe7efaed...@hopcount.ca> you write: >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. Hi. I'm not Joe but I have a CZDS account. As I said back in August, while there are lots of zones that are delegation-mostly, that is not the same as being delegation-only. It is simply true that most TLDs are delegation-only, and this hack is not useful. I grepped through the downloaded contracted zone files for signed A and records and found over 32,000 of them in over 200 TLDs. The list of TLDs and counts are below, or you can find the whole set at https://www.iecc.com/signedglue.txt There are also _nicname._tcp SRV records in TLDs including .am .at. ax. be. bg. biz. ch. cl. co. de. dk. fo. fr. gg. hu. ie. is. and at least a dozen others. Beyond that, there are 17,000 signed MX records in the .name zone and probably other oddities if I looked further. R's, John 1 abogado.txt 1 aeg.txt 1 afamilycompany.txt 1 amazon.txt 1 aol.txt 2 arab.txt 182 asia.txt 1 audible.txt 1 author.txt 1 aws.txt 1 barefoot.txt 1 bayern.txt 1 bbc.txt 5 bbt.txt 1 beer.txt 1 bentley.txt 4 bet.txt 2 biz.txt 6 black.txt 60 blue.txt 1 bms.txt 1 book.txt 1 boston.txt 1 bot.txt 1 bradesco.txt 1 broadway.txt 8 broker.txt 2 brussels.txt 1 budapest.txt 1 buy.txt 1 call.txt 8 career.txt 1 casa.txt 17 cat.txt 8 chanel.txt 1 circle.txt 8 clubmed.txt 1 comcast.txt 1 cooking.txt 8 cookingchannel.txt 2 cpa.txt 8 crown.txt 8 crs.txt 8 csc.txt 1 cymru.txt 1 dds.txt 1 deal.txt 8 diy.txt 8 duck.txt 4 eco.txt 8 ericsson.txt 1 fashion.txt 1 fast.txt 8 fidelity.txt 1 fire.txt 1 fishing.txt 1 fit.txt 8 food.txt 8 foodnetwork.txt 8 forex.txt 1 free.txt 8 frontdoor.txt 8 fujixerox.txt 8 gallo.txt 1 garden.txt 8 genting.txt 8 glade.txt 28 global.txt 1 gop.txt 1 got.txt 2 green.txt 8 guardian.txt 8 hgtv.txt 1 horse.txt 1 hot.txt 8 hotmail.txt 8 ice.txt 1 imdb.txt 20338 info.txt 2 ist.txt 8 istanbul.txt 8 jaguar.txt 8 java.txt 1 jot.txt 1 joy.txt 8 juniper.txt 8 kerryhotels.txt 8 kerrylogistics.txt 8 kerryproperties.txt 33 kim.txt 1 kindle.txt 8 kuokgroup.txt 8 landrover.txt 1 law.txt 8 lefrak.txt 8 lego.txt 1 like.txt 8 linde.txt 6 link.txt 8 lipsy.txt 7 llc.txt 2 llp.txt 1 locus.txt 1 london.txt 8 lundbeck.txt 8 lupin.txt 1 luxe.txt 8 maif.txt 8 markets.txt 8 med.txt 1 miami.txt 8 microsoft.txt 303 mobi.txt 1 moi.txt 2 moscow.txt 8 nab.txt 8 nationwide.txt 8 next.txt 8 nextdirect.txt 8 nikon.txt 8 nissay.txt 8 norton.txt 1 now.txt 8 obi.txt 8 off.txt 8 omega.txt 3 onl.txt 8 onyourside.txt 8 oracle.txt 8 orange.txt 8171 org.txt 1 organic.txt 2 paris.txt 1 pay.txt 2 pet.txt 8 pictet.txt 1 pin.txt 14 pink.txt 4 poker.txt 4 politie.txt 1 prime.txt 1246 pro.txt 4 promo.txt 8 raid.txt 1 read.txt 8 realestate.txt 8 realtor.txt 38 red.txt 8 rexroth.txt 1 rodeo.txt 1 room.txt 8 rwe.txt 1 safe.txt 8 sanofi.txt 1 save.txt 8 sbs.txt 8 sca.txt 3 scb.txt 8 scjohnson.txt 1 secure.txt 8 sener.txt 8 ses.txt 8 shangrila.txt 8 shell.txt 1 shiksha.txt 1 silk.txt 8 sky.txt 1 smile.txt 1 spot.txt 4 srl.txt 1 surf.txt 8 swatch.txt 1 talk.txt 8 tatamotors.txt 141 tel.txt 8 tiaa.txt 8 tiffany.txt 783 top.txt 8 trading.txt 12 travel.txt 8 travelchannel.txt 1 tunes.txt 1 tushu.txt 8 ubank.txt 8 ubs.txt 8 vanguard.txt 1 vip.txt 1 virgin.txt 8 visa.txt 2 vlaanderen.txt 1 vodka.txt 8 volvo.txt 12 vote.txt 1 wales.txt 1 wanggou.txt 8 weber.txt 1 wedding.txt 8 weir.txt 8 windows.txt 1 work.txt 1 wow.txt 8 xbox.txt 8 xerox.txt 1 xfinity.txt 18 xin.txt 2 xn--30rr7y.txt 8 xn--5su34j936bgsg.txt 1 xn--6frz82g.txt 8 xn--9dbq2a.txt 3 xn--9et52u.txt 1 xn--c1avg.txt 1 xn--cckwcxetd.txt 2 xn--efvy88h.txt 1 xn--i1b6b1a6a2e.txt 1 xn--jlq480n2rg.txt 60 xn--kput3i.txt 8 xn--mk1bu44c.txt 2 xn--mxtq1m.txt 2 xn--ngbrx.txt 1 xn--nqv7f.txt 8 xn--t60b56a.txt 8 xn--tckwe.txt 8 xn--w4r85el8fhu5dnra.txt 8 xn--w4rs40l.txt 1 yamaxun.txt 1 yoga.txt 1 you.txt 1 zappos.txt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
"Andrew McConachie" writes: > I’m having a hard time understanding the two proposed deployments in > this document. It's not as clean as I'd like, certainly. I was pushing up against the draft submission deadlines and didn't get all the wording into place. > In 2.2.1 it states that .internal does not exist in the GID. Yet in > the Summary section immediately after it states that .internal is an > unsigned TLD. Which is it? .internal is an unsigned TLD and is the GID. I don't see where in 2.2.1 it says that though. > In 2.2.2 it states that .zz is an unsigned delegation in the GID’s DNS > root. Yet in the summary section it states that “.zz is a > special-use-like TLD that MUST never be assigned”. Which is it? The later. .zz is not delegated. Again I'm not sure which sentence you're referring to though. [someone did note that one of my section names is incorrect as well and referred to the wrong one] > My understanding of an unsigned TLD is that it is delegated in the > root zone unsigned. And I take it that GID is simply a synonym for > what many call The Public DNS. Yep. It's "Global Internet's DNS (GID)", per the document. There are, unfortunately, more than one naming environments. We've known this for years with even /etc/hosts being different from the DNS, and NIS coming along later, etc. Nowdays, there are so many split-systems with both internal and externally differing naming sets I was trying to use something that included the world "global" to be super-clear this is the "big one". -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] draft-hardaker-dnsop-private-namespace-options
On Nov 3, 2020, at 5:11 PM, Wes Hardaker wrote: >> My understanding of an unsigned TLD is that it is delegated in the >> root zone unsigned. And I take it that GID is simply a synonym for >> what many call The Public DNS. > > Yep. It's "Global Internet's DNS (GID)", per the document. > > There are, unfortunately, more than one naming environments. We've > known this for years with even /etc/hosts being different from the DNS, > and NIS coming along later, etc. Nowdays, there are so many > split-systems with both internal and externally differing naming sets I > was trying to use something that included the world "global" to be > super-clear this is the "big one". There is "global DNS" from RFC 8499. Or is your GID supposed to be something different? --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-delegation-information-signer
I submitted draft-fujiwara-dnsop-delegation-information-signer-00. Name: draft-fujiwara-dnsop-delegation-information-signer Revision: 00 Title: Delegation Information (Referrals) Signer for DNSSEC Document date: 2020-11-03 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt DNSSEC does not have a function to validate delegation information. I think it is a large missing peace of DNSSEC. I have a question why we did not include signature validation function to delegation information ? Probably, because it is non-authoritative information. Or, because it was difficult to define the necessary and sufficient delegation information. It is now widely agreed (although not explicitly documented) that the delegation information is the information used for name resolution and does not result in name resolution. We have a word "in-domain" glue which is the necessary and sufficient glue. And the idea may offer the signature for root priming data. If someone interested the document, I would like time slot at dnsop WG meeting. Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] draft-hardaker-dnsop-private-namespace-options
Paul Hoffman writes: > There is "global DNS" from RFC 8499. Or is your GID supposed to be something > different? Same thing. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
