You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SRV Resource Records are a standardized way of discovering services through DNS (see RFC2782 for the specification). SRV gives clients a way to ask their DNS resolver for a service/transport protocol combination at some domain, and receive a domain name, port number, load balancing information etc. for this combination. Typical use cases include LDAP, the Session Initiating Protocol (SIP), and the !ZeroConf/Bonjour service discovery protocol. An example (from Wikipedia):
Client asks DNS for the SRV record of _sip._tcp.example.com
DNS tells it to go to bigbox.example.com. at TCP port 5060
Support for this, i.e. delivering answers when asked for an SRV resource record, should not be difficult to add to Zenodotus (or dnscommon.repy).
I also envision another use case where Zenodotus should respect and follow SRV RRs below its own domain name. Consider a DNS resolver running on a Seattle vessel. That resolver cannot listen on port 53 due to the limited port range available to vessels. Thus, a client that wants to use the vessel DNS needs to know the special port, and do the query using other means than gethostbyname_ex(), which basically requires port 53 in order to work. Accordingly, a vessel DNS will not work for browsers, and probably not work for most things not under the control of the researcher.
If on the other hand Zenodotus understands SRV records inside its own domain, it can look up the SRV record for DNS for the subdomain queried by the client, and then recurse to the vessel using the correct (high-numbered) port gathered thus to collect A/quad-A/etc. records as requested. This would open up quite some space for experimentation with load balancing, CDN stuff, etc.
The text was updated successfully, but these errors were encountered:
SRV Resource Records are a standardized way of discovering services through DNS (see RFC2782 for the specification). SRV gives clients a way to ask their DNS resolver for a service/transport protocol combination at some domain, and receive a domain name, port number, load balancing information etc. for this combination. Typical use cases include LDAP, the Session Initiating Protocol (SIP), and the !ZeroConf/Bonjour service discovery protocol. An example (from Wikipedia):
Support for this, i.e. delivering answers when asked for an SRV resource record, should not be difficult to add to Zenodotus (or
dnscommon.repy
).I also envision another use case where Zenodotus should respect and follow SRV RRs below its own domain name. Consider a DNS resolver running on a Seattle vessel. That resolver cannot listen on port 53 due to the limited port range available to vessels. Thus, a client that wants to use the vessel DNS needs to know the special port, and do the query using other means than
gethostbyname_ex()
, which basically requires port 53 in order to work. Accordingly, a vessel DNS will not work for browsers, and probably not work for most things not under the control of the researcher.If on the other hand Zenodotus understands SRV records inside its own domain, it can look up the SRV record for DNS for the subdomain queried by the client, and then recurse to the vessel using the correct (high-numbered) port gathered thus to collect A/quad-A/etc. records as requested. This would open up quite some space for experimentation with load balancing, CDN stuff, etc.
The text was updated successfully, but these errors were encountered: