RFC 4367

What's in a Name: False Assumptions about DNS Names

📅 published February 2006, from ietf

RFC 4367: What's in a Name? False Assumptions about DNS Names 🎀

Okay bestie, here's the deal. This is an Informational RFC from February 2006, written by J. Rosenberg, Ed. for the IAB (Internet Architecture Board). It's not a standard, just really good advice 💅. It doesn't list any RFCs it obsoletes or updates.

Status of This Memo

This memo is here to share information with the Internet community. It doesn't set any Internet standard, and anyone can distribute it freely 🌸.

Copyright (C) The Internet Society (2006).

Abstract

DNS is the system that turns human-friendly names into all kinds of data, usually IP addresses 🦋. Those names show up in email addresses, URIs, and other identifiers that people read all the time. So everyone wants names that mean something, like a trademark, a company name, or a type of service. The problem? Humans and automated systems start assuming things about what a name should offer, and those assumptions are often wrong, which causes all sorts of failures 💀. This doc digs into that problem and suggests how to avoid it 💖.

Table of Contents

   1. Introduction ....................................................2
   2. Target Audience .................................................4
   3. Modeling Usage of the DNS .......................................4
   4. Possible Assumptions ............................................5
      4.1. By the User ................................................5
      4.2. By the Client ..............................................6
      4.3. By the Server ..............................................7
   5. Consequences of False Assumptions ...............................8
   6. Reasons Why the Assumptions Can Be False ........................9
      6.1. Evolution ..................................................9
      6.2. Leakage ...................................................10
      6.3. Sub-Delegation ............................................10
      6.4. Mobility ..................................................12
      6.5. Human Error ...............................................12
   7. Recommendations ................................................12
   8. A Note on RFC 2219 and RFC 2782 ................................13
   9. Security Considerations ........................................14
   10. Acknowledgements ..............................................14
   11. IAB Members ...................................................14
   12. Informative References ........................................15

1. Introduction ✨

DNS [1] is basically the Internet's essential name-to-data translator 🧚. Its most common job is finding the IP address of a host linked to a name [2] [1] [3]. But it can do way more, and people have proposed using it for almost everything, including geographic info [4].

Domain names are everywhere in application identifiers, especially email addresses and URIs. The big ones are the HTTP URL [5], the Real Time Streaming Protocol (RTSP) URL [6], and the SIP URI [7] 📱. They're on business cards, websites, and street signs, which is exactly why companies go hunting for domain names with brand vibes, advertising power, and service-related meaning 🍓.

People also guess what a host ought to offer based on its name 👀. That's pushed organizations to register names based on those guesses. Some examples: proposals for a TLD tied to adult content [8], requests for TLDs about mobile devices and services, and even phishing attacks 🙈.

Once those guesses get baked into a client or server (because of an implementor's choice, a management rule, or domain owner policy), things can break in lots of ways 😭. This doc walks through the common ways those assumptions sneak in, how they can be wrong, what goes wrong because of them, and how to avoid the trap 💜.

Section 4 covers the kinds of assumptions clients, servers, and people might make about a domain name. Here, an "assumption" means any behavior you expect when using a service at a domain name, even if no protocol spec actually requires it 🫶. Usually these assumptions mean ignoring part of a spec because you think your environment is stricter than the spec allows. Section 5 gives an overview of what goes wrong: interoperability failures, bad user experiences, and full system failures 💥. Section 6 explains why an assumption can be wrong from the start or can go bad later. Usually the environment changes in unexpected ways, and what used to be a fair assumption just isn't anymore. Other times, the assumption was based on a specific community of clients and servers, and something outside that community joined the party 🎉.

Section 7 gives recommendations. They're built on classic Internet protocol engineering mantras that have been around for decades. They include:

  • Follow the specifications.
  • Use the capability negotiation techniques provided in the protocols.
  • Be liberal in what you accept, and conservative in what you send. [18]

The big takeaway: automata should not change their behavior within a protocol based on the domain name, or any part of the domain name, of the host they're talking to 🌈.

2. Target Audience 🎀

This doc has a few audiences, and they're all kind of responsible for the drama 😤.

First up are the implementors who actually write the software that makes these false assumptions. The recommendations here are meant to back up the engineering basics they usually know, but tend to forget once deadlines are looming and everyone's stressed 💅.

Next are the technology managers, who often write the requirements that lead to these assumptions. For them, this doc is a reminder not to take shortcuts when deciding what a project actually covers 👑.

Finally, it's for domain name policy makers and administrators. This doc points out the risk of setting domain policies that end up hardcoded into how applications behave inside that domain ⚠️.

3. Modeling Usage of the DNS 🦋

Here's the simple picture of how applications use DNS:

                       +--------+
                       |        |
                       |        |
                       |  DNS   |
                       |Service |
                       |        |
                       +--------+
                         ^   |
                         |   |
                         |   |
                         |   |
          /--\           |   |
         |    |          |   V
         |    |        +--------+                     +--------+
          \--/         |        |                     |        |
            |          |        |                     |        |
         ---+---       | Client |-------------------->| Server |
            |          |        |                     |        |
            |          |        |                     |        |
           /\          +--------+                     +--------+
          /  \
         /    \

         User
                                 Figure 1

Figure 1 shows the basic setup 🧩. A user grabs an identifier for the content or service they want, which is usually a URL or URI with a domain name in it. They type that into their client app, like putting a URL into a browser window 💻. The client is the automaton (software and/or hardware) that reaches out to a server so it can give the user what they asked for. To find that server, it asks a DNS server to turn the domain name into an IP address, then contacts the server at that address 🚀. This same basic model covers application protocols like HTTP [5], SIP [7], RTSP [6], and SMTP [9].

From this model, it's clear that three entities could make false assumptions about what the server provides 🕵️‍♀️. The human user might form expectations about the content based on the host name the content came from. The server might assume the client speaks protocols it doesn't, can handle content it can't, or has capabilities it doesn't have. And the client might assume the server supports protocols, content, or capabilities it doesn't. On top of that, an application can involve lots of humans, clients, and servers, and each one can independently make these false assumptions 🌸.

4. Possible Assumptions 💭

There are lots of types of false assumptions for each of those three elements 🙃.

4.1. By the User 🙈

The list of possible user assumptions is basically endless 😂. Users might assume an HTTP URL that looks like a company name leads to a server run by that company. They might assume an email from an address in the .gov TLD is really from a government employee. They might assume content from a web server in a TLD labeled as adult (for example, .sex) really is adult content [8]. These assumptions are unavoidable, they may all be false, and they're not the focus of this doc 🫠.

Stay tuned, because more of this is coming up in part 2 🦋✨.

4.2. By the Client ✨

okay so even though the client is an automaton (a robot, basically 🤖), it can make some of the same assumptions a human user might 🙈 like, lots of clients assume any host with a hostname starting with www is a web server 💅 even though that assumption can totally be false 💀

also the client cares about the protocols it needs to talk to the server, so it might assume stuff about how those protocols work 🧚 these assumptions show up in the implementation when a standardized protocol negotiation technique (the one the protocol itself defines) gets ignored, and instead some rule gets hardcoded into the software that comes to its own conclusion about what the negotiation would have decided 😭 the result is usually lost interoperability, worse reliability, and a worse user experience 💔

  • Authentication Algorithm: a protocol might support a whole bunch of authentication techniques, but a client might assume the server always supports one that's only optional according to the protocol 🔐 for example, a SIP client contacting a SIP server in a domain that's apparently used to identify mobile devices (like www.example.cellular) might assume the server supports the optional Authentication and Key Agreement (AKA) digest technique [10], just because of the domain name it used to reach the server 📱 another one: a web client might assume a server named https.example.com supports HTTP over Transport Layer Security (TLS) [16] 🔒
  • Data Formats: a protocol might allow lots of data formats to be sent from the server to the client, but the client might assume one specific format instead of using the content labeling and negotiation capabilities of the underlying protocol 🎀 for example, an RTSP client might assume all audio content delivered to it from media.example.cellular uses a low-bandwidth codec 🎧 and a mail client might assume the contents of messages it pulls from a mail server at mail.example.cellular are always text, instead of checking the MIME headers [11] in the message to figure out the actual content type 📨
  • Protocol Extensions: a client may try an operation on the server that needs the server to support an optional protocol extension 🧩 but instead of implementing the necessary fallback logic, the client may falsely assume the extension is supported. an example: a SIP client that needs reliable provisional responses to its request (RFC 3262 [17]) might assume this extension is supported on servers in the domain sip.example.telecom 📞 and then it wouldn't implement the fallback behavior defined in RFC 3262, since it would assume every server it talks to is in that domain and therefore all support the extension 🙃 but if those assumptions prove wrong, the client is unable to make any phone calls 📵😭
  • Languages: a client may support facilities for processing text differently depending on the language of the text 🌍 but rather than figuring out the language from markers in the message from the server, the client might assume a language based on the domain name 🫠 and that assumption can easily be wrong. for example, a client might assume any text in a web page retrieved from a server within the .de country code TLD (ccTLD) is German, and try to translate it to Finnish 🇩🇪➡️🇫🇮 which would fail dramatically if the text was actually French 💀 unfortunately this client behavior sometimes happens because the server never properly labeled the language of its content in the first place, often because the server assumed that labeling wasn't needed 🥲 this is a perfect example of how false assumptions can create vicious cycles 🔁

4.3. By the Server

the server is an automaton too, just like the client 🤖 let's think about one servicing a particular domain, like www.company.cellular 🏢 it might assume that all clients connecting to this domain support particular capabilities, instead of using the underlying protocol to figure that out. some examples:

  • Authentication Algorithm: the server can assume a client supports a particular optional authentication technique, and so it doesn't support the mandatory one 🙅‍♀️
  • Language: the server can serve content in a particular language, based on an assumption that the clients accessing the domain speak a particular language, or based on an assumption that clients coming from a particular IP address speak a certain language 🗣️
  • Data Formats: the server can assume the client supports a particular set of MIME types and is only capable of sending ones within that set 📦 when it generates content in a protocol response, it ignores any content negotiation headers that were present in the request 🙈 for example, a web server might ignore the Accept HTTP header field and send a specific image format 🖼️
  • Protocol Extensions: the server might assume the client supports a particular optional protocol extension, so it doesn't support the fallback behavior that's needed when the client doesn't 🔁
  • Client Characteristics: the server might assume certain things about the physical characteristics of its clients, like memory footprint, processing power, screen sizes, screen colors, pointing devices, and so on 📏 based on those assumptions, it might choose specific behaviors when processing a request 💅 for example, a web server might always assume clients connect through cell phones, and therefore return content that lacks images and is tuned for those devices 📱

5. Consequences of False Assumptions 💥

okay so there are SO many negative outcomes that can come from the false assumptions users, servers, and clients can make 😩 these include:

  • Interoperability Failure: the client or server assumed some kind of protocol operation, and that assumption was wrong 🚫 so the two can't communicate and the user gets some kind of error. this is a total interoperability failure, showing up as a lack of service for users of the system 😞 and unfortunately this kind of failure persists. repeated attempts over time by the client to access the service will keep failing 🔄 only a change in the server or client software can fix it 🛠️
  • System Failure: the client or server misinterpreted a protocol operation, and the misinterpretation was serious enough to uncover a bug in the implementation 🐛 the bug causes a system crash or some kind of outage, either transient or permanent (until a user resets it) 💻☠️ if this happens in a server, not only does the connecting client lose service, but other clients trying to connect won't get service either 😱 as an example, if a web server assumes content passed to it from a client (created, for example, by a digital camera) is of a particular content type, and it always passes image content to a codec for decompression before storage, the codec might crash when it unexpectedly gets an image compressed in a different format 📷💥 of course, it might also crash even if the Content-Type was correct, if the compressed bitstream was invalid 🙃 false assumptions merely introduce additional failure cases, babe 🫠
  • Poor User Experience: the client and server do communicate, but the user gets a diminished experience 😕 for example, if a client on a PC connects to a website that provides content for mobile devices, the content may be underwhelming when viewed on the PC 💻 or a client accessing a streaming media service may receive very low bitrate content, even though the client supported better codecs 📉 and if a user wants to access content from both a cellular device and a PC using a shared address book (that is, an address book shared across multiple devices), the user would need two entries in that address book, and would need to use the right one from the right device 📇 this is a poor user experience 😤
  • Degraded Security: a weaker security mechanism gets used than the one that ought to have been used 🔓 for example, a server in a domain might assume it's only contacted by clients with a limited set of authentication algorithms, even though those clients have recently been upgraded to support a stronger set 😬 this one is seriously giving "we had the upgrade and didn't even know it" 🥀

6. Reasons Why the Assumptions Can Be False 🧐

assumptions made by clients and servers about how protocols operate when contacting a particular domain are brittle, and they can be wrong for lots of reasons 🪵 on the server side, many of the assumptions are based on the idea that a domain name will only be given to, or used by, a restricted set of clients 🎯 if the holder of the domain name assumes something about those clients, and can assume that only those clients use the domain name, then they can configure or program the server to operate specifically for those clients 🛠️ both parts of this assumption can be wrong, as discussed in more detail below 👀

on the client side it's similar, being based on the assumption that a server within a particular domain will provide a specific type of service 🫶 sub-delegation and evolution, both discussed below, can make these assumptions wrong 💫

6.1. Evolution 🦋

the Internet and the devices that access it are constantly evolving, often at a rapid pace 🚀 unfortunately there's a tendency to build for the here and now, and then worry about the future later 🙈 lots of the assumptions above are predicated on the characteristics of today's clients and servers 📅 support for specific protocols, authentication techniques, or content is based on today's standards and today's devices 📲 even though these may, for the most part, be true, they won't always be 😭 an excellent example is mobile devices. a server servicing a domain accessed by mobile devices might try to make assumptions about the protocols, protocol extensions, security mechanisms, screen sizes, or processor power of those devices 🤳 but all of these characteristics can and will change over time ⏳

when they do change, the change is usually evolutionary 🌱 the result is that the assumptions remain valid in some cases, but not in others 🎭 it's difficult to fix such systems, since it requires the server to detect what type of client is connecting and what its capabilities are 🕵️‍♀️ unless the system is built and deployed with these capability negotiation techniques built in from the start, that detection can be extremely difficult 😩 in fact, fixing it will often require adding the very capability negotiation features that, if they'd been in place and used from the beginning, would have avoided the problem altogether 🤦‍♀️✨

6.2. Leakage ✨

okay so servers make an assumption too 🙈 they figure they'll only ever be visited by specific clients, the ones that are set up or provisioned to use the domain name. basically there's this vibe of "community" 🫶 where the people who know the name are the in-crowd and everyone else is not invited.

but bestie, this community is not real 😭 the Internet is global. the DNS is global. there is literally no technical wall between the in-crowd and everyone outside it 💀 information zooms around the Internet so fast that these domain names are going to end up in clients outside the community. domain names show up everywhere in URIs, and URIs get passed around constantly, so leakage is just a matter of time ⏳. and since the DNS is global and has only one root [12], clients outside the community can totally go searching for and using those "special" domain names too 👀

honestly though, this leakage is a strength of the Internet, not a weakness 🌈 it's what lets any client with a connection to the Internet reach a service, and that's how a service gets rapid growth in customers 🚀💖

6.3. Sub-Delegation 🍓

clients and users assume things about domains because they think some centralized authority is in charge and can enforce those assumptions 👑 but the DNS isn't centralized, it's distributed 🕸️. if a domain doesn't delegate its sub-domains and keeps all its records in one zone, it can keep a centralized policy about how the domain operates 💅. the problem is that once a domain gets big enough that its administrators start delegating sub-domains to other authorities, it gets harder and harder to keep central control over what service each sub-domain provides 😩.

same deal with domain names that have human-friendly meaning. a service provider called "example" might register and run its services at "example.com", "example.net", and basically example.foo for every foo that is a valid TLD 🤯. just like sub-delegation, this means the number of domains keeps growing, and central control over all of them gets harder to maintain 📈.

not that it's impossible 🙅‍♀️ there are plenty of examples of policies being administered successfully across sub-domains many levels deep ✨. but it takes more and more effort, because it needs human intervention and written process and procedure 📋. automatically checking that policies are being followed is really hard, since there's no way to automatically verify a lot of the policies people come up with 😤.

a cheaper way to handle centralized policy is to just hope everyone follows the centralized policies, then wait for complaints or do random audits 🎲. those approaches have plenty of problems 💀.

the way sub-delegation breaks assumptions is discussed in more detail in Section 4.1.3 of [8] and in Section 3.3 of [20] 📚.

because policy continuity gets fragile across sub-delegations, if a client or user assumes some property tied to a TLD (like ".wifi"), that property is increasingly likely to be missing from a server with a particular name as the number of sub-domains grows 🥺. for example, in "store.chain.company.provider.wifi", there could be four levels of delegation below ".wifi" 🌀. so unless the holder of ".wifi" is working really hard, the properties the holder wants to enforce are quite likely not there 😬. those properties might be missing because of human error, or because someone willfully chose not to follow them 🙃.

6.4. Mobility 🦋

one of the main selling points of a hostname as an identifier is that it sticks around 💜. a client can change IP addresses and still keep the same persistent identifier other hosts use to reach it 🎀. because their value comes from persistence, hostnames tend to move with a host not only when it changes IP addresses, but also when it changes access network providers and technologies 🚶‍♀️. so assumptions based on the access network a hostname seems to belong to tend to be wrong over time 😵‍💫.

for example, a PC might normally connect through its broadband provider and, via dynamic DNS, have a hostname inside that provider's domain 🏠. but you can't assume that any host in that network has broadband access, since the user could connect the PC over a low-bandwidth wireless network and still keep the same domain name 📶🥲.

6.5. Human Error 🙈

human error can cause problems in any system, and this one is no exception 🤷‍♀️. there are plenty of relevant examples.

a client implementation might assume that just because a DNS SRV record exists for a particular protocol in a particular domain, saying the service is available on some port, the service is actually running there 🫠. that assumption can be wrong because the system administrators haven't updated the SRV records to match the services that are running now 🗂️. another example: a client might assume a particular domain policy applies to all sub-domains 🤔. but a system administrator might have forgotten to apply the policy to servers running in one of those sub-domains 😱.

7. Recommendations 💅

based on all these problems, the clear conclusion is that clients, servers, and users should not make assumptions about the nature of the service provided to, or by, a domain 🛑. more specifically, though, here's what can be said:

Follow the specifications 📜: when specifications define mandatory baseline procedures and formats, those should be implemented and supported, even if people mostly end up using the optional procedures 🎯. for example, if a specification mandates a particular baseline authentication technique but lets others be negotiated and used, implementations need to implement the baseline authentication algorithm even if the other ones get used most of the time 🔐. put more simply, the behavior of the protocol machinery should never change based on the domain name of the host 🙅‍♀️✨.

Use capability negotiation 🤝: lots of protocols are built with capability negotiation mechanisms 🧩. for example, a content negotiation framework has been defined for protocols using MIME content [13] [14] [15] 🎀. SIP lets clients negotiate the media types used in the multimedia session, as well as protocol parameters 📞. HTTP lets clients negotiate the media types returned in requests for content 🖼️. when these features exist in a protocol, clients and servers should use them rather than making assumptions about supported capabilities 💖. a corollary is that protocol designers should include such mechanisms when evolution is expected in how the protocol gets used 🌱.

"Be liberal in what you accept, and conservative in what you send" [18]: this axiom of Internet protocol design applies here too 👑. implementations should be prepared for the full range of what a protocol allows another entity to send, rather than being restrictive about what they're willing to receive 🫶.

to sum up: there is never a need to make assumptions 🙌. instead, use the specifications and the negotiation capabilities they provide, and the overall system will be robust and interoperable ✨🔥.

8. A Note on RFC 2219 and RFC 2782 🎀

based on the definition of an assumption given here, the behavior hinted at by records in the DNS also counts as an assumption 🧐. RFC 2219 [19] defines well-known aliases that can be used to build domain names for reaching various well-known services in a domain 🗺️. this approach was later followed by a new resource record, the SRV record [2], which says that a particular service runs on a server in a domain 📡. both of these mechanisms are useful as a hint that a particular service runs in a domain 💡, but both still represent assumptions that may be false 😬. they differ, though, in the reasons those assumptions might turn out to be false 🤓.

a client that assumes "ftp.example.com" is an FTP server might be wrong because the naming convention in RFC 2219 wasn't known by, or wasn't followed by, the owner of domain.com 🙃. with RFC 2782, an SRV record for a particular service only shows up by explicit choice of the domain administrator, so a client that assumes the matching host provides that service would only be wrong because of human error in configuration 🧑‍💻. in this case the assumption is less likely to be wrong, but it can still be wrong 😅.

the only way to know for sure that a service is running on a host is to open a connection to that service's port and check 🔍. implementations need to be careful not to codify any behaviors that cause failures if the information in the record turns out to be false 🚨. this is pretty much common sense for robust implementations, but it's worth saying out loud 📢💖.

9. Security Considerations 🔐💀

🚨 this section is serious, bestie. assumptions about security are where things get really dangerous ⚠️.

one of the assumptions clients or servers can make is about whether certain security protocols and algorithms are available and in use (or not) 🔒. for example, a client accessing a service in a particular domain might assume a specific authentication algorithm or hash function in the application protocol 🧾. over time, weaknesses might be found in that technique, which means a different mechanism is needed 🥀. similarly, a system might start out with an insecure mechanism and later decide to switch to a secure one 🔄. in either case, assumptions about security properties can cause interoperability failures, or even worse, service delivered insecurely even though the client asked for secure service and thought that's what it was getting 😱🫢. these kinds of assumptions are fundamentally unsound, even if the records themselves are secured with DNSSEC 🛡️💥.

10. Acknowledgements 🫶

the IAB would like to thank John Klensin, Keith Moore and Peter Koch for their comments 💜✨.

11. IAB Members 👑

Internet Architecture Board members at the time of writing this document are: 🌸

  • Bernard Aboba 🎀
  • Loa Andersson 🦋
  • Brian Carpenter 🍓
  • Leslie Daigle 💅
  • Patrik Faltstrom ✨
  • Bob Hinden 🧚
  • Kurtis Lindqvist 🌈
  • David Meyer 💖
  • Pekka Nikander 🔥
  • Eric Rescorla ⭐
  • Pete Resnick 🫶
  • Jonathan Rosenberg 👑

12. Informative References ✨

okay bestie, here's the whole reading list the doc points to 📚 every single one is kept exactly as written 💅

  • [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 🌸
  • [2] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 🧚
  • [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. 💜
  • [4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996. 🦋
  • [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 🌈
  • [6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. 🎀
  • [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. ✨
  • [8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, February 2004. 🙈
  • [9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. 💌
  • [10] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002. 🔐
  • [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 🍓
  • [12] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. 👑
  • [13] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000. 🦋
  • [14] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999. 🌸
  • [15] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999. 💜
  • [16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 🫶
  • [17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. ⭐
  • [18] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. 🧚
  • [19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997. 🌈
  • [20] Faltstrom, P., "Design Choices When Expanding DNS", Work in Progress, June 2005. 🔥

Author's Address 💖

the editor's contact details, as listed in the doc:

   Jonathan Rosenberg, Editor
   IAB
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   EMail: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

Copyright (C) The Internet Society (2006). 🌸

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💅

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🌈

okay so the IETF doesn't take a side on whether any intellectual property rights apply to the tech in here, or whether you can actually get a license for it. it also hasn't gone looking for those rights itself. if you want the rules on rights in RFC documents, check BCP 78 and BCP 79. ✨

any IPR disclosures sent to the IETF Secretariat, plus any licensing assurances or attempts to get a general license for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🦋

and if you spot a copyright, patent, patent application, or other proprietary right that might cover tech needed to implement this standard, the IETF wants to hear about it. send it to ietf-ipr@ietf.org. 💜

Acknowledgement 🫶

the RFC Editor function is funded by the IETF Administrative Support Activity (IASA). the people behind the scenes deserve all the love 💖

📦 where this page comes from