3 ms·

No, not saying that. As I’m sure you know, WHOIS and RDAP are about domain registrant data supplied by registrars and registries. We didn’t do this in RDAP be

No, not saying that. As I’m sure you know, WHOIS and RDAP are about domain registrant data supplied by registrars and registries. We didn’t do this in RDAP because: a) we’re not a registrar or registry; b) RDAP has strict limits designed specifically to prevent exactly what we’re trying to enable - unlimited and unrestricted access to data for developers; c) NUM is much broader than just contact data

cookiengineer 5y ago
> unlimited and unrestricted access to data for developers I'm not sure what you're trying to argument with here. Why is RDAP limited if anybody can just use a client and any server on the internet that fulfills the same spec? [1] The argument works both ways, because as of now, your solution is literally "n (servers) = 1", therefore it's the maximum restricted access possible. Arguing that an IETF- and ICANN-backed RFC is limited and restricted; whereas you are using a proprietary NUM protocol on top of DNS, an RFC by the IETF, is ridiculous. Don't you realize that you're trying to push a proprietary protocol here? RDAP is an IETF-RFC, so I'd argue that adoption is much more likely; as it is also backed by ICANN, RIPE and all internet registries. You're just using DNS as a generic database here, and I'd argue that the DNS protocol wasn't designed for the purpose that the NUM protocol seems to have as its goals; given the overhead of schema validation that each client has to do for themselves. [2] > NUM is much broader than just contact data RDAP supports different schemas for entries, objects and models; just as any other database. Add a new rtype="whatever" and define its properties, and you're set to go. Honestly in times of GraphQL making predictable queries as easy and as built-in as possible; the NUM protocol feels like a huge setback in terms of transport encryption, integrity, predictability of state complexity and confidentiality. [1] https://datatracker.ietf.org/doc/html/rfc7482 https://datatracker.ietf.org/doc/html/rfc7482 [2] https://www.numprotocol.com/specification https://www.numprotocol.com/specification
- elliottinvent 5y ago
  Thanks for the detailed technical feedback, it's why I'm here. > Why is RDAP limited if anybody can just use a client and any server on the internet that fulfils the same spec? RDAP as a technology and RFC isn't limited or restricted of course, just like restful APIs as a technology are not limited. However, the implementation of the technology is limited. The servers offered by registrars and registries will be limited and the access and use of data restricted. We promote NUM as unlimited and unrestricted because NUM records (whether in authoritative nameservers or under num.net) are hosted in DNS and requests can not easily be tracked or rate limited. > I'd argue that the DNS protocol wasn't designed for the purpose that the NUM protocol seems to have as its goals I disagree, we're using vanilla DNS TXT records which have existed in DNS since '94 [1]: "This paper proposes the use of the DNS TXT resource record [...] to contain new types of information." Most NUM Records can be transported over UDP, even under the original 512b limit. A NUM record containing let's say 20 typical key value pairs is smaller than a DNSSECd A record and smaller than millions of DNS TXT records at a domain apex (dig target.com TXT). > given the overhead of schema validation that each client has to do for themselves Validation is minimal and is dealt with at a library level, as it will be with RDAP or any other API. The fact that mainstream data serialisation formats (e.g. JSON, YAML, etc) are not designed for DNS, does not mean that DNS is not designed to store serialised data. We created MODL [2] to solve this problem. To demonstrate low overhead, we have a heavy example implementation that fetches 62 NUM records, validates them and displays them in 1.6 seconds [2]. > Honestly in times of GraphQL making predictable queries as easy and as built-in as possible... This data is already centralised in graphs by Facebook, Google and more. There was an effort to decentralise it with the Semantic Web. We're offering an alternative to both, where users can retain their privacy, developers can actually build scalable, profitable products (as opposed to using Google / Facebook APIs) and the data is actually available (as opposed to SemWeb). > ... the NUM protocol feels like a huge setback in terms of transport encryption, integrity, predictability of state complexity and confidentiality. These seem like complaints about DNS which are addressed by DNSSEC, DNS over TLS (DOT), DNS over HTTPS (DOH), DPRIVE and Oblivious DNS-over-HTTPS (ODOH). Thanks again for your thoughts, happy to dive deeper into any of this. 1. https://datatracker.ietf.org/doc/html/rfc1464 https://datatracker.ietf.org/doc/html/rfc1464 2. https://companydirectory.uk/barclays.co.uk/contact-information https://companydirectory.uk/barclays.co.uk/contact-informati... 3. https://www.modl.uk https://www.modl.uk
- elliottinvent 5y ago
  Ah, I might have misunderstood your previous comment about RDAP - I thought you were asking why we didn’t fetch this data from registrar RDAP implementations, so my answer was in response to that. You may have been suggesting that we serve out our data from num.net using RDAP instead of DNS. In answer to that: NUM is a DNS-based protocol because every online organisation has access to DNS - it’s a standardised way for them to store and serve out data, they’ve already got it and already pay for it.

cookiengineer 5y ago

> unlimited and unrestricted access to data for developers I'm not sure what you're trying to argument with here. Why is RDAP limited if anybody can just use a client and any server on the internet that fulfills the same spec? [1] The argument works both ways, because as of now, your solution is literally "n (servers) = 1", therefore it's the maximum restricted access possible. Arguing that an IETF- and ICANN-backed RFC is limited and restricted; whereas you are using a proprietary NUM protocol on top of DNS, an RFC by the IETF, is ridiculous. Don't you realize that you're trying to push a proprietary protocol here? RDAP is an IETF-RFC, so I'd argue that adoption is much more likely; as it is also backed by ICANN, RIPE and all internet registries. You're just using DNS as a generic database here, and I'd argue that the DNS protocol wasn't designed for the purpose that the NUM protocol seems to have as its goals; given the overhead of schema validation that each client has to do for themselves. [2] > NUM is much broader than just contact data RDAP supports different schemas for entries, objects and models; just as any other database. Add a new rtype="whatever" and define its properties, and you're set to go. Honestly in times of GraphQL making predictable queries as easy and as built-in as possible; the NUM protocol feels like a huge setback in terms of transport encryption, integrity, predictability of state complexity and confidentiality. [1] https://datatracker.ietf.org/doc/html/rfc7482 https://datatracker.ietf.org/doc/html/rfc7482 [2] https://www.numprotocol.com/specification https://www.numprotocol.com/specification

elliottinvent 5y ago
Thanks for the detailed technical feedback, it's why I'm here. > Why is RDAP limited if anybody can just use a client and any server on the internet that fulfils the same spec? RDAP as a technology and RFC isn't limited or restricted of course, just like restful APIs as a technology are not limited. However, the implementation of the technology is limited. The servers offered by registrars and registries will be limited and the access and use of data restricted. We promote NUM as unlimited and unrestricted because NUM records (whether in authoritative nameservers or under num.net) are hosted in DNS and requests can not easily be tracked or rate limited. > I'd argue that the DNS protocol wasn't designed for the purpose that the NUM protocol seems to have as its goals I disagree, we're using vanilla DNS TXT records which have existed in DNS since '94 [1]: "This paper proposes the use of the DNS TXT resource record [...] to contain new types of information." Most NUM Records can be transported over UDP, even under the original 512b limit. A NUM record containing let's say 20 typical key value pairs is smaller than a DNSSECd A record and smaller than millions of DNS TXT records at a domain apex (dig target.com TXT). > given the overhead of schema validation that each client has to do for themselves Validation is minimal and is dealt with at a library level, as it will be with RDAP or any other API. The fact that mainstream data serialisation formats (e.g. JSON, YAML, etc) are not designed for DNS, does not mean that DNS is not designed to store serialised data. We created MODL [2] to solve this problem. To demonstrate low overhead, we have a heavy example implementation that fetches 62 NUM records, validates them and displays them in 1.6 seconds [2]. > Honestly in times of GraphQL making predictable queries as easy and as built-in as possible... This data is already centralised in graphs by Facebook, Google and more. There was an effort to decentralise it with the Semantic Web. We're offering an alternative to both, where users can retain their privacy, developers can actually build scalable, profitable products (as opposed to using Google / Facebook APIs) and the data is actually available (as opposed to SemWeb). > ... the NUM protocol feels like a huge setback in terms of transport encryption, integrity, predictability of state complexity and confidentiality. These seem like complaints about DNS which are addressed by DNSSEC, DNS over TLS (DOT), DNS over HTTPS (DOH), DPRIVE and Oblivious DNS-over-HTTPS (ODOH). Thanks again for your thoughts, happy to dive deeper into any of this. 1. https://datatracker.ietf.org/doc/html/rfc1464 https://datatracker.ietf.org/doc/html/rfc1464 2. https://companydirectory.uk/barclays.co.uk/contact-information https://companydirectory.uk/barclays.co.uk/contact-informati... 3. https://www.modl.uk https://www.modl.uk
elliottinvent 5y ago
Ah, I might have misunderstood your previous comment about RDAP - I thought you were asking why we didn’t fetch this data from registrar RDAP implementations, so my answer was in response to that. You may have been suggesting that we serve out our data from num.net using RDAP instead of DNS. In answer to that: NUM is a DNS-based protocol because every online organisation has access to DNS - it’s a standardised way for them to store and serve out data, they’ve already got it and already pay for it.