Internet Assigned Numbers Authority

Service Name and Transport Protocol Port Number Registry

Last Updated
2024-04-30
Expert(s)
TCP/UDP: Joe Touch; Eliot Lear, Kumiko Ono, Wes Eddy, Brian Trammell, 
Jana Iyengar, and Michael Scharf
SCTP: Michael Tuexen
DCCP: Eddie Kohler and Yoshifumi Nishida
Reference
[RFC6335]
Note
Service names and port numbers are used to distinguish between different
services that run over transport protocols such as TCP, UDP, DCCP, and
SCTP.

Service names are assigned on a first-come, first-served process, as
documented in [RFC6335].

Port numbers are assigned in various ways, based on three ranges: System
Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
Ports (49152-65535); the different uses of these ranges are described in
[RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are 
assigned by the "IETF Review" or "IESG Approval" procedures described in 
[RFC8126]. User Ports are assigned by IANA using the "IETF Review" process, 
the "IESG Approval" process, or the "Expert Review" process, as per 
[RFC6335]. Dynamic Ports are not assigned.

The registration procedures for service names and port numbers are
described in [RFC6335].

Assigned ports both System and User ports SHOULD NOT be used without
or prior to IANA registration.

************************************************************************
* PLEASE NOTE THE FOLLOWING:                                           *
*                                                                      *
* ASSIGNMENT OF A PORT NUMBER DOES NOT IN ANY WAY IMPLY AN             *
* ENDORSEMENT OF AN APPLICATION OR PRODUCT, AND THE FACT THAT NETWORK  *
* TRAFFIC IS FLOWING TO OR FROM A REGISTERED PORT DOES NOT MEAN THAT   *
* IT IS "GOOD" TRAFFIC, NOR THAT IT NECESSARILY CORRESPONDS TO THE     *
* ASSIGNED SERVICE. FIREWALL AND SYSTEM ADMINISTRATORS SHOULD          *
* CHOOSE HOW TO CONFIGURE THEIR SYSTEMS BASED ON THEIR KNOWLEDGE OF    *
* THE TRAFFIC IN QUESTION, NOT WHETHER THERE IS A PORT NUMBER          *
* REGISTERED OR NOT.                                                   *
************************************************************************

Request an Assignment
  [https://www.iana.org/protocols/apply]

Available Formats

CSV

XML

HTML

Plain text
Service Name Port Number Transport Protocol Description Assignee Contact Registration Date Modification Date Reference Service Code Unauthorized Use Reported Assignment Notes
www-http 80 tcp World Wide Web HTTP [Tim_Berners_Lee] [Tim_Berners_Lee] This is a duplicate of the "http" service and should not be used for discovery purposes. u=<username> p=<password> path=<path to document> (see txtrecords.html#http) Known Subtypes: _printer NOTE: The meaning of this service type, though called just "http", actually denotes something more precise than just "any data transported using HTTP". The DNS-SD service type "http" should only be used to advertise content that: * is served over HTTP, * can be displayed by "typical" web browser client software, and * is intented primarily to be viewed by a human user. Of course, the definition of "typical web browser" is subjective, and may change over time, but for practical purposes the DNS-SD service type "http" can be understood as meaning "human-readable HTML content served over HTTP". In some cases other widely-supported content types may also be appropriate, such as plain text over HTTP, or JPEG image over HTTP. Content types not intented primarily for viewing by a human user, or not widely-supported in web browsing clients, should not be advertised as DNS-SD service type "http", even if they do happen to be transported over HTTP. Such types should be advertised as their own logical service type with their own DNS-SD service type, for example, XUL (XML User Interface Language) transported over HTTP is advertised explicitly as DNS-SD service type "xul-http".
www-http 80 udp World Wide Web HTTP [Tim_Berners_Lee] [Tim_Berners_Lee] This is a duplicate of the "http" service and should not be used for discovery purposes. u=<username> p=<password> path=<path to document> (see txtrecords.html#http) Known Subtypes: _printer NOTE: The meaning of this service type, though called just "http", actually denotes something more precise than just "any data transported using HTTP". The DNS-SD service type "http" should only be used to advertise content that: * is served over HTTP, * can be displayed by "typical" web browser client software, and * is intented primarily to be viewed by a human user. Of course, the definition of "typical web browser" is subjective, and may change over time, but for practical purposes the DNS-SD service type "http" can be understood as meaning "human-readable HTML content served over HTTP". In some cases other widely-supported content types may also be appropriate, such as plain text over HTTP, or JPEG image over HTTP. Content types not intented primarily for viewing by a human user, or not widely-supported in web browsing clients, should not be advertised as DNS-SD service type "http", even if they do happen to be transported over HTTP. Such types should be advertised as their own logical service type with their own DNS-SD service type, for example, XUL (XML User Interface Language) transported over HTTP is advertised explicitly as DNS-SD service type "xul-http".
dnsix 90 tcp DNSIX Securit Attribute Token Map [Charles_Watt] [Charles_Watt] PORT 90 also being used unofficially by Pointcast
dnsix 90 udp DNSIX Securit Attribute Token Map [Charles_Watt] [Charles_Watt] PORT 90 also being used unofficially by Pointcast
dn6-nlm-aud 195 tcp DNSIX Network Level Module Audit
dn6-nlm-aud 195 udp DNSIX Network Level Module Audit
dn6-smm-red 196 tcp DNSIX Session Mgt Module Audit Redir [Lawrence_Lebahn] [Lawrence_Lebahn]
dn6-smm-red 196 udp DNSIX Session Mgt Module Audit Redir [Lawrence_Lebahn] [Lawrence_Lebahn]
sdnskmp 558 tcp SDNSKMP
sdnskmp 558 udp SDNSKMP
domain-s 853 tcp DNS query-response protocol run over TLS [IESG] [IETF_Chair] 2015-10-08 2022-04-11 [RFC7858]
domain-s 853 udp DNS query-response protocol run over DTLS or QUIC [IESG] [IETF_Chair] 2015-10-08 2022-04-01 [RFC7858][RFC8094][RFC9250]
ddt 1052 tcp Dynamic DNS Tools [Remi_Lefebvre] [Remi_Lefebvre]
ddt 1052 udp Dynamic DNS Tools [Remi_Lefebvre] [Remi_Lefebvre]
dns2go 1227 tcp DNS2Go [Deerfield_Communications_Inc] [Mike_Courterier] 2015-07-15
dns2go 1227 udp DNS2Go [Deerfield_Communications_Inc] [Mike_Courterier] 2015-07-15
menandmice-dns 1337 tcp menandmice DNS [Sigfus_Magnusson] [Sigfus_Magnusson]
menandmice-dns 1337 udp menandmice DNS [Sigfus_Magnusson] [Sigfus_Magnusson]
sunscalar-dns 1870 tcp SunSCALAR DNS Service [Sanjay_Radia] [Sanjay_Radia]
sunscalar-dns 1870 udp SunSCALAR DNS Service [Sanjay_Radia] [Sanjay_Radia]
ddns-v3 2164 tcp Dynamic DNS Version 3 [Alan_Yates] [Alan_Yates]
ddns-v3 2164 udp Dynamic DNS Version 3 [Alan_Yates] [Alan_Yates]
spw-dnspreload 3849 tcp SPACEWAY DNS Preload [Daniel_Friedman] [Daniel_Friedman] 2003-08
spw-dnspreload 3849 udp SPACEWAY DNS Preload [Daniel_Friedman] [Daniel_Friedman] 2003-08
dns-llq 5352 tcp DNS Long-Lived Queries [Stuart_Cheshire] [Stuart_Cheshire] 2005-08 2019-08-26 [RFC8764]
dns-llq 5352 udp DNS Long-Lived Queries [Stuart_Cheshire] [Stuart_Cheshire] 2005-08 2019-08-26 [RFC8764]
mdns 5353 tcp Multicast DNS [IESG] [IETF_Chair] [RFC6762]
mdns 5353 udp Multicast DNS [IESG] [IETF_Chair] [RFC6762]
mdnsresponder 5354 tcp Multicast DNS Responder IPC [Stuart_Cheshire_3] [Stuart_Cheshire_3] 2004-06
mdnsresponder 5354 udp Multicast DNS Responder IPC [Stuart_Cheshire_3] [Stuart_Cheshire_3] 2004-06
ub-dns-control 8953 tcp unbound dns nameserver control [NLnet_Labs_Support] [NLnet_Labs_Support] 2011-05-10 2011-07-11
pdl-datastream 9100 tcp Printer PDL Data Stream [Stuart_Cheshire_4] [Stuart_Cheshire_4] 2002-09 The protocol name "pdl-datastream" is primarily registered for use in DNS SRV records (RFC 2782). DNS SRV records allow a protocol to run on any port number, but the default port for this protocol is 9100.
pdl-datastream 9100 udp Printer PDL Data Stream [Stuart_Cheshire_4] [Stuart_Cheshire_4] 2002-09 The protocol name "pdl-datastream" is primarily registered for use in DNS SRV records (RFC 2782). DNS SRV records allow a protocol to run on any port number, but the default port for this protocol is 9100.
odnsp 9966 tcp OKI Data Network Setting Protocol [Masato_Sato] [Masato_Sato] 2006-05
odnsp 9966 udp OKI Data Network Setting Protocol [Masato_Sato] [Masato_Sato] 2006-05
conecube udp DNS SRV service for smarthome server [cone_smart_solution] [Christoph_Bimminger] 2019-04-22 Defined TXT keys: none
device-info Device Info [Stuart_Cheshire][Marc_Krochmal] [Stuart_Cheshire][Marc_Krochmal] Not a service type. Special name reserved for DNS-SD device info.
dns-llq-tls tcp DNS Long-Lived Queries over TLS [Stuart_Cheshire] [Stuart_Cheshire] 2019-05-04 [RFC6281] Defined TXT Keys: None
dns-push-tls tcp DNS Push Notification Service Type [IESG] [IETF_Chair] 2019-11-25 [RFC8765, Section 6.1] Defined TXT Keys: None
dns-query-tls tcp DNS queries to the authoritative server over TLS [Stuart_Cheshire] [Stuart_Cheshire] 2019-05-04 Defined TXT Keys: None
dns-sd DNS Service Discovery [Stuart_Cheshire][Marc_Krochmal] [Stuart_Cheshire][Marc_Krochmal] Not a service type. Special name reserved for DNS-SD meta queries.
dns-update tcp DNS Dynamic Update Service [Stuart_Cheshire] [Stuart_Cheshire] 2019-05-04 DNS Dynamic Update Service for a given domain may not necessarily be provided by the principal name servers as advertised by the domain's "NS" records, and may not necessarily always be provided on port 53. The "_dns-update._udp.<domain>." SRV record gives the target host and port where DNS Dynamic Update Service is provided for the named domain.
dns-update udp DNS Dynamic Update Service [Stuart_Cheshire] [Stuart_Cheshire] 2019-05-04 DNS Dynamic Update Service for a given domain may not necessarily be provided by the principal name servers as advertised by the domain's "NS" records, and may not necessarily always be provided on port 53. The "_dns-update._udp.<domain>." SRV record gives the target host and port where DNS Dynamic Update Service is provided for the named domain.
dns-update-tls tcp DNS Dynamic Update Service over TLS [Stuart_Cheshire] [Stuart_Cheshire] 2019-05-04 [RFC6281] DNS Dynamic Update Service for a given domain may not necessarily be provided by the principal name servers as advertised by the domain's "NS" records, and may not necessarily always be provided on port 53. The "_dns-update._udp.<domain>." SRV record gives the target host and port where DNS Dynamic Update Service is provided for the named domain.
dnssd-srp tcp DNS-SD Service Registration [IESG] [IETF_Chair] 2024-04-12 [RFC-ietf-dnssd-srp-25] Defined TXT keys: None
dnssd-srp-tls tcp DNS-SD Service Registration (TLS) [IESG] [IETF_Chair] 2024-04-12 [RFC-ietf-dnssd-srp-25] Defined TXT keys: None
ep Endpoint Protocol (EP) for use in Home Automation systems [Tommy_van_der_Vorst] [Tommy_van_der_Vorst] Defined TXT keys: dns-sd_mdns
eucalyptus Eucalyptus Discovery [Support_Team] [Support_Team] Defined TXT keys: Eucalyptus-DNS-SD
guid Special service type for resolving by GUID (Globally Unique Identifier) Defined TXT keys: Varies; Depends on type of service being offered/resolved Although DNS-SD does not recommend or advocate using GUIDs as the primary name of an offered service why not?, it does support use of GUIDs as service names where developers want to use them that way. Typically users do not browse for GUIDs. They are not user-friendly and not very informative. Typically, the service is advertised as usual, using a user-friendly name. One of the TXT record attributes is a GUID for the service instance. Once the user has browsed and chosen the desired service instance via its user-friendly name, the service is resolved, the TXT record is retrieved, and the GUID is stored. A given network service instance is therefore being advertised two ways, for example: <User-Friendly-Name>._ptp._tcp.local <GUID>._guid._tcp.local On subsequent accesses to the service, the GUID-based name is resolved, and that particular service instance is discovered, even if the user has subsequently changed the user-friendly name to something else. Note: Although each different logical service type needs to have its own different DNS-SD service type, all GUID-based names use the same pseudo-type: "_guid._tcp". There is no possibility of name conflict because (by definition) GUIDs are globally unique.
https tcp HTTP over SSL/TLS [Tim_Berners_Lee] [Tim_Berners_Lee] Web browsers like Safari and Internet Explorer (with the Bonjour for Windows plugin) DO NOT browse for DNS-SD service type "_https._tcp" in addition to browsing for "_http._tcp". This is a conscious decision to reduce proliferation of service types, to help keep DNS-SD efficient on the network. Today, if a user types http://www.mybank.com/ into their web browser, the web server automatically redirects the user to https://www.mybank.com/. Rather than having an entirely different DNS-SD service type for https, we recommend using the same redirection mechanism: advertise a plain "http" service, which consists of nothing except an HTTP redirection to the desired "https" URL. Work is currently being done on adding mechanisms to HTTP and TLS to allow the server to tell the client that it needs to activate TLS on the current connection before proceeding. If this becomes widely adopted, it further justifies the decision to not create a separate DNS-SD service type "_https._tcp", because security becomes just another one of the things that is negotiated on a per-connection basis (like content-type negotiation today) rather than being an entirely separate thing.
nasunifiler tcp This DNS-SD service is used by mobile clients to locate the Nasuni Filer (a storage product) for a given company. [Nasuni_Corporation] [David_Shaw-Nasuni] 2016-01-22 Defined TXT keys: companyfullname == The name of the company hosting the Nasuni Filer
presence Peer-to-peer messaging / Link-Local Messaging [XMPP_Registrar] [XMPP_Registrar] Defined TXT keys: See http://www.xmpp.org/registrar/linklocal.html Note: Registration updated May 2007. Was formerly listed as "iChat AV" (Apple's IM client for Mac OS X) with TXT keys: txtvers, port.p2pj, phsh, vc, 1st, AIM, msg, status, last When first shipped in Mac OS X 10.2, iChat's peer-to-peer messaging protocol was created to solve the problem of serverless messaging between peers on the same link. However, there is nothing inherent in the protocol that limits it to being only link-local; it was simply an artifact of iChat in Mac OS X 10.2 using link-local Multicast DNS to discover peers. With the advent of Wide-Area DNS-SD, it is also possible to use iChat's peer-to-peer messaging between machines on different links.
recipe-sharing tcp Recipe Sharing Protocol [Daniel_G_Taylor] [Daniel_G_Taylor] 2007-11 Defined TXT keys: [http://www.recipemanager.org/rsp/rsp10draft.html#dnssd]
rfbc Remote Frame Buffer Client (Used by VNC viewers in listen-mode) [Ole_Morten_Duesund] [Ole_Morten_Duesund] Defined TXT keys: server=dns-name/ip-address:port of currently displayed VNC server. Empty if not showing anything/available.
services DNS Service Discovery [Stuart_Cheshire][Marc_Krochmal] [Stuart_Cheshire][Marc_Krochmal] Not a service type. Special name reserved for DNS-SD meta queries.
split-dns64 tcp DNS64 in split configuration [Kasper_Dupont] [Kasper_Dupont] 2021-10-19 Defined TXT keys: None
voalte2 tcp Server location via DNS-SD [Voalte_Inc] [John_Simpson] 2019-01-22 Defined TXT keys: txtvers, name, (others not publicly documented)
voalte3 tcp Server location via DNS-SD [Voalte_Inc] [John_Simpson] 2019-01-22 Defined TXT keys: txtvers, name, (others not publicly documented)

Contact Information

ID Name Organization Contact URI Last Updated
[Alan_Yates] Alan Yates mailto:alany&ay.com.au
[Charles_Watt] Charles Watt mailto:watt&sware.com
[Christoph_Bimminger] Christoph Bimminger cone smart solution mailto:christoph.bimminger&cone.at 2019-04-22
[cone_smart_solution] cone smart solution mailto:office&cone.at 2019-04-22
[Daniel_Friedman] Daniel Friedman mailto:dfriedman&hns.com 2003-08
[Daniel_G_Taylor] Daniel G. Taylor mailto:dan&programmer-art.org 2007-11
[David_Shaw-Nasuni] David Shaw mailto:dshaw&nasuni.com 2016-01-22
[Deerfield_Communications_Inc] Deerfield Communications Inc. mailto:mikec&deerfield.net 2015-07-15
[IESG] IESG mailto:iesg&ietf.org
[IETF_Chair] IETF Chair IETF mailto:chair&ietf.org
[John_Simpson] John Simpson Voalte, Inc. mailto:jms1&voalte.com 2019-01-22
[Kasper_Dupont] Kasper Dupont mailto:kasperd&xwhfx.16.oct.2021.kasperd.dk 2021-10-19
[Lawrence_Lebahn] Lawrence Lebahn mailto:DIA3&paxrv-nes.navy.mil
[Marc_Krochmal] Marc Krochmal mailto:marc&apple.com
[Masato_Sato] Masato Sato mailto:satou203&oki.com 2006-05
[Mike_Courterier] Mike Courterier Deerfield Communications Inc. mailto:mikec&deerfield.net 2015-07-15
[NLnet_Labs_Support] NLnet Labs Support NLnet Labs mailto:support&nlnetlabs.nl 2011-07-11
[Nasuni_Corporation] Nasuni Corporation mailto:it&nasuni.com 2016-01-22
[Ole_Morten_Duesund] Ole-Morten Duesund mailto:ole-morten.duesund&bbvisuals.no
[Remi_Lefebvre] Remi Lefebvre mailto:remi&debian.org
[Sanjay_Radia] Sanjay Radia mailto:srradia&kasumbi.eng.sun.com
[Sigfus_Magnusson] Sigfus Magnusson mailto:sigfusm&menandmice.com
[Stuart_Cheshire] Stuart Cheshire mailto:cheshire&apple.com 2022-07-11
[Stuart_Cheshire_3] Stuart Cheshire mailto:mdnsresponder-ipc&multicastdns.org 2004-06
[Stuart_Cheshire_4] Stuart Cheshire mailto:pdl-datastream&apple.com 2002-09
[Support_Team] Support Team mailto:support&eucalyptus.com
[Tim_Berners_Lee] Tim Berners-Lee mailto:timbl&w3.org
[Tommy_van_der_Vorst] Tommy van der Vorst mailto:tommy&pixelspark.nl
[Voalte_Inc] Voalte, Inc. mailto:engops&voalte.com 2019-01-22
[XMPP_Registrar] XMPP Registrar mailto:registrar&xmpp.org