[DNSOP] Re: [Ext] Re: Is .INTERNAL a special use domain name?
Quoting Michael De Roover on Monday February 10, 2025: > > > So far it appears that the > decision to use the string "internal" specifically has reached reasonable > consensus, but I think I could use a confirmation on that. Do you think that > is > the case? If so, I would see no problem proceeding to make this change on the > next maintenance. Just that I uh.. don't want to have to do this twice. I can confirm IANA considers .internal to be reserved for private-use purposes. This Internet Draft is part of our efforts to memorialize the decision that has already been taken to do that. kim Kim Davies VP, IANA Services, ICANN President, PTI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Is .INTERNAL a special use domain name?
Hi folks, We have published a new version of the draft intended to document the .internal top-level domain. (https://datatracker.ietf.org/doc/draft-davies-internal-tld/) When we presented this work in Dublin, there was a lot of discussion both in the meeting, and subsequently, on whether this should be a work item and also whether the domain merited consideration as a special-use domain name per RFC 6761. I don’t think there was clear consensus on either, but to further the discussion on the latter point, Warren Kumari has provided strawman text to stimulate discussion. kim ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Re: New Version Notification for draft-nottingham-public-resolver-errors-00.txt
Quoting Stephane Bortzmeyer on Wednesday November 06, 2024: > > > The draft specifies it as FCFS, so IANA does not have a > > discretionary role. > > The draft says the opposite "IANA may refuse registrations that are > deemed to be deceptive or spurious." For what its worth, it is common practice for IANA to weed out requests for first-come first-served registries that lack a genuine intent to register the assoiated resource. Otherwise registries would be full of spam entries. kim ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [Ext] Re: Questions before adopting must-not-sha1
Quoting John Levine on Wednesday May 01, 2024: > > We all know the people at IANA who run .INT. If we can't persuade them > that this has becomes a problem that needs to be fixed, how urgent is > it likely to be? No persuasion necessary. There has been an ongoing project to update the signing approach for all zones maintained on ICANN infrastructure, which includes .INT. I asked the team and the implementation for .INT is planned to happen over the next month. kim ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
Quoting John Levine on Saturday May 06, 2023: > >The IANA Function Operator does so for all ccTLDs (which would imply all > >TLDs). > > Indeed, but some of them are lame anyway. Here's today's report: > ... > There are 96 more that timed out but I can't tell whether they really aren't > there or it's a temporary network issue. The IANA tests are only performed in the context of a change request being processed. The current approach was put in place where there was sensitivity against IANA monitoring TLDs. A third-party study was commissioned last year that interviewed TLD operators and recommended that approach evolve to proactive monitoring, so moving in that direction is now something we are planning for. 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. kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Deprecating infrastructure .INT domains
Quoting Masataka Ohta on Friday November 12, 2021:
>
> > 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'm afraid (1) should be documented by a separate rfc maybe titled
> as "Relationship between IETF and IANA", which should clarify
> semantics of "IANA considerations" section of not only this but
> also other rfcs, which was not a problem when both of the rfc
> editor and IANA was the same person.
>
> Is the "IANA considerations" section just a recommendation from
> IETF/ISOC to IANA/ICANN or approved by IANA/ICANN during *modified*
> standardization process of IETF?
These are fair points and hopefully the language can be tweaked to make
it a little clearer. (RFC 2860 does define the relationship between IETF
and IANA, but the role of .INT was modified as a consequence of RFC
3172)
Most of the names in the draft were in the zone when we started the
inventory process a couple of years ago. For those that were lame
for over a year we removed them from the zone because they were
already functionally inoperable. For the remaining two that are in
there, there doesn't appear to be any sign that they are currently
configured to operate as documented. Specifically, {1..9}.tpc.int and
{0..9,a..f}.nsap.int all return NXDOMAIN.
Even if we are perhaps duly empowered to make such an operational
decision regarding these delegations, producing this draft and gaining
additional consensus on these actions I think will produce a better
result given the original delegations eminated from IETF work.
kim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Deprecating infrastructure .INT domains
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
Re: [DNSOP] [Ext] Re: DNS privacy and AS 112: the case of home.arpa
Hi Mark, Quoting Mark Andrews on Tuesday December 12, 2017: > > HOME.ARPA. SOAA.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 > 1800 900 604800 86400 > HOME.ARPA.NS A.ROOT-SERVERS.NET. .. > HOME.ARPA. DNAME EMPTY.AS112.ARPA. It is unclear to me how this avoids having root servers process DNAME records. Given the process of consultation, coordination and testing support for DNAME records in the root servers (or relocating the .arpa authorities) is likely to take longer than is desirable to have home.arpa insecurely delegated, the delegation to AS112 was considered as the best short-term approach even if it is not without its own difficulties. kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME
Quoting Stephane Bortzmeyer on Friday November 10, 2017: > > > I'll note that from a technical/mechanical perspective, ICANN's and > > Verisign's root zone management systems already know how to deal > > with delegations. A DNAME in the root would require an unknown level > > of development by both parties. > > I've never read the source code of the root zone management system, > but it seems surprising that it could be a non-trivial level of > development. I assume this system is complicated because it is highly > sensitive, and because it needs to incorporate a lot of defenses > against both mistakes and attacks, but they should be more or less the > same for DNAME and NS/A/, no? ... > Wild guess (and I pay beers if I'm wrong): the technical work will > take much less time than the process one. I suspect that would be a distinction without a difference. Any process changes need to be mapped into technical changes to the systems, as the whole business process from beginning to end is processed in the systems. Allowing DNAME records in the root zone is adding a new concept into root zone management that hasn't been catered to before. Just one of the many things that would need to be looked at is how to transmit DNAME provisioning requests via EPP. I don't know if there is even an EPP mapping for this. We haven't studied what would be involved, but I feel confident in predicting the whole exercise would be non-trivial. kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt
Quoting Andrew Sullivan on Thursday April 30, 2015: | > | > "Country" is a loaded term. I don't have a better suggestion in mind but | > there are many instances where a ccTLD is a territory, etc. I don't mean | > to open a rathole, just point this out. | | If we changed this to say, "A TLD that is allocated using the UN | country list using the the two-letter code from the ISO 3166-1 alpha-2 | standard [ISO3166]," would that address your concern? The ISO 3166-1 standard itself refers to its scope as "countries", and the broader ISO 3166 standard for "countries and their subdivisions". ICANN tends to say "countries or territories". I'd suggest trying to avoid the politically-fraught issue if practical. Also note that not all ccTLDs are two-letter codes pulled from the standard. With the advent of IDN ccTLDs, the domain itself is not derived from the ISO 3166-1 standard, only whether a particular geographic entity has standing to have a ccTLD. My suggestion: "A TLD that is allocated for use based on an entry in the ISO 3166-1 standard [ISO 3166-1]". If an allusion to the purpose is useful, then: "A TLD that is allocated for use based on an entry in the ISO 3166-1 standard [ISO 3166-1]. The ISO 3166 standard provides codings of countries and their subdivisions." kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] respsize draft
On 30/03/2011, at 7:10 AM, Paul Vixie , Akira Kato wrote: > The authors would like to make the draft either of > - Move it to publish as Informational RFC (after another WGLC?) > - Withdraw the document > > However, the authors are happy to continue to improve the document > provided if the community requests us specific sugesstions. I find the document very useful, and support it being published as an Informational RFC. kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DLVs and ITAR
Hi Joao, On 14/09/09 9:53 AM, "joao damas" wrote: > could the ITAR have a serial number that could be checked without > having to download and parse the whole file, to enable quick checks > from consumers of the ITAR information that would not overwhelm either > end of the communication? There is a serial number which can be checked, and I guess we could publish it independently, however you can use the inherent HTTP mechanism (If-Modified-Since header) to check for updates and not get the actual file if it hasn't updated. e.g. The '-N' flag with wget. > PS: or even, could it be published as a DNS zone of some name, with a > TLL and an SOA? Perhaps, although I am hoping a signed root zone is not too far off... kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DLVs and ITAR
Hi Mark, On 11/09/09 4:47 PM, "Mark Andrews" wrote: > > Publish new DNSKEY, publish new DS, wait at least the max TTL of > the old DS/DNSSKEY TTLs. Remove old DS, remove old DNSKEY. > > The same thing should be happening with ITAR. Publish new DNSKEY, > publish new DS, wait the prescribed period for the trust achors to > be updated, remove old DS, remove old DNSKEY. > > At the moment no one knows how long to wait as you havn't told > anyone what that period should be. Are you suggesting ITAR needs to add TTLs, or ITAR should be somehow technically enforce sufficiently long overlap periods, or should just provide rules that TLD operators are expected to abide by? The assumption right now is it is for the TLD operators to act responsibly and make changes as appropriate. ITAR is just an oblivious republisher of data that they have submitted, and has subsequently verified is genuine. It seems to me the problems you describe are ones of encouraging best practice amongst TLD operators, rather than a specific defect in ITAR. Kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DLVs and ITAR
On 11/09/09 4:21 PM, "Kim Davies" wrote: > > Right now, since the initial activity populating the repository, there are > only a couple of ITAR change events per month, but we have no pattern as to > when they can occur. Actually, I can be more specific: 2009-01-20 sign_zones generating new registry view (serial 2 -> 3) 2009-01-22 sign_zones generating new registry view (serial 3 -> 4) 2009-01-29 sign_zones generating new registry view (serial 4 -> 5) 2009-02-01 sign_zones generating new registry view (serial 5 -> 6) 2009-02-12 sign_zones generating new registry view (serial 6 -> 7) 2009-02-17 sign_zones generating new registry view (serial 7 -> 8) 2009-02-21 sign_zones generating new registry view (serial 8 -> 9) 2009-02-23 sign_zones generating new registry view (serial 9 -> 10) 2009-03-12 sign_zones generating new registry view (serial 10 -> 11) 2009-04-01 sign_zones generating new registry view (serial 11 -> 12) 2009-04-06 sign_zones generating new registry view (serial 12 -> 13) 2009-04-06 sign_zones generating new registry view (serial 13 -> 14) 2009-04-14 sign_zones generating new registry view (serial 14 -> 15) 2009-04-17 sign_zones generating new registry view (serial 15 -> 16) 2009-06-24 sign_zones generating new registry view (serial 16 -> 17) 2009-07-15 sign_zones generating new registry view (serial 17 -> 18) 2009-08-22 sign_zones generating new registry view (serial 18 -> 19) 2009-09-01 sign_zones generating new registry view (serial 19 -> 20) 2009-09-02 sign_zones generating new registry view (serial 20 -> 21) 2009-09-03 sign_zones generating new registry view (serial 21 -> 22) Kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DLVs and ITAR
Hi Mark, On 11/09/09 4:01 PM, "Mark Andrews" wrote: > > IANA still has not provided timing guidance. > > IANA can you please specifiy a maximum polling interval on this > page and inform the TLD's using ITAR of what it is. A minimum > polling interval would also be useful but is not crucial. I can't provide good guidance, because the ITAR is "live". If we get a valid add request then it goes in, if we have a valid remove request it comes out. We could get three different changes in the span of an hour, or we could get no requests in the span of a whole month. Revisions to the registry are not batched into scheduled intervals, like, say, the root zone. Maybe they should be? Right now, since the initial activity populating the repository, there are only a couple of ITAR change events per month, but we have no pattern as to when they can occur. kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...
On 8/09/09 6:07 PM, "Mark Andrews" wrote: >> >> As for when the current .PR key was listed on the interim trust anchor >> repository at IANA, 2009-09-01 21:45:06.072 UTC would be the precise time. > > So ITAR consumers had 2 days to respond to this key rollover event. > Did PR inform you immediately the DNSKEY was added to the PR zone? > What happened in the 14 days between the DNSKEY being added to the > zone and it appearing in ITAR? The ITAR listing process is essentially automatic, but relies on the TLD operator actually submitting a request to list via a web form. It is up to the TLD operator to submit trust anchors to us when they are ready. The only check we do is we will not list a trust anchor until there is a matching DNSKEY in their zone. We have no unique insight into the key management policies of the TLD operators. We do not monitor TLD zones for DNSKEYs that are not in the ITAR and give them courtesy notes that they are absent (maybe we should?). I think the questions on rollover planning are best left for each TLD to provide, it is not something we have any restrictions on. kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...
On 8/09/09 11:52 AM, "Chris Thompson" wrote: > > ISC supposedly get their data for TLDs from the IANA ITAR. That's certainly > up to date now at https://itar.iana.org/anchors/anchors.xml but it would be > more than interesting to know how long that has been the case. (As I recall, > PR had to be chivvied into joining the ITAR in the first place.) > > Given that the ITAR *is* now up to date, can anyone from ISC comment? > (I had expected to find it already fixed after coming back from the pub, > but no...) I do not intend to speak for anyone at ISC, but I believe they stated on this list previously they sync with the ITAR data on a weekly basis. As for when the current .PR key was listed on the interim trust anchor repository at IANA, 2009-09-01 21:45:06.072 UTC would be the precise time. Kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On 9/06/08 11:56 AM, "David Conrad" <[EMAIL PROTECTED]> wrote: > > On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote: >>> I'm curious: have you consulted with the various TLD-related >>> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD, >>> etc.) on >>> how to solve this problem? >> >> No. What do you think they'd say that hasn't been said in this thread >> already? > > You're talking about essentially creating a registry of their registry > policies and distributing it statically via your product. I would > imagine they might be interested and might even have some useful input > to provide. Some might even think it rude (even Microsoftian :-)) not > to ask. But perhaps I've been at layer 9 too long. This thread sounds remarkably like deja vu. Indeed, the TLD community was rather upset a few years ago by Mozilla taking unilateral action to introduce a hard-coded white-list of acceptable IDN TLDs without prior consultation. It is not unreasonable to think that doing so for a second time, with the benefit of hindsight, would be received negatively. I'd also speculate much of the pros and cons to this discussion are equally applicable to the IDN whitelist. ( http://www.mozilla.org/projects/security/tld-idn-policy-list.html) kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: DNS servers (fwd)
Dean Anderson wrote: > The ICANN announcement doesn't seem to have come through on DNSOP as > Patrick indicated. I can't find it in my archive Did anyone else > get it? The announcement was posted on 24 October to [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED], as well as some other closed lists. I didn't send it to DNSOP as I figured it was out of the group's charter of "developing guidelines", but I will note that for the future. If there are any other appropriate places for such announcements to be sent I'd be happy to include them for the future. Apologies to those who didn't get notice through the above. Whilst I am dispensing the mea culpas, I'll also say it was an oversight the original email dispatches weren't PGP signed. The root zone and hints files on internic.net are PGP signed by VRSN if you wish to cross-verify. kim ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS resolver loop for a ccTLD .bg
Zvezdelin Vladov wrote: > > I didn't know where to go to, for such kind of > problem, so I am writing here. > > When a resolve for a ccTLD .bg, there is > a loop going on, maybe somewhere at auth01.ns.uu.net. FYI, auth01.ns.uu.net was removed from the root zone as an authority for .bg on 2007-03-09. kim ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
