RFC7701bis and RSSAC001 update proposal: require NSID
There was a discussion during the last call about whether or not RSOs should be required (via RFC7701bis at least) to support and transmit NSID. Currently all the existing RSOs do support NSID and return some value (see below). Since they all do, it seems like an easy jump to put the requirement into RFC7701bis. But there is also a question of what value should be reported; I'd think it should be a fairly simple statement that doesn't prescribe an explicit format, but rather should say something generic like "indicates a unique identifier for a given deployed instance". Thoughts? $ for i in a b c d e f g h i j k l m ; do echo -e -n "$i.root-servers.net:\t" ; dig @$i.root-servers.net . soa +nsid | grep -i nsid: | sed 's/.*//' ; done a.root-servers.net: ("a8.us-lax.root") b.root-servers.net: ("b4-lax") c.root-servers.net: ("lax1a.c.root-servers.org") d.root-servers.net: ("bbca1.droot.maxgigapop.net") e.root-servers.net: ("c01.LAX.eroot") f.root-servers.net: ("LAX.cf.f.root-servers.org") g.root-servers.net: ("sat3.groot") h.root-servers.net: ("001.nzy.h.root-servers.org") i.root-servers.net: ("s1.bnx") j.root-servers.net: ("a8.us-lax.root") k.root-servers.net: ("ns3.us-mia.k.ripe.net") l.root-servers.net: ("us-rtv-aa") m.root-servers.net: ("M-SJC-3") -- Wes Hardaker USC/ISI
On Feb 27, 2023, at 4:56 PM, Wes Hardaker <hardaker@isi.edu> wrote:
There was a discussion during the last call about whether or not RSOs should be required (via RFC7701bis at least) to support and transmit NSID.
Just a note that that is a typo: this is about a -bis version of RFC 7720, not 7701.
Currently all the existing RSOs do support NSID and return some value (see below). Since they all do, it seems like an easy jump to put the requirement into RFC7701bis. But there is also a question of what value should be reported; I'd think it should be a fairly simple statement that doesn't prescribe an explicit format, but rather should say something generic like "indicates a unique identifier for a given deployed instance".
Thoughts?
I agree that <https://datatracker.ietf.org/doc/draft-hardaker-iab-rfc7720-bis/> should include a requirement that all RSOs support correctly responding to queries with the NSID EDNS0 option included. I also agree that there is no significant value to specifying a format, and that there may be a harm in fixing a format that might need to be changed in the future. --Paul Hoffman
On Feb 27, 2023, at 4:56 PM, Wes Hardaker <hardaker@isi.edu> wrote:
There was a discussion during the last call about whether or not RSOs should be required (via RFC7701bis at least) to support and transmit NSID. Currently all the existing RSOs do support NSID and return some value (see below). Since they all do, it seems like an easy jump to put the requirement into RFC7701bis. But there is also a question of what value should be reported; I'd think it should be a fairly simple statement that doesn't prescribe an explicit format, but rather should say something generic like "indicates a unique identifier for a given deployed instance”.
How about this: MUST implement the Name Server Identifier (NSID) Option [RFC 5001] and SHOULD set the NSID payload to a string that conveys the server's geographic location. DW
On Feb 28, 2023, at 5:13 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
How about this:
MUST implement the Name Server Identifier (NSID) Option [RFC 5001] and SHOULD set the NSID payload to a string that conveys the server's geographic location.
This works for me, although I would prefer that this be a MUST. I don't see any logical situation where an RSO is running server software that cannot emit some configured string in an NSID response. --Paul Hoffman
Le 28 févr. 2023 à 20:22, Paul Hoffman <paul.hoffman@icann.org> a écrit :
On Feb 28, 2023, at 5:13 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
How about this:
MUST implement the Name Server Identifier (NSID) Option [RFC 5001] and SHOULD set the NSID payload to a string that conveys the server's geographic location.
Do you see this in RFC7701bis or RSSAC001? (For me, taking the IETF perspective, I’m not sure it is really necessary, so I would say only in RSSAC001) Marc.
This works for me, although I would prefer that this be a MUST. I don't see any logical situation where an RSO is running server software that cannot emit some configured string in an NSID response.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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.
Do you see this in RFC7701bis or RSSAC001? (For me, taking the IETF perspective, I’m not sure it is really necessary, so I would say only in RSSAC001)
It's a technical requirement, so I don't see how it shouldn't be in 7701bis. -- Wes Hardaker USC/ISI
Le 28 févr. 2023 à 22:43, Wes Hardaker <hardaker@isi.edu> a écrit :
Do you see this in RFC7701bis or RSSAC001? (For me, taking the IETF perspective, I’m not sure it is really necessary, so I would say only in RSSAC001)
It's a technical requirement, so I don't see how it shouldn't be in 7701bis.
It could. My point is that there could be all sorts of technical requirements that RSOs may do, but is not “required” from the perspective of IETF. Hence not really needed in RFC7720+. Again, the perspective of 7720 was a high-level minimal requirements from the IETF to RSO, not the whole set of possible requirements that could be implemented by RSOs. At that time, we refrain from going deep into every detail: we could have gone into DNSSEC algorithms, … Again, I’m not against anything, just want to make sure we understand the purpose of RFC7720 and its successors. Marc.
-- Wes Hardaker USC/ISI
It could. My point is that there could be all sorts of technical requirements that RSOs may do, but is not “required” from the perspective of IETF.
I'm confused. The current text proposal puts the support for returning an NSID field as a MUST. Doesn't that make it a requirement? [there is a SHOULD discussion around the contents of the field] -- Wes Hardaker USC/ISI
Le 1 mars 2023 à 09:57, Wes Hardaker <hardaker@isi.edu> a écrit :
It could. My point is that there could be all sorts of technical requirements that RSOs may do, but is not “required” from the perspective of IETF.
I'm confused. The current text proposal puts the support for returning an NSID field as a MUST. Doesn't that make it a requirement?
Well, I guess my comment did not come across very well. First, let me repaste the whole paragraph I wrote, instead of the single sentence you extracted: <paste> "It could. My point is that there could be all sorts of technical requirements that RSOs may do, but is not “required” from the perspective of IETF. Hence not really needed in RFC7720+. Again, the perspective of 7720 was a high-level minimal requirements from the IETF to RSO, not the whole set of possible requirements that could be implemented by RSOs. At that time, we refrain from going deep into every detail: we could have gone into DNSSEC algorithms, … Again, I’m not against anything, just want to make sure we understand the purpose of RFC7720 and its successors.” </paste> The idea of 7720 was so that the IAB/IETF would make sure that the RSO are doing their job to properly serve the DNS, at a high-level, leaving the “details” to the RSOs. And that was clear and agreed by the two parties, and in fact requested by the RSOs, that RSOs will take care of the “details”. Therefore 7720 was a high-level document of requirements. A good example of this, and it was discussed back then, was about saying anything about crypto parameters. To me NSID is in the “details” of RSOs doing their work, not an essential need to “run the DNS Root service”. Quoting RFC7720: - "It specifies basic requirements for the Internet that DNS clients meet when interacting with a root name service over the public Internet.” - "This section describes the minimum high-level protocol requirements.” To me, NSID does not meet this. If we start adding "detailed” requirements such as NSID, then we are opening a can of worms and start a way new different document with all sorts of “detailed” requirements that will be added. That is a very different course and actually not a RFC7720-bis, but just another document. The more requirements are put the more we, the IETF/IAB, are "parenting" RSOs, which was _not_ agreed at least at the time of RFC7720. If RSOs wants to document all their detailed technical/protocol requirements in an IETF document, then fine, start from scratch, and leave RFC7720 as is. However, my suggestion is that instead you put those into the RSSAC001. My 2 cents. Marc.
[there is a SHOULD discussion around the contents of the field]
-- Wes Hardaker USC/ISI
To me, NSID does not meet this.
For me, the requirement for NSID comes from the requirement for a resolver operator to be able to debug their interaction with the RSS, which is very hard without a unique identifier being returned within the NSID field from that operator. Thus a requirement to make the system more fail-safe/debuggable. I do get your point about the split, and applaud it. For me, the RFC should contain technical elements and the RSSAC001 document should contain policy elements. I think the point we're stuck at is "should there be a place to document the 'we want to have X, but it's not a requirement' and if there should be a place/list, where should that place/list go?". Certainly one alternative is to refuse to have a list, or anything related to a SHOULD/MAY type specification leaving only the "if you don't do this, the system won't work at all". But then, it gets even more tricky; EG, is Ipv4 really required by *every* RSO? Are checksums *really* required? And why MUST they be validated? Does the system as a whole fail when these don't apply? The document could be very very short if we only stick to the "do this or it breaks" list. But, you're right it's a slippery slope and somewhere a line needs to be drawn or at least organized into multiple lines. -- Wes Hardaker USC/ISI
This works for me, although I would prefer that this be a MUST. I don't see any logical situation where an RSO is running server software that cannot emit some configured string in an NSID response.
You mean you want a MUST for pointing to a geographical location? I think that's what you're implying but wasn't positive. [I think it should be a SHOULD still, which implies "you really must unless you have some solid reason why not"] -- Wes Hardaker USC/ISI
On 01/03/2023 01:22, Paul Hoffman wrote:
On Feb 28, 2023, at 5:13 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
How about this:
MUST implement the Name Server Identifier (NSID) Option [RFC 5001] and SHOULD set the NSID payload to a string that conveys the server's geographic location.
This works for me, although I would prefer that this be a MUST. I don't see any logical situation where an RSO is running server software that cannot emit some configured string in an NSID response.
All RSOs do currently have -something- in their hostname.bind and NSID data that contains an RSO-specific location code, but it takes quite a long series of regexes to extract them. However those codes do not necessarily conform to any recognised standard, so this potentially opens up a can of worms on what constitutes "a string that conveys the server's geographic location". Ray
On 1 Mar 2023, at 11:11, Ray Bellis <ray@isc.org> wrote:
On 01/03/2023 01:22, Paul Hoffman wrote:
On Feb 28, 2023, at 5:13 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
How about this: MUST implement the Name Server Identifier (NSID) Option [RFC 5001] and SHOULD set the NSID payload to a string that conveys the server's geographic location. This works for me, although I would prefer that this be a MUST. I don't see any logical situation where an RSO is running server software that cannot emit some configured string in an NSID response.
All RSOs do currently have -something- in their hostname.bind and NSID data that contains an RSO-specific location code, but it takes quite a long series of regexes to extract them.
However those codes do not necessarily conform to any recognised standard, so this potentially opens up a can of worms on what constitutes "a string that conveys the server's geographic location”.
As long as someone can figure out the syntax themselves I don’t think there needs to be an agreed upon syntax. A while back I helped a researcher who wrote to ask-rssac@icann.org <mailto:ask-rssac@icann.org> with trying to figure out which instance they were getting queries from and we ended up just writing the RSO and asking them. That process doesn’t scale well. There’s a top-level top-level key to the JSON data called “Identifier Naming Convention”. Some RSIs fill this in and some don’t. <https://root-servers.org/root/B/json/> There’s also RFC 7108 to be aware of. <https://www.rfc-editor.org/rfc/rfc7108> Thanks, Andrew
Greetings again. There was a long thread here about adding a MUST-level or SHOULD-level requirement to the update to BCP40 (RFC 7720) for RSOs providing unique NSID identifiers for each instance. (The draft is at <https://datatracker.ietf.org/doc/draft-hardaker-iab-rfc7720-bis/>; the repo for the draft is at <https://github.com/marcblanchet/rfc7720bis>). In the repo, I suggested a new section be added for "Protocol Recommendations", to differentiate from "Protocol Requirements" and "Deployment Requirements" because I think that the unique NSID does not need to be a "MUST". It is useful for debugging, but if an RSO messes up and uses duplicate IDs, or somehow forgets to turn NSID on for some instances, the root server system will not be significantly harmed. In that spirit, I propose the following for a new "Protocol Recommendations" section: - SHOULD respond to queries that include an NSID [RFC5001] EDNS(0) option with an identifier that is unique for each instance. At the time this document is published, each root server operator deploys multiple instances, so the instance identifier for the NSID response SHOULD include a sub-string that identifies the root server operator. The identifier is only useful for debugging and does not necessarily indicate any attribute of the instance that is responding. The wording here is a bit stilted because BCP40 does not yet define "instance", does not yet talk about anycast, and doesn't even really define "root server operator". If those are addressed before the document is finalized, the above wording can change as well. Thoughts? --Paul Hoffman
In that spirit, I propose the following for a new "Protocol Recommendations" section:
I think that text looks generally good, thanks for suggesting it. We still do need to have a debate about whether the document should even have recommendations at all, as there isn't a consensus type call on that yet and there has been disagreement. [I assume cookie support would also go into the recommendation section] -- Wes Hardaker USC/ISI
On Mar 18, 2023, at 5:56 AM, Wes Hardaker <hardaker@isi.edu> wrote:
We still do need to have a debate about whether the document should even have recommendations at all, as there isn't a consensus type call on that yet and there has been disagreement.
This will certainly involve bikeshedding what is meant by "best current practice", but such a discussion is probably needed.
[I assume cookie support would also go into the recommendation section]
I hadn't gotten there, but yes, definitely. I have not come up with any others at this point. --Paul Hoffman
On Mar 17, 2023, at 3:13 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings again. There was a long thread here about adding a MUST-level or SHOULD-level requirement to the update to BCP40 (RFC 7720) for RSOs providing unique NSID identifiers for each instance. (The draft is at <https://datatracker.ietf.org/doc/draft-hardaker-iab-rfc7720-bis/>; the repo for the draft is at <https://github.com/marcblanchet/rfc7720bis>).
In the repo, I suggested a new section be added for "Protocol Recommendations", to differentiate from "Protocol Requirements" and "Deployment Requirements" because I think that the unique NSID does not need to be a "MUST". It is useful for debugging, but if an RSO messes up and uses duplicate IDs, or somehow forgets to turn NSID on for some instances, the root server system will not be significantly harmed.
In that spirit, I propose the following for a new "Protocol Recommendations" section:
- SHOULD respond to queries that include an NSID [RFC5001] EDNS(0) option with an identifier that is unique for each instance. At the time this document is published, each root server operator deploys multiple instances, so the instance identifier for the NSID response SHOULD include a sub-string that identifies the root server operator. The identifier is only useful for debugging and does not necessarily indicate any attribute of the instance that is responding.
The wording here is a bit stilted because BCP40 does not yet define "instance", does not yet talk about anycast, and doesn't even really define "root server operator". If those are addressed before the document is finalized, the above wording can change as well.
Thoughts?
IMO we should probably avoid “instance” here, and maybe “unique” as well. It will lead to a discussion of instance vs site vs server that won’t be fruitful. In my proposed text I was careful to avoid that. I find the second sentence (“At this time…include a sub-string”) somewhat confusing. Generally I think “at this time” comments aren’t really relevant. The RFC should just say what the recommendations are. But I also don’t see what RSOs having multiple instances has to do with the sub-string, and I think you mean root server identity there instead of RSO? What goes into the NSID payload is less of a protocol recommendation, and more of a policy recommendation/expectation. DW
I find the second sentence (“At this time…include a sub-string”) somewhat confusing. Generally I think “at this time” comments aren’t really relevant.
Thanks, I meant to respond about that too. IMHO, all history should go into the history appendix and the main text should be specific to the recommendations/requirements. Wes Hardaker USC/ISI
On Mar 20, 2023, at 1:43 PM, Wessels, Duane <dwessels@verisign.com> wrote:
- SHOULD respond to queries that include an NSID [RFC5001] EDNS(0) option with an identifier that is unique for each instance. At the time this document is published, each root server operator deploys multiple instances, so the instance identifier for the NSID response SHOULD include a sub-string that identifies the root server operator. The identifier is only useful for debugging and does not necessarily indicate any attribute of the instance that is responding.
The wording here is a bit stilted because BCP40 does not yet define "instance", does not yet talk about anycast, and doesn't even really define "root server operator". If those are addressed before the document is finalized, the above wording can change as well.
Thoughts?
IMO we should probably avoid “instance” here, and maybe “unique” as well. It will lead to a discussion of instance vs site vs server that won’t be fruitful. In my proposed text I was careful to avoid that.
Your proposal was: MUST implement the Name Server Identifier (NSID) Option [RFC 5001] and SHOULD set the NSID payload to a string that conveys the server's geographic location. I used "instance" because "server's" is not clear because the base document uses "server" to mean either the RSO or (apparently) the hardware. I suspect this is because in 2015 not all the RSOs were using anycast. I also find "conveys the server's geographic location" as over-specific. I have heard that some RSOs don't like doing this, and I certainly know that there are sometimes errors when they do.
I find the second sentence (“At this time…include a sub-string”) somewhat confusing. Generally I think “at this time” comments aren’t really relevant. The RFC should just say what the recommendations are.
I thought it was relevant because 7720 didn't acknowledge anycast, and the use of NSIDs is only relevant because of anycast.
But I also don’t see what RSOs having multiple instances has to do with the sub-string, and I think you mean root server identity there instead of RSO?
It would help the person holding the NSID. I can easily imagine two RSOs having the same identifier such as "LAX-1".
What goes into the NSID payload is less of a protocol recommendation, and more of a policy recommendation/expectation.
It falls into the category of Deployment Requirement. I'm fine with having different wording that somehow indicates that each "server" (hardware) have a different NSID, but I think that requires rewriting the top of the document as well. It sounds like we should do that. --Paul Hoffman
On Mon 2023-03-20 21:22:59+0000 Paul wrote:
But I also don’t see what RSOs having multiple instances has to do with the sub-string, and I think you mean root server identity there instead of RSO?
It would help the person holding the NSID. I can easily imagine two RSOs having the same identifier such as "LAX-1".
I don't think you're going to get agreement on NSIDs being completely unique amongst all RSOs. And you shouldn't need the identity of the RSO in the NSID because you know the RSO you sent the query to... Regards, Robert -- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
On Mar 20, 2023, at 2:42 PM, Robert Story <rstory@ant.isi.edu> wrote:
On Mon 2023-03-20 21:22:59+0000 Paul wrote:
But I also don’t see what RSOs having multiple instances has to do with the sub-string, and I think you mean root server identity there instead of RSO?
It would help the person holding the NSID. I can easily imagine two RSOs having the same identifier such as "LAX-1".
I don't think you're going to get agreement on NSIDs being completely unique amongst all RSOs.
If the string starts with the RSI's letter, and the RSO tries to make each instance have a unique identifier, this would make the NSIDs unique among the RSOs.
And you shouldn't need the identity of the RSO in the NSID because you know the RSO you sent the query to...
True. If identifying yourself with your RSI letter is onerous, we can drop the second sentence. --Paul Hoffman
On 20/03/2023 22:50, Paul Hoffman wrote:
If identifying yourself with your RSI letter is onerous, we can drop the second sentence.
I doubt it's particularly onerous for the RSOs themselves, but there are existing consumers of NSID / hostname.bind who would need to update their systems if those values change format. Ray
participants (7)
-
Andrew McConachie -
Marc Blanchet -
Paul Hoffman -
Ray Bellis -
Robert Story -
Wes Hardaker -
Wessels, Duane