Changing RSO addresses, critical infrastructure pools, returning addresses
Just to inform this discussion, here is an article detailing how L-Root returned an address from the general pool, and a third party started providing DNS service on that old address. https://www.icann.org/en/blogs/details/ghosts-of-root-servers-past-19-5-2008... While that story had a happy ending, it is a cautionary tale. This document is providing guidance, and so we should provide recommendations on the best possible procedure. It is irrelevant whether or not some RIR has a critical infrastructure pool, or some RSO doesn't want to (or can't) keep an old address, or any other arguments of that nature. Regards, Robert
Hi, Haven’t been (and won’t be) participating in this particular facet of the RSSAC Caucus, but… On Oct 4, 2024, at 1:26 PM, Robert Story via rssac-caucus <rssac-caucus@icann.org> wrote:
https://www.icann.org/en/blogs/details/ghosts-of-root-servers-past-19-5-2008...
While that story had a happy ending, it is a cautionary tale.
While that particular incident caused a certain amount of heartburn, gnashing of teeth, and (international diplomatic) silliness, I do honestly miss Bill. FWIW, that event led me to suggest root server addresses should be treated as protocol elements, specified by RFC and assigned by IANA in https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia..., such that the addresses _never_ change. In the event of a root server operator changing, the IP addresses that root server uses would transfer to the new operator. That is (in today’s terms) while a root server operator is performing root service, they’d have a ROA for their AS in all 5 RIRs (since there isn’t an IANA RPKI TA) to announce the prefix containing the root server “golden” address they’re operating. Should they no longer provide that service, the golden address moves to the new root server operator (or gets AS0 null routed if that root server identity is no longer needed). Taking into consideration the truly ridiculously long tail of "mis-directed” queries to old root server addresses, the root servers’ addresses unique position in the context of the functioning of the DNS (and, as a result, pretty much the Internet), and the risks entailed when the addresses do change and hence the uselessness of the old address essentially forever, I figured permanently fixing the addresses was a reasonable solution. Others disagreed and it was clear to me it wasn’t worth exploring at that time. Maybe it is now. Or maybe not. Regards, -drc
Hi drc,
On 5 Oct 2024, at 9:47 AM, David Conrad via rssac-caucus <rssac-caucus@icann.org> wrote:
FWIW, that event led me to suggest root server addresses should be treated as protocol elements, specified by RFC and assigned by IANA in https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia..., such that the addresses _never_ change. In the event of a root server operator changing, the IP addresses that root server uses would transfer to the new operator. That is (in today’s terms) while a root server operator is performing root service, they’d have a ROA for their AS in all 5 RIRs (since there isn’t an IANA RPKI TA) to announce the prefix containing the root server “golden” address they’re operating. Should they no longer provide that service, the golden address moves to the new root server operator (or gets AS0 null routed if that root server identity is no longer needed).
"since there isn’t an IANA RPKI TA" I agree with you that these addresses are "special purpose" addresses and they should exist in the IANA Special Purpose Address Registries. But at that point why shouldn't IANA run its own RPKI TA and announce these and the other addresses that are listed in these registries? If the address is not globally routable it could issue a ROA with AS0. Otherwise it could announce ROAs with the relevant originating addresses. In my view, if these are addresses in an IANA registry then the RPKI structure should accurately reflect that. regards, Geoff
I believe this gets into a form of politics (obviously not technology) that I’m no longer paid to have to wade through... :) Regards, -drc
On Oct 4, 2024, at 5:05 PM, Geoff Huston <gih@apnic.net> wrote:
Hi drc,
On 5 Oct 2024, at 9:47 AM, David Conrad via rssac-caucus <rssac-caucus@icann.org> wrote:
FWIW, that event led me to suggest root server addresses should be treated as protocol elements, specified by RFC and assigned by IANA in https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia..., such that the addresses _never_ change. In the event of a root server operator changing, the IP addresses that root server uses would transfer to the new operator. That is (in today’s terms) while a root server operator is performing root service, they’d have a ROA for their AS in all 5 RIRs (since there isn’t an IANA RPKI TA) to announce the prefix containing the root server “golden” address they’re operating. Should they no longer provide that service, the golden address moves to the new root server operator (or gets AS0 null routed if that root server identity is no longer needed).
"since there isn’t an IANA RPKI TA"
I agree with you that these addresses are "special purpose" addresses and they should exist in the IANA Special Purpose Address Registries. But at that point why shouldn't IANA run its own RPKI TA and announce these and the other addresses that are listed in these registries? If the address is not globally routable it could issue a ROA with AS0. Otherwise it could announce ROAs with the relevant originating addresses.
In my view, if these are addresses in an IANA registry then the RPKI structure should accurately reflect that.
regards,
Geoff
Quoting Geoff Huston via rssac-caucus on Saturday October 05, 2024:
"since there isn´t an IANA RPKI TA"
I agree with you that these addresses are "special purpose" addresses and they should exist in the IANA Special Purpose Address Registries. But at that point why shouldn't IANA run its own RPKI TA and announce these and the other addresses that are listed in these registries? If the address is not globally routable it could issue a ROA with AS0. Otherwise it could announce ROAs with the relevant originating addresses.
In my view, if these are addresses in an IANA registry then the RPKI structure should accurately reflect that.
I wasn't a party to the discussions that lead to the current RPKI structure, but this question has come up recently in other contexts where issuing ROAs for IANA reserved address space has been an issue. I am not sure the right forum to explore the issue of IANA-issued ROAs further, but I do wonder - under David's proposal - what would be the threshold for critical infrastructure that merits IANA reservation? Once you open the door here I have to assume there is a slippery slope of other things that warrant similar consideration. kim
Driven through RFC process with an IAB/IANA considerations section. IETF to process the need. IAB to concur and direct. IANA to implement. Not your problem, if it's a process rooted in RFCs. When e.g. we requested AS112 and 2.0.0.2 originally, it was in RFC process. And there are instructions in the RFC which go to delegation functions. "..and remove from AS0 under the IANA TA" would be a natural consequence. So are you saying you want a review of past delegations? minor RFC to add instructions, done. Time consuming but not actually "hard" as much as a bit of a logistical trawl. -G
Kim, I don't know which is the right forum to "to explore the issue of IANA-issued ROAs". I suspect that it still falls in to the bucket that david described as "a form of politics"[1]. I suggest the RSSAC Caucus wouldn't it except to say that to-date I'm not aware that an IANA RPKI TA of any form has been created despite RFC6491 being in existence for over 12 years. [1] Modulo any changes in that environment that might have occurred recently. On the topic of making or establishing "golden" addresses for the root server system, I am quite uncomfortable wth that idea. On the face of it, I see that as a recognition that the method to update the hints files is glacial. More deeply I think it further promotes ossification in a system that should be more agile. Lastly I fear for a process concern should a root server operator be deemed as non-performing or unsuitable (whichever way the governance constructs decree) and is to be removed - but the RSO doesn't want to cooperate. Having that RSO in control of a set of "golden identifiers" means a smooth transition is unlikely to be achievable. I would think a smoother approach would be to change the hints file (yes, putting effort into making the hints file more agile across all DNS codebases) and the NS records in the root zone in participation with an incoming RSO. Cheers Terry
On 8 Oct 2024, at 1:01 AM, Kim Davies via rssac-caucus <rssac-caucus@icann.org> wrote:
Quoting Geoff Huston via rssac-caucus on Saturday October 05, 2024:
"since there isn´t an IANA RPKI TA"
I agree with you that these addresses are "special purpose" addresses and they should exist in the IANA Special Purpose Address Registries. But at that point why shouldn't IANA run its own RPKI TA and announce these and the other addresses that are listed in these registries? If the address is not globally routable it could issue a ROA with AS0. Otherwise it could announce ROAs with the relevant originating addresses.
In my view, if these are addresses in an IANA registry then the RPKI structure should accurately reflect that.
I wasn't a party to the discussions that lead to the current RPKI structure, but this question has come up recently in other contexts where issuing ROAs for IANA reserved address space has been an issue.
I am not sure the right forum to explore the issue of IANA-issued ROAs further, but I do wonder - under David's proposal - what would be the threshold for critical infrastructure that merits IANA reservation? Once you open the door here I have to assume there is a slippery slope of other things that warrant similar consideration.
kim _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Wed 2024-10-09 10:32:59+1000 Terry wrote:
On the topic of making or establishing "golden" addresses for the root server system, I am quite uncomfortable wth that idea.
David's reference to golden addresses was and idea he had in 2008, and has not been proposed in the Changing RSO addresses document. What has been proposed is that RSO service address should be 'special'. The idea being to prevent a Former Service Address (as defined in the document) that has been returned to a RIR from being reallocated to someone other than an RSO. While not (yet) written up in the document, I think the guidance for a Former Service Address should be something along the lines of this ordered list: - continue providing DNS root service on the address - maintain ownership/control of the address (whether it's 'dark' or reused for some other service) - transfer the prefix to another RSO - and as a last resort, return the address to the RIR There is also a proposal to recommend that RSOs requesting a new prefix for root service should request an allocation from the critical infrastructure pool, should the RIR have such a pool. The idea being that critical infrastructure addresses, when returned, are less likely to end up in nefarious hands. There is also a proposal to recommend that 'someone' should bring policy proposals to each of the RIRs to have returned prefixes that have been used for root service placed in a special pool and only re-assigned to another RSO for root service. Kind of like a subset of a critical infrastructure pool. This is currently a fairly contentious issue on the calls, which I why I'm trying to drum up discussion on the list. Regards, Robert USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
Hi Robert,
On 9 Oct 2024, at 03:27, Robert Story via rssac-caucus <rssac-caucus@icann.org> wrote:
David's reference to golden addresses was and idea he had in 2008, and has not been proposed in the Changing RSO addresses document. What has been proposed is that RSO service address should be 'special'. The idea being to prevent a Former Service Address (as defined in the document) that has been returned to a RIR from being reallocated to someone other than an RSO.
While not (yet) written up in the document, I think the guidance for a Former Service Address should be something along the lines of this ordered list:
- continue providing DNS root service on the address - maintain ownership/control of the address (whether it's 'dark' or reused for some other service) - transfer the prefix to another RSO - and as a last resort, return the address to the RIR
There is also a proposal to recommend that RSOs requesting a new prefix for root service should request an allocation from the critical infrastructure pool, should the RIR have such a pool. The idea being that critical infrastructure addresses, when returned, are less likely to end up in nefarious hands.
There is also a proposal to recommend that 'someone' should bring policy proposals to each of the RIRs to have returned prefixes that have been used for root service placed in a special pool and only re-assigned to another RSO for root service. Kind of like a subset of a critical infrastructure pool.
This is currently a fairly contentious issue on the calls, which I why I'm trying to drum up discussion on the list.
Regards, Robert
USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Robert, On 9 Oct 2024, at 03:27, Robert Story via rssac-caucus <rssac-caucus@icann.org> wrote:
David's reference to golden addresses was and idea he had in 2008, and has not been proposed in the Changing RSO addresses document. What has been proposed is that RSO service address should be 'special'. The idea being to prevent a Former Service Address (as defined in the document) that has been returned to a RIR from being reallocated to someone other than an RSO.
This is little more than a single example of the risks of allowing identifiers to be reused by untrusted third parties when they are associated with services that have security requirements. The more general problem is also illustrated in situations such as people letting domain names lapse so they can be registered by others, nameserver hostnames used as glue whose parent domains are claimed by others (as described nicely and somewhat recently by Gautam Akiwate and others), and reuse of individual addresses assigned for use in cloud providers that provide opportunities for reputation colouring or access through ACLs. We see signs of this in the defensive posture that online services take around email addresses used as identifiers and associated restrictions about email hosting, too. There are lots of examples. Considering the implications of identifier reuse is just sensible practice at this point. I don't think the root servers are that special in this regard. I agree that we expect RSOs to follow best practices but I would hope nobody needs to write that down in order for it to happen. Joe
On Wed 2024-10-09 08:40:02+0200 Joe wrote:
Considering the implications of identifier reuse is just sensible practice at this point.
Totally agree.
I don't think the root servers are that special in this regard. I agree that we expect RSOs to follow best practices but I would hope nobody needs to write that down in order for it to happen.
<tongue in cheek>So we can just reduce this document to "Do the right thing"?</> But seriously, though, I think we've all been around long enough to know that what's sensible to on person can be nonsensical to another, or just something they didn't think of. eg underspecified RFCs result in bugs, and need errata or revision. Do you have a reference to a best practices document that talks about identifier reuse? It would be great to be able to referencing such a document while talking about how RSOs should mitigate the risks. Regards, Robert USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
On 9 Oct 2024, at 16:10, Robert Story <rstory@ant.isi.edu> wrote:
Do you have a reference to a best practices document that talks about identifier reuse? It would be great to be able to referencing such a document while talking about how RSOs should mitigate the risks.
I don't have a good reference for general advice, although to be clear I haven't looked and so I'm not saying there isn't one. Probably I should look. A reference would be useful. Joe
Joe, On Oct 8, 2024, at 11:40 PM, Joe Abley via rssac-caucus <rssac-caucus@icann.org> wrote:
Considering the implications of identifier reuse is just sensible practice at this point. I don't think the root servers are that special in this regard.
I believe the blast radius of misuse of a root server address to be a bit larger than pretty much any other identifier.
I agree that we expect RSOs to follow best practices but I would hope nobody needs to write that down in order for it to happen.
“Just use common sense”? Regards, -drc
Hi Robert, A few responses in line...
On 9 Oct 2024, at 11:26 AM, Robert Story <rstory@ant.isi.edu> wrote:
David's reference to golden addresses was and idea he had in 2008, and has not been proposed in the Changing RSO addresses document. What has been proposed is that RSO service address should be 'special'. The idea being to prevent a Former Service Address (as defined in the document) that has been returned to a RIR from being reallocated to someone other than an RSO.
Why (5-why"s root cause analysis) is that address special?
While not (yet) written up in the document, I think the guidance for a Former Service Address should be something along the lines of this ordered list:
- continue providing DNS root service on the address
what does it matter if the DNS answer validates?
- maintain ownership/control of the address (whether it's 'dark' or reused for some other service)
See above. If it goes dark, then great! if it's reused and people still use the address in a resolution frame then 'see above' (shouldn't we expect DNSSEC validation?)
- transfer the prefix to another RSO - and as a last resort, return the address to the RIR
The above two are administrative.. Sorry to be the cynical nay-sayer, but what I have seen is that bureaucracies don't often end up giving you the answer you need or want.
There is also a proposal to recommend that RSOs requesting a new prefix for root service should request an allocation from the critical infrastructure pool, should the RIR have such a pool. The idea being that critical infrastructure addresses, when returned, are less likely to end up in nefarious hands.
"nefarious" calls out some risk profile. Has the workgroup defined that risk profile? What is the text? If that is then a problem statement wouldn't it be better dealt with at a protocol or operational layer rather than praying 5 RIR policies are homogeneous, or policies won't change under your feet?? If it's punted to the policy layer, then i would suggest the WG is on thin ice, and it won't pass the "pub test".
There is also a proposal to recommend that 'someone' should bring policy proposals to each of the RIRs to have returned prefixes that have been used for root service placed in a special pool and only re-assigned to another RSO for root service. Kind of like a subset of a critical infrastructure pool.
I disagree with this proposal .. The v4/v6 prefix (and ASNs) should only be considered important as long as it holds the "token" as an RSO (in hints and root zone). That is the goal, IMHO. It doesn't matter where the service address comes from, e.g. Historical allocation, RIR/NIR allocation or assignment , acquisition by MNA, or leasing the space. There should be nothing special about the address for where the root zone service is presented, except that the address is in the hints file and in the root zone and the DNS answers are DNSSEC validated.
This is currently a fairly contentious issue on the calls, which I why I'm trying to drum up discussion on the list.
Understood.. and happy to see that discussion happen! Cheers, Terry (ps. offline for a day or two flying a helicopter - responses delayed)
Terry, On Oct 9, 2024, at 3:49 AM, Terry Manderson via rssac-caucus <rssac-caucus@icann.org> wrote:
Why (5-why"s root cause analysis) is that address special?
Root server addresses come hard wired into millions of (potentially) unmanaged servers globally. Updating those addresses has been empirically proven to take a _very_ long time. Reusing those addresses is problematic and poses a security risk. There are probably others I’m forgetting.
- continue providing DNS root service on the address what does it matter if the DNS answer validates?
2/3rds of the Internet doesn’t validate after decades and it doesn’t appear the rate of change is improving all that much? Regards, -drc
- continue providing DNS root service on the address what does it matter if the DNS answer validates?
2/3rds of the Internet doesn’t validate after decades and it doesn’t appear the rate of change is improving all that much?
its not really getting any better - 2/3 of the Internet works on the misguided assumption that it you send a packet to the "correct" IP address then the response is also "correct". It opens the door to all kinds of abuse, and it seems like a small thing to me not to make this situation any worse by permitting masquerading DNS root servers to camp on "old" root server addresses. https://stats.labs.apnic.net/dnssec/XA?hc=XA&hx=0&hv=1&hp=1&hr=1&w=1&p=0 Geoff
David,
On 10 Oct 2024, at 3:35 AM, David Conrad <david.conrad@layer9.tech> wrote:
On Oct 9, 2024, at 3:49 AM, Terry Manderson via rssac-caucus <rssac-caucus@icann.org> wrote:
Why (5-why"s root cause analysis) is that address special?
Root server addresses come hard wired into millions of (potentially) unmanaged servers globally. Updating those addresses has been empirically proven to take a _very_ long time. Reusing those addresses is problematic and poses a security risk. There are probably others I’m forgetting.
I will take your word for that, I would have to find data to say otherwise.
- continue providing DNS root service on the address what does it matter if the DNS answer validates?
2/3rds of the Internet doesn’t validate after decades and it doesn’t appear the rate of change is improving all that much?
Looking at DO bit query attributes on L.ROOT-SERVERS.NET <http://l.root-servers.net/> publicly available data, DO=1 is around the 130K queries per second, with DO=0 or no DO at around 30K queries per second. I don't agree with "2/3rds don't validate." I will agree that the graph seems stable - others with longer baseline visibility might be able to observe a trend. Cheers, Terry
Terry, On Oct 15, 2024, at 5:01 AM, Terry Manderson <terry@terrym.net> wrote:
Looking at DO bit query attributes on L.ROOT-SERVERS.NET <http://l.root-servers.net/> publicly available data, DO=1 is around the 130K queries per second, with DO=0 or no DO at around 30K queries per second. I don't agree with "2/3rds don't validate." I will agree that the graph seems stable - others with longer baseline visibility might be able to observe a trend.
DO=1 means “I can understand DNSSEC-related RRs”. It doesn’t mean a resolver actually does anything with those RRs. As far as I'm aware, the best statistics for actual DNSSEC validation is at https://stats.labs.apnic.net/dnssec. Regards, -drc
Hi David, That is a correct interpretation of the DO bit. I haven't looked at the APNIC stats, but will do so later ... However if that is the case, one would ask "WHY" are so many resolvers are asking for DNSSEC responses and doing nothing with them? Again, root cause analysis! If the result is just laziness, then any approach discussed without DNSSEC validation as a staple disenfranchises those that have gone to the effort to sign their zones. Cheers, Terry -- Mobile device, don't expect grammar.
On 15 Oct 2024, at 10:39 AM, David Conrad <david.conrad@layer9.tech> wrote:
Terry,
On Oct 15, 2024, at 5:01 AM, Terry Manderson <terry@terrym.net> wrote: Looking at DO bit query attributes on L.ROOT-SERVERS.NET <http://l.root-servers.net/> publicly available data, DO=1 is around the 130K queries per second, with DO=0 or no DO at around 30K queries per second. I don't agree with "2/3rds don't validate." I will agree that the graph seems stable - others with longer baseline visibility might be able to observe a trend.
DO=1 means “I can understand DNSSEC-related RRs”. It doesn’t mean a resolver actually does anything with those RRs. As far as I'm aware, the best statistics for actual DNSSEC validation is at https://stats.labs.apnic.net/dnssec.
Regards, -drc
terry> That is a correct interpretation of the DO bit. I haven't looked terry> at the APNIC stats, but will do so later ... However if that is terry> the case, one would ask "WHY" are so many resolvers are asking terry> for DNSSEC responses and doing nothing with them? Again, root terry> cause analysis! stub OS resolvers like microsoft have been setting DO bit for decades and the resolvers above them pass that on. doesn't mean they use the signatures, etc.
From: Paul Ebersman via rssac-caucus <rssac-caucus@icann.org> terry> That is a correct interpretation of the DO bit. I haven't looked terry> at the APNIC stats, but will do so later ... However if that is terry> the case, one would ask "WHY" are so many resolvers are asking terry> for DNSSEC responses and doing nothing with them? Again, root terry> cause analysis!
stub OS resolvers like microsoft have been setting DO bit for decades and the resolvers above them pass that on. doesn't mean they use the signatures, etc.
My windows clinet does not set DO bit. Full service resolvers like BIND 9, Unbound, Knot Resolvers, etc have been setting DO bit to pass RRSIGs to stub validators when they do not validate. RFC 4033 and RFC 4035 defines Security-Aware resolvers (that know DNSSEC) MUST set DO bit when sending requests. (even if they don't validate) See: RFC 4035 Section 3.2.1, RFC 4033 Section 2 If we want to know the DNSSEC validation of full-service resolvers from the root servers side, we can look at the number of IP addresses that sends "." DNSKEY queries to. -- Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
Fujiwara-san, Thank you for. that! I don't see that stub resolvers are capable of DNSSEC validation at this point, or even the desired location from "conservation of processing" point of view, but that might be just me.. Has there been any studies done to analyse the number of resolvers taking to the RSS (with query volumes) that do or do not ask for DNSKEY?? (google scholar didn't find anything of note) Would that not be the categorical definition of DNSSEC validation? Especially in regards to the root server system? Cheers, Terry -- Mobile device, don't expect grammar.
On 15 Oct 2024, at 1:55 PM, Kazunori Fujiwara <fujiwara@jprs.co.jp> wrote:
From: Paul Ebersman via rssac-caucus <rssac-caucus@icann.org> terry> That is a correct interpretation of the DO bit. I haven't looked terry> at the APNIC stats, but will do so later ... However if that is terry> the case, one would ask "WHY" are so many resolvers are asking terry> for DNSSEC responses and doing nothing with them? Again, root terry> cause analysis!
stub OS resolvers like microsoft have been setting DO bit for decades and the resolvers above them pass that on. doesn't mean they use the signatures, etc.
My windows clinet does not set DO bit.
Full service resolvers like BIND 9, Unbound, Knot Resolvers, etc have been setting DO bit to pass RRSIGs to stub validators when they do not validate.
RFC 4033 and RFC 4035 defines Security-Aware resolvers (that know DNSSEC) MUST set DO bit when sending requests. (even if they don't validate)
See: RFC 4035 Section 3.2.1, RFC 4033 Section 2
If we want to know the DNSSEC validation of full-service resolvers from the root servers side, we can look at the number of IP addresses that sends "." DNSKEY queries to.
-- Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
Terry-san,
Has there been any studies done to analyse the number of resolvers taking to the RSS (with query volumes) that do or do not ask for DNSKEY?? (google scholar didn't find anything of note)
We have DITL dataset. However, IP address anonymization makes estimation difficult. I did such research in 2010-2013. - Increase of probable DNSSEC Validations and DNSSEC side effect, 28 July 2013, IEPG Meeting, Berlin, Germany. http://www.iepg.org/2013-07-ietf87/4%20-%20IEPG-201307-fujiwara-02.pdf - Analysis of DITL root data and comparison with jp data , 6 Oct., 2013, DNS-OARC Fall 2013 Workshop, Phoenix, AZ, US. https://indico.dns-oarc.net//getFile.py/access?contribId=1&resId=0&materialI...
Would that not be the categorical definition of DNSSEC validation? Especially in regards to the root server system?
Since many measurement probes send similar queries to root-servers as DNSSEC validators, it may be difficult to accurately determine the number of DNSSEC validators. -- Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
Thank you Fujiwara-san for doing some repeatable research! It's been over 10 years since your valuable efforts. Perhaps time to redo that with higher fidelity data from all the RSO's? Better yet including data from the global public resolvers? I note that my observation of NSEC3, for the explicit denial of non-existence, has changed the traffic profile of DNS traffic to the RSS, at one point it was grater than 80% of the qry rate. Seems now it may be less than 50%. So the system is evolving. I also note (and i think i agree with you) that using probes to send queries directly to root servers is misaligned with the resolution process, hence the fidelity of results is far less than ideal. Getting data directly from the resolvers would (with lofty expectations) the gold standard. Cheers, Terry -- Mobile device, don't expect grammar.
On 15 Oct 2024, at 2:30 PM, Kazunori Fujiwara <fujiwara@jprs.co.jp> wrote:
Terry-san,
Has there been any studies done to analyse the number of resolvers taking to the RSS (with query volumes) that do or do not ask for DNSKEY?? (google scholar didn't find anything of note)
We have DITL dataset. However, IP address anonymization makes estimation difficult.
I did such research in 2010-2013.
- Increase of probable DNSSEC Validations and DNSSEC side effect, 28 July 2013, IEPG Meeting, Berlin, Germany.
http://www.iepg.org/2013-07-ietf87/4%20-%20IEPG-201307-fujiwara-02.pdf
- Analysis of DITL root data and comparison with jp data , 6 Oct., 2013, DNS-OARC Fall 2013 Workshop, Phoenix, AZ, US.
https://indico.dns-oarc.net//getFile.py/access?contribId=1&resId=0&materialI...
Would that not be the categorical definition of DNSSEC validation? Especially in regards to the root server system?
Since many measurement probes send similar queries to root-servers as DNSSEC validators, it may be difficult to accurately determine the number of DNSSEC validators.
-- Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
terry> Thank you Fujiwara-san for doing some repeatable research! It's terry> been over 10 years since your valuable efforts. terry> Perhaps time to redo that with higher fidelity data from all the terry> RSO's? Better yet including data from the global public terry> resolvers? Agree with both kudos and desire for more recent redo of these efforts. ebersman> Resolver operators running antique resolvers or buying into ebersman> all the FUD that validating causes all sorts of failures users ebersman> will scream at them about? terry> I'll take that as a question to investigate.. Seeing if resolver operators are finally past the FUD would be interesting. My guess is that the trailing edge are enterprises/orgs (along with USG/DOD), rather than the large recursive farms or ISPs. The latter mostly have bought into validation. Another interesting question to me is if the growth of mobile devices has made any change in what mobile providers are doing in terms of DNSSEC validation. As for old software, based on my time doing tech support for BIND (when BIND8 was already deprecated but BIND4 was not uncommon enough) and at a large ISP, where the number of 10+ year old versions of DNSMASQ on routers was way too high, I think we all know how long old cruft still sticks around. We're still seeing A6 queries at the root, aren't we? :)
Greetings, all. I'm seeing a lot of things in that thread that have nothing to do with the thread topic. They do have to do with possible future interesting work for the RSSAC Caucus. Please consider starting a new thread with your new idea for work. This will help those of us who might want to work with you to know where you are going. If you really are commenting on the current document, please maybe point more carefully at which words in the document you think need changing. This will help those of us who think the document is pretty much done know where it might not be. Thanks! --Paul Hoffman
Following up on what Paul said, I think this document has too narrow a scope. It addresses something that has happened infrequently, and unless someone is hinting at something, it shouldn’t occur for a while—at least not without plenty of notice and under controlled circumstances. I’ve been reading through the thread but haven’t had much time to respond. Between recovering from the heart attack, job hunting, and just enjoying life, things have been a bit slow on my end. That said, I believe the following points have been discussed and either need the scope of the current document extended or require the formation of a new work party: 1. Updating root hints and everything that entails, with proper communication and, hopefully, smooth propagation to the folks who need it (e.g., software vendors). NEW WORK PARTY? 2. RSO communication—this is being discussed elsewhere, but how can we better communicate with the ‘community’ and other stakeholders? NEW WORK PARTY? 3. Accepting direct communication from the community to the RSO for $REASONS. NEW WORK PARTY? 4. The current document doesn’t seem to address future scenarios and focuses only on instances where an RSO is changing a current address. I think the following should be considered: a. In-place changes where an RSO needs to update for $REASONS. i. Should a global policy be proposed to reserve some CI space in each RIR’s pool for expansion? b. Operator experiences a protracted outage, and another RSO needs to temporarily announce the space. c. Operator capture—needs removal, and another RSO needs to announce for $TIME. d. Operator goes rogue or ghosts the RSO and fails to fulfill their obligations. e. A new operator is added, and a new letter is required (likely using CI space from the RIR's). i. Should a global policy be proposed to reserve some CI space in each RIR's pool for expansion? Respectfully submitted for your consideration. I believe the document should include or expand on some future-proofing to account for these possibilities. -- Darren Kara darren@thekaras.org On Tue, Oct 15, 2024, at 12:22 PM, Paul Hoffman via rssac-caucus wrote:
Greetings, all. I'm seeing a lot of things in that thread that have nothing to do with the thread topic. They do have to do with possible future interesting work for the RSSAC Caucus.
Please consider starting a new thread with your new idea for work. This will help those of us who might want to work with you to know where you are going.
If you really are commenting on the current document, please maybe point more carefully at which words in the document you think need changing. This will help those of us who think the document is pretty much done know where it might not be.
Thanks!
--Paul Hoffman _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Replies inline, mostly no hat. On 2024/10/15 20:22, Darren Kara via rssac-caucus wrote:
I think this document has too narrow a scope
I think it's just right. The SOW was AIUI mostly intended to create a document that covers all the "dumb questions" that arose when B-root announced their recent change on NANOG and other places. Apart from a thorny question about allocation policies (see below) the work party is *mostly* done.
1. Updating root hints and everything that entails, with proper communication and, hopefully, smooth propagation to the folks who need it (e.g., software vendors). NEW WORK PARTY?
IANA has an established process for updating the root hints (and the other two official sources of root server addresses listed in RSSAC030) and changes to that are (IMHO) out of our purview. We've touched on the communications (see below).
2. RSO communication—this is being discussed elsewhere, but how can we better communicate with the ‘community’ and other stakeholders? NEW WORK PARTY?
3. Accepting direct communication from the community to the RSO for $REASONS. NEW WORK PARTY?
Hmm, maybe. We've punted on this within the scope of this work party, at least for outbound communications re: root server IP changes. The majority view is that any notifications to anyone beyond IANA are effectively a courtesty notification, and we are currently loathe to formalise anything beyond that. If there was a body that should be in a position to notify the community (where membership of that community is self selecting) it's probably IANA itself but I don't think RSSAC has standing to ask IANA to take that on. For more general communications between the RSOs and stakeholders, that probably has to wait until RSS GS is in place.
4. The current document doesn’t seem to address future scenarios and focuses only on instances where an RSO is changing a current address. I think the following should be considered:
a. In-place changes where an RSO needs to update for $REASONS.
How is that different to the work party's current topic?
i. Should a global policy be proposed to reserve some CI space in each RIR’s pool for expansion?
Something like this is being discussed, or more specifically, how to develop a policy that preserves any current address space currently being used for root service such that it can never be used for anything else. In the presence of such a hypothetical policy it is unclear that there is any additional benefit of using CI space, since the primary characteristic of CI space are its allocation and return policies. (Once you have space, the allocation policy doesn't matter. If the global policy is that root service space doesn't get returned, then the CI return policies don't matter either)
b. Operator experiences a protracted outage, and another RSO needs to temporarily announce the space.
c. Operator capture—needs removal, and another RSO needs to announce for $TIME.
d. Operator goes rogue or ghosts the RSO and fails to fulfill their obligations.
Cannot be done (AFAIK) under the current LIR / RIR model (where the IP space is under the control of the individual RSOs) without either the cooperation of the failing RSO or unilateral action by the RIR that would be very likely (IANAL) outside of their T&Cs.
e. A new operator is added, and a new letter is required (likely using CI space from the RIR's).
Subject to resolution of the CI question, this is effectively covered by the current document. Ray
[ Yes, I changed the subject, again, so that the threads make sense later. ] On Oct 15, 2024, at 12:22, Darren Kara via rssac-caucus <rssac-caucus@icann.org> wrote:
I think this document has too narrow a scope. It addresses something that has happened infrequently, and unless someone is hinting at something, it shouldn’t occur for a while—at least not without plenty of notice and under controlled circumstances.
No one in the Work Party has hinted at anything like that.
That said, I believe the following points have been discussed and either need the scope of the current document extended or require the formation of a new work party:
1. Updating root hints and everything that entails, with proper communication and, hopefully, smooth propagation to the folks who need it (e.g., software vendors). NEW WORK PARTY?
In my mind, this belongs to IANA, not the RSSAC. If RSSAC feels that IANA is doing this wrong, then a note to IANA would probably suffice; having said that, I haven't heard what IANA is doing wrong here.
2. RSO communication—this is being discussed elsewhere, but how can we better communicate with the ‘community’ and other stakeholders? NEW WORK PARTY?
RSSAC (not the Caucus) is actively working on this. RSSAC has, so far, not asked for Caucus input on their work.
3. Accepting direct communication from the community to the RSO for $REASONS. NEW WORK PARTY?
RSOs hear directly from the community all the time. Can you be more specific about the problem?
4. The current document doesn’t seem to address future scenarios and focuses only on instances where an RSO is changing a current address. I think the following should be considered: a. In-place changes where an RSO needs to update for $REASONS.
Update what?
i. Should a global policy be proposed to reserve some CI space in each RIR’s pool for expansion?
That is indeed being discussed.
b. Operator experiences a protracted outage, and another RSO needs to temporarily announce the space.
Define "need". Seriously, what noticeable damage is done by an RSO being unresponsive for a long time?
c. Operator capture—needs removal, and another RSO needs to announce for $TIME.
This is a core goal for the RSS GWG.
d. Operator goes rogue or ghosts the RSO and fails to fulfill their obligations.
This is a core goal for the RSS GWG.
e. A new operator is added, and a new letter is required (likely using CI space from the RIR's). i. Should a global policy be proposed to reserve some CI space in each RIR's pool for expansion?
I suspect that this is closely related to (4a) above. --Paul Hoffman
Thanks paul, I was mostly summarizing what I've seen to be some distinct threads while I've been getting caught up thanks @ray for a good summary of things as well as Paul. I guess the distinction between an existing RSO and any future doesn't appear to be addressed, again ill have to read the document thricely, as stated i've been recovering from a near death experience and getting caught up. I also have a bit of time after my sudden departure from ICANN. warm regards, -- Darren Kara darren@thekaras.org On Tue, Oct 15, 2024, at 4:52 PM, Paul Hoffman wrote:
[ Yes, I changed the subject, again, so that the threads make sense later. ]
On Oct 15, 2024, at 12:22, Darren Kara via rssac-caucus <rssac-caucus@icann.org> wrote:
I think this document has too narrow a scope. It addresses something that has happened infrequently, and unless someone is hinting at something, it shouldn’t occur for a while—at least not without plenty of notice and under controlled circumstances.
No one in the Work Party has hinted at anything like that.
That said, I believe the following points have been discussed and either need the scope of the current document extended or require the formation of a new work party:
1. Updating root hints and everything that entails, with proper communication and, hopefully, smooth propagation to the folks who need it (e.g., software vendors). NEW WORK PARTY?
In my mind, this belongs to IANA, not the RSSAC. If RSSAC feels that IANA is doing this wrong, then a note to IANA would probably suffice; having said that, I haven't heard what IANA is doing wrong here.
2. RSO communication—this is being discussed elsewhere, but how can we better communicate with the ‘community’ and other stakeholders? NEW WORK PARTY?
RSSAC (not the Caucus) is actively working on this. RSSAC has, so far, not asked for Caucus input on their work.
3. Accepting direct communication from the community to the RSO for $REASONS. NEW WORK PARTY?
RSOs hear directly from the community all the time. Can you be more specific about the problem?
4. The current document doesn’t seem to address future scenarios and focuses only on instances where an RSO is changing a current address. I think the following should be considered: a. In-place changes where an RSO needs to update for $REASONS.
Update what?
i. Should a global policy be proposed to reserve some CI space in each RIR’s pool for expansion?
That is indeed being discussed.
b. Operator experiences a protracted outage, and another RSO needs to temporarily announce the space.
Define "need". Seriously, what noticeable damage is done by an RSO being unresponsive for a long time?
c. Operator capture—needs removal, and another RSO needs to announce for $TIME.
This is a core goal for the RSS GWG.
d. Operator goes rogue or ghosts the RSO and fails to fulfill their obligations.
This is a core goal for the RSS GWG.
e. A new operator is added, and a new letter is required (likely using CI space from the RIR's). i. Should a global policy be proposed to reserve some CI space in each RIR's pool for expansion?
I suspect that this is closely related to (4a) above.
--Paul Hoffman
Paul, I appreciate your goal of trying to seperate threads to make it easier for document editing and coordination.. unfortunately for me (and I had two other folks message me offline) it came across as silencing or redirecting discussion. There are some gems in what has been said in threads so far that speak to the "why" actions might happen in Changing RSO Addressees. Be that related to Hints File Agility, lack of adoption of resolver DNSSEC validation, ongoing lethargic adoption of new code bases etc... And that, IMHO, leads to deeper exploration of what the meaty RSASC recommendations might be to the community. Cheers Terry
On 16 Oct 2024, at 2:22 AM, Paul Hoffman via rssac-caucus <rssac-caucus@icann.org> wrote:
Greetings, all. I'm seeing a lot of things in that thread that have nothing to do with the thread topic. They do have to do with possible future interesting work for the RSSAC Caucus.
Please consider starting a new thread with your new idea for work. This will help those of us who might want to work with you to know where you are going.
If you really are commenting on the current document, please maybe point more carefully at which words in the document you think need changing. This will help those of us who think the document is pretty much done know where it might not be.
Thanks!
--Paul Hoffman _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hey Paul, Have been away from the desk for motorcycle and helicopter reasons...
On 16 Oct 2024, at 1:50 AM, Paul Ebersman <list-rssac@dragon.net> wrote:
terry> I'll take that as a question to investigate..
Seeing if resolver operators are finally past the FUD would be interesting. My guess is that the trailing edge are enterprises/orgs (along with USG/DOD), rather than the large recursive farms or ISPs. The latter mostly have bought into validation.
Another interesting question to me is if the growth of mobile devices has made any change in what mobile providers are doing in terms of DNSSEC validation.
Agreed on both of the above... all of that speaks, "in my opinion" to the "why" of why we are now "still" discussing effects of ossification.
As for old software, based on my time doing tech support for BIND (when BIND8 was already deprecated but BIND4 was not uncommon enough) and at a large ISP, where the number of 10+ year old versions of DNSMASQ on routers was way too high, I think we all know how long old cruft still sticks around. We're still seeing A6 queries at the root, aren't we? :)
So that is, IMO, that we as an industry never versioned DNS (as a protocol set .... - yep, I have a part of the blame from being on the IESG) that allowed the industry to specify a version of "specification". Personally Postel's mantra of "“e conservative in what you do, be liberal in what you accept from others” has in part created this problem, we never actually do that with the Infosec term of "CIA" (not the USA's intel org) .. But that's a beer discussion. T.
ebersman> stub OS resolvers like microsoft have been setting DO bit for ebersman> decades and the resolvers above them pass that on. doesn't ebersman> mean they use the signatures, etc. fujiwara> My windows clinet does not set DO bit. The windows OS started setting DO years ago. Haven't heard that they've changed that recently. Pretty sure mac OSX has also been doing the same. The stub resolver doesn't validate but it does set DO.
Paul,
stub OS resolvers like microsoft have been setting DO bit for decades and the resolvers above them pass that on. doesn't mean they use the signatures, etc.
Right, I get that.. Personally, I think more work needed in terms of understanding why resolvers are/aren't validating. Cheers, Terry
terry> Personally, I think more work needed in terms of understanding terry> why resolvers are/aren't validating. Resolver operators running antique resolvers or buying into all the FUD that validating causes all sorts of failures users will scream at them about?
Hi Paul, I'll take that as a question to investigate.. Though, so far it seems there is a decent level of inquiry for my liking to be able to answer the deeper question that started this thread. Cheers, Terry -- Mobile device, don't expect grammar.
On 15 Oct 2024, at 2:21 PM, Paul Ebersman <list-rssac@dragon.net> wrote:
terry> Personally, I think more work needed in terms of understanding terry> why resolvers are/aren't validating.
Resolver operators running antique resolvers or buying into all the FUD that validating causes all sorts of failures users will scream at them about?
Apologies, edit s/it seems there is a decent level of inquiry for my liking/it seems there is a decent level of inquiry for my liking/it seems there ISN'T a decent level of inquiry for my liking/ Cheers, Terry -- Mobile device, don't expect grammar.
On 15 Oct 2024, at 2:33 PM, Terry Manderson <terry@terrym.net> wrote:
Hi Paul,
I'll take that as a question to investigate..
Though, so far it seems there is a decent level of inquiry for my liking to be able to answer the deeper question that started this thread.
Cheers, Terry -- Mobile device, don't expect grammar.
On 15 Oct 2024, at 2:21 PM, Paul Ebersman <list-rssac@dragon.net> wrote:
terry> Personally, I think more work needed in terms of understanding terry> why resolvers are/aren't validating.
Resolver operators running antique resolvers or buying into all the FUD that validating causes all sorts of failures users will scream at them about?
On 15 Oct 2024, at 2:19 PM, Paul Ebersman via rssac-caucus <rssac-caucus@icann.org> wrote:
terry> That is a correct interpretation of the DO bit. I haven't looked terry> at the APNIC stats, but will do so later ... However if that is terry> the case, one would ask "WHY" are so many resolvers are asking terry> for DNSSEC responses and doing nothing with them? Again, root terry> cause analysis!
stub OS resolvers like microsoft have been setting DO bit for decades and the resolvers above them pass that on. doesn't mean they use the signatures, etc.
some data... some 42% of users sit behind a collection of recursive resolvers _SOME_ of which perform DNSSEC validation some 34% of users sit behind a collection of recursive resolvers _ALL_ of which perform DNSSEC validation (https://stats.labs.apnic.net/dnssec/XA) in one day (14 October) we observed 0.49% of users sit behind a recursive resolver that does NOT use EDNS(0). Some 92.6% of users have the DNSSEC_OK bit set in their queries If we just look at recursive resolvers, and not weight the results by query volume, 2.16% of resolvers do not do EDNS(0) and some 92.58% use the DNSSEC_OK bit set in their queries. Geoff
Thanks Geoff, This is based on some sampling constructs, yes? Can you point me to your methodology? I couldn't see it on the links provided. Thanks! T.
On 16 Oct 2024, at 5:57 AM, Geoff Huston <gih@apnic.net> wrote:
On 15 Oct 2024, at 2:19 PM, Paul Ebersman via rssac-caucus <rssac-caucus@icann.org> wrote:
terry> That is a correct interpretation of the DO bit. I haven't looked terry> at the APNIC stats, but will do so later ... However if that is terry> the case, one would ask "WHY" are so many resolvers are asking terry> for DNSSEC responses and doing nothing with them? Again, root terry> cause analysis!
stub OS resolvers like microsoft have been setting DO bit for decades and the resolvers above them pass that on. doesn't mean they use the signatures, etc.
some data...
some 42% of users sit behind a collection of recursive resolvers _SOME_ of which perform DNSSEC validation some 34% of users sit behind a collection of recursive resolvers _ALL_ of which perform DNSSEC validation
(https://stats.labs.apnic.net/dnssec/XA)
in one day (14 October) we observed 0.49% of users sit behind a recursive resolver that does NOT use EDNS(0). Some 92.6% of users have the DNSSEC_OK bit set in their queries
If we just look at recursive resolvers, and not weight the results by query volume, 2.16% of resolvers do not do EDNS(0) and some 92.58% use the DNSSEC_OK bit set in their queries.
Geoff
its the APNIC Ad-based measurement system. (https://www.potaroo.net/ispcol/2023-10/measure-dnssec.html). In this case I'm looking at the query profile seen at the authoritative servers for an unsigned domain name. Geoff
On 22 Oct 2024, at 5:40 PM, Terry Manderson <terry@terrym.net> wrote:
Thanks Geoff,
This is based on some sampling constructs, yes? Can you point me to your methodology? I couldn't see it on the links provided.
Thanks! T.
On 16 Oct 2024, at 5:57 AM, Geoff Huston <gih@apnic.net> wrote:
On 15 Oct 2024, at 2:19 PM, Paul Ebersman via rssac-caucus <rssac-caucus@icann.org> wrote:
terry> That is a correct interpretation of the DO bit. I haven't looked terry> at the APNIC stats, but will do so later ... However if that is terry> the case, one would ask "WHY" are so many resolvers are asking terry> for DNSSEC responses and doing nothing with them? Again, root terry> cause analysis!
stub OS resolvers like microsoft have been setting DO bit for decades and the resolvers above them pass that on. doesn't mean they use the signatures, etc.
some data...
some 42% of users sit behind a collection of recursive resolvers _SOME_ of which perform DNSSEC validation some 34% of users sit behind a collection of recursive resolvers _ALL_ of which perform DNSSEC validation
(https://stats.labs.apnic.net/dnssec/XA)
in one day (14 October) we observed 0.49% of users sit behind a recursive resolver that does NOT use EDNS(0). Some 92.6% of users have the DNSSEC_OK bit set in their queries
If we just look at recursive resolvers, and not weight the results by query volume, 2.16% of resolvers do not do EDNS(0) and some 92.58% use the DNSSEC_OK bit set in their queries.
Geoff
Terry, The path a particular resolution takes can be arbitrarily complex due to forwarders and other eyebrow-raising operational choices. In order for DNSSEC-related RRs to get from the authoritative to the validator, every resolver-like thing in the path must signal it won’t drop DNSSEC RRs (or explode in flames on seeing an RR it didn’t understand — RFC 3225 is old and before it was implemented, there were resolver implementations that behaved poorly when they saw DNSSEC RRs). As a result, pretty much every modern resolver (or resolver-like thing) that implements DNSSEC sets DO=1, even it never actually validates. Regards, -drc On Tue, Oct 15, 2024, at 8:44 AM, Terry Manderson wrote:
Hi David,
That is a correct interpretation of the DO bit. I haven't looked at the APNIC stats, but will do so later ... However if that is the case, one would ask "WHY" are so many resolvers are asking for DNSSEC responses and doing nothing with them? Again, root cause analysis!
If the result is just laziness, then any approach discussed without DNSSEC validation as a staple disenfranchises those that have gone to the effort to sign their zones.
Cheers, Terry -- Mobile device, don't expect grammar.
On 15 Oct 2024, at 10:39 AM, David Conrad <david.conrad@layer9.tech> wrote: Terry,
On Oct 15, 2024, at 5:01 AM, Terry Manderson <terry@terrym.net> wrote:
Looking at DO bit query attributes on L.ROOT-SERVERS.NET <http://l.root-servers.net/> publicly available data, DO=1 is around the 130K queries per second, with DO=0 or no DO at around 30K queries per second. I don't agree with "2/3rds don't validate." I will agree that the graph seems stable - others with longer baseline visibility might be able to observe a trend.
DO=1 means “I can understand DNSSEC-related RRs”. It doesn’t mean a resolver actually does anything with those RRs. As far as I'm aware, the best statistics for actual DNSSEC validation is at https://stats.labs.apnic.net/dnssec.
Regards, -drc
Robert, You say “tomatoe” and I say “tomatoh”. In both cases, the attachment point for root service on the Internet (the IP address) is treated specially. My idea is simply to not bother with the gymnastics to deal with something that changes maybe once a decade on average, stop pretending root server IP addresses _aren’t_ special by explicitly listing them in the special use address registry, and use the routing system to deal with the EXCEPTIONALLY rare case of root service changing operators. Regards, -drc
On Oct 8, 2024, at 6:25 PM, Robert Story via rssac-caucus <rssac-caucus@icann.org> wrote:
On Wed 2024-10-09 10:32:59+1000 Terry wrote:
On the topic of making or establishing "golden" addresses for the root server system, I am quite uncomfortable wth that idea.
David's reference to golden addresses was and idea he had in 2008, and has not been proposed in the Changing RSO addresses document. What has been proposed is that RSO service address should be 'special'. The idea being to prevent a Former Service Address (as defined in the document) that has been returned to a RIR from being reallocated to someone other than an RSO.
While not (yet) written up in the document, I think the guidance for a Former Service Address should be something along the lines of this ordered list:
- continue providing DNS root service on the address - maintain ownership/control of the address (whether it's 'dark' or reused for some other service) - transfer the prefix to another RSO - and as a last resort, return the address to the RIR
There is also a proposal to recommend that RSOs requesting a new prefix for root service should request an allocation from the critical infrastructure pool, should the RIR have such a pool. The idea being that critical infrastructure addresses, when returned, are less likely to end up in nefarious hands.
There is also a proposal to recommend that 'someone' should bring policy proposals to each of the RIRs to have returned prefixes that have been used for root service placed in a special pool and only re-assigned to another RSO for root service. Kind of like a subset of a critical infrastructure pool.
This is currently a fairly contentious issue on the calls, which I why I'm trying to drum up discussion on the list.
Regards, Robert
USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Terry, On Oct 8, 2024, at 5:32 PM, Terry Manderson via rssac-caucus <rssac-caucus@icann.org> wrote:
More deeply I think it further promotes ossification in a system that should be more agile.
If you want “agility” (ignoring “why?"), in the current system, there are two vectors for change: (1) changing the address listed in the hints; or (2) changing the operator that is announcing the address. Historically, as has been shown empirically by the long tail of queries to old addresses (1) has been problematic, requiring changes to _millions_ of independently operated recursive resolvers, many of which are likely unmanaged. (2) would require changing network operators and a couple of ROAs. One of these seems _far_ more agile than the other to me.
Lastly I fear for a process concern should a root server operator be deemed as non-performing or unsuitable (whichever way the governance constructs decree) and is to be removed - but the RSO doesn't want to cooperate. Having that RSO in control of a set of "golden identifiers" means a smooth transition is unlikely to be achievable. I would think a smoother approach would be to change the hints file (yes, putting effort into making the hints file more agile across all DNS codebases) and the NS records in the root zone in participation with an incoming RSO.
We have seen how long it takes for changes to DNS codebases to be deployed, even when it is standardized and there is clear need. And there are likely a bunch of security considerations to updating the configuration information for root servers in all the world’s resolvers that would need some careful thought. Ignoring the question of when dealing with non-performing or unsuitable RSOs will be resolved, with the increased deployment of RPKI (now > 50% I hear), the ROA of the root prefix from the non-performing or unsuitable root operator would be marked as invalid by <IANA,one or more RIRs,the Great Spaghetti Monster> and be dropped by folks who have configured their routing filters that way, with the ROA of the new root operator being marked as valid, therefore being accepted. This change would presumably be implemented within hours to days as opposed to years (if ever). Regards, -drc
Hi David, (apologies for the long delay in replying) No doubt that making a set of addresses "golden" + RPKI is an attractive lever to effect rapid change (and might also come with its own pile of risks). I guess my use of agile didn't come across how I anticipated. There is a balance to be struck between "rapid" and globally responsible, trustworthy, transparent, and predicable. I would love to see code, to automagically update the hints files, rolled into DNS codebases ASAP or even better - 10 years ago. (Yes, I acknowledge the lag in getting that across the line.) In the end I would rather see this addressed once the new shiny RSS governance body is established. I also believe that it will take years to convince the incumbent RSOs to switch over to golden addresses (which already has a long tail) or hand the addresses they currently have and use to IANA (in your example). Cheers, Terry
On 10 Oct 2024, at 3:06 AM, David Conrad <david.conrad@layer9.tech> wrote:
Terry,
On Oct 8, 2024, at 5:32 PM, Terry Manderson via rssac-caucus <rssac-caucus@icann.org> wrote:
More deeply I think it further promotes ossification in a system that should be more agile.
If you want “agility” (ignoring “why?"), in the current system, there are two vectors for change: (1) changing the address listed in the hints; or (2) changing the operator that is announcing the address. Historically, as has been shown empirically by the long tail of queries to old addresses (1) has been problematic, requiring changes to _millions_ of independently operated recursive resolvers, many of which are likely unmanaged. (2) would require changing network operators and a couple of ROAs. One of these seems _far_ more agile than the other to me.
Lastly I fear for a process concern should a root server operator be deemed as non-performing or unsuitable (whichever way the governance constructs decree) and is to be removed - but the RSO doesn't want to cooperate. Having that RSO in control of a set of "golden identifiers" means a smooth transition is unlikely to be achievable. I would think a smoother approach would be to change the hints file (yes, putting effort into making the hints file more agile across all DNS codebases) and the NS records in the root zone in participation with an incoming RSO.
We have seen how long it takes for changes to DNS codebases to be deployed, even when it is standardized and there is clear need. And there are likely a bunch of security considerations to updating the configuration information for root servers in all the world’s resolvers that would need some careful thought.
Ignoring the question of when dealing with non-performing or unsuitable RSOs will be resolved, with the increased deployment of RPKI (now > 50% I hear), the ROA of the root prefix from the non-performing or unsuitable root operator would be marked as invalid by <IANA,one or more RIRs,the Great Spaghetti Monster> and be dropped by folks who have configured their routing filters that way, with the ROA of the new root operator being marked as valid, therefore being accepted. This change would presumably be implemented within hours to days as opposed to years (if ever).
Regards, -drc
Hi Terry, Hi all, Quoting Terry Manderson on Wednesday October 09, 2024:
... On the face of it, I see that as a recognition that the method to update the hints files is glacial. More deeply I think it further promotes ossification in a system that should be more agile.
On this, IANA and Verisign have been discussing a modest idea that may help address this. Currently the root hints file has a Last Updated date in the commentary that doesn't necessarily correlate to a change in the underlying data. The idea was to evolve this file to regularly republish the root hints file, similar to the root zone itself but on a lesser cadence, regardless of whether the underlying data has changed. Then in conjuction with that, we rev the publication date, and add an explicit expiry date into the future. This would send a signal for implementers to add some monitoring to make sure their hints file hasn't expired and/or implement a update mechanism rather than treating it as static data. I could see the header of the hints file having a stanza something like this: ; Last-Update: YYYY-MM-DD ; Issued: YYYY-MM-DD ; Expires: YYYY-MM-DD The hints file would get re-issued whenever there is an underlying change to the data, but also on a regular interval (e.g. 1st of the month). Then the expires date would be some period beyond that based on how frequently we'd like implementors to revalidate the data, e.g. ; Issued: 2024-10-01 ; Expires: 2025-03-31 Tooling can kick up warnings or corrective action if it tries to ingest the hints file and sees the current date is beyond the Expires date. The leap second data that IANA publishes has a similar concept of being reissued every 6 months, even though the underlying data hasn't changed since 2017. kim
Thanks Kim, Good to know it is being considered! Terry
On 10 Oct 2024, at 3:31 AM, Kim Davies <kim.davies@iana.org> wrote:
Hi Terry, Hi all,
Quoting Terry Manderson on Wednesday October 09, 2024:
... On the face of it, I see that as a recognition that the method to update the hints files is glacial. More deeply I think it further promotes ossification in a system that should be more agile.
On this, IANA and Verisign have been discussing a modest idea that may help address this. Currently the root hints file has a Last Updated date in the commentary that doesn't necessarily correlate to a change in the underlying data.
The idea was to evolve this file to regularly republish the root hints file, similar to the root zone itself but on a lesser cadence, regardless of whether the underlying data has changed. Then in conjuction with that, we rev the publication date, and add an explicit expiry date into the future. This would send a signal for implementers to add some monitoring to make sure their hints file hasn't expired and/or implement a update mechanism rather than treating it as static data.
I could see the header of the hints file having a stanza something like this:
; Last-Update: YYYY-MM-DD ; Issued: YYYY-MM-DD ; Expires: YYYY-MM-DD
The hints file would get re-issued whenever there is an underlying change to the data, but also on a regular interval (e.g. 1st of the month). Then the expires date would be some period beyond that based on how frequently we'd like implementors to revalidate the data, e.g.
; Issued: 2024-10-01 ; Expires: 2025-03-31
Tooling can kick up warnings or corrective action if it tries to ingest the hints file and sees the current date is beyond the Expires date.
The leap second data that IANA publishes has a similar concept of being reissued every 6 months, even though the underlying data hasn't changed since 2017.
kim
participants (12)
-
Darren Kara -
David Conrad -
Geoff Huston -
George Michaelson -
Joe Abley -
Kazunori Fujiwara -
Kim Davies -
Paul Ebersman -
Paul Hoffman -
Ray Bellis -
Robert Story -
Terry Manderson