Talk:Dynamic DNS

message: Any objections? Josh Parris ✉ 23:19, 18 May 2005 (UTC)
replies: text: Yes, unless you explain why. – Smyth\talk 14:17, 19 May 2005 (UTC)

text: Alright, I have replaced it with a link to Google Directory. – Smyth\talk 17:29, 20 May 2005 (UTC)
thread_title: I intend to delete the list of external providers

message: Scottprive seems to be describing the CGI code used to call nsupdate by providers like dyndns.org.  I know of no DNS server that is listening on port 80.  I think the claim of update via http should be reverted unless it can be backed up. Smallpond
:Yes, I think that the original author attempted to say that many proprietary services that call theirselves "dynamic DNS" do not actually implement the RFC2136/2845 protocol, but use a proprietary protocol instead, that's often HTTP-based. The paragraph is really unclear and confusing about this. The DDNS RFCs don't even mention HTTP, so it's probably safe to rewrite it. -- intgr 15:54, 11 October 2006 (UTC)
replies: text: Actually, I'm willing to bet that the providers use RFC-standard methods internally, they just put the webserver between the customer and the DNS updates for ease of use and security.  Anyway, I changed the section to describe the HTTP protocol updates, see if it's clear. Smallpond 21:45, 12 October 2006 (UTC)
replies: text: Comment: The assumption they just put the webserver between the customer and the DNS updates for ease of use and security is not correct. Security has nothing to do with the reasons for the proprietary (HTTP) dynamic DNS formats. There was not any standard in RFC-based dynamic DNS updates to allow for "user" and "account" centric responses ('update abuse', 'no host', 'expired account', 'call support' etc). Commercial and free dynamic DNS providers are all 'proprietary' in this respect. Scottprive 16:52, 20 November 2006 (UTC)
replies: text: I removed the "(DDNS)" acronym since it's not used for referring to "dynamic DNS" in the general case, but rather the RFC-specified DNS protocol extension [as far as I know]. I think the next section about the standard DDNS (currently saying "'Dynamic DNS' is documented by RFC 2136 ...") should also be rewritten to be more clear that it's just one of all the protocols capable of updating DNS; also, it should probably be mentioned earlier in the article that there is a standard as well as proprietary protocols, just to make it clear since that's likely to confuse people otherwise. -- intgr 22:26, 12 October 2006 (UTC)
replies: text:  'dynamic DNS' is not a single method for updating a DNS server: it's also a service industry, a proprietary protocol, a method of working on limited or degraded Internet connections, and it has peripheral relationships to 'port blocking'. It's not just what it says in the current article. I'll post another talk on this. -- Scottprive 16:52, 20 November 2006 (UTC)
thread_title:  http update 

message: I have an idea about a feature that would change how the internet worked.
I propose that DNS have resource record types such as: 
porthttp,porthttps,portsmtp,portsmtps,portimap,portimaps,portpop3,portpop3s,portftp,portftps,etc...
I appears to me that such a move would change the way the world relies on IP addresses, since we appear to be running out.  If you think how many servers there are in the world that have static IP addresses that only host one web page or even one service.
It seems like it would be fairly easy to implement a record type lookup to determine what port a website is using. The same thing could be accomplished for looking up what port a mail server is using.  Yes the web browsers of the world could be adapted to do a ip and port lookup.
SSL Certificates could be adapted to include both the domain name and port.
DNS record types could be created and used to register what port a webpage is on.
For example:
My webpage would have two DNS records.
Record Type "A" host record, www.example.com = 127.0.0.1
Record Type "porthttp" port record, www.example.com = 80
This type of resource lookup would allow the internet to host a website or service on which ever port they wanted and would prevent the world from relying on common ports as the answer of where am I going to put my service. 
Think about this. Currently one static IP address can only host one website service on a single static IP address.  Routing and NAT take care of this. The only problem is there is no DNS record to lookup a port for the expected service. If a single IP address can have 65535 ports then a single IP NAT address could host 65535 websites on 65535 different ports.  All is need is the ability to find the port that the http service is located on.
I also see this as a chance to solve the world's problem with ISP's blocking commonly used ports.
I don't have the programming skills to do the work, but if the idea was communicated to the world, the right people could make it happen.
09:55, 28 July 2011 (UTC)
replies: text:  See the SVCB RRtype. Bill Woodcock (talk) 10:00, 3 September 2021 (UTC)
thread_title:  Question / Idea 

message: I'm not sure about this so won't edit the article, but isn't this article about two topics which have some things in common but are in many important ways distinct? 1: a service providing a static address for users with addresses which change from time to time, allocated by ISPs; 2: the process for normal maintenance of DNS records.
1 is of relevance to people, who do not need to be computer-literate, with non-static IP addresses supplied by ISPs. 2 is relevant to technical people maintaining the Internet and keeping organisations' DNS information up to date.
The article at present seems rather confusing; the two functions should distinguished clearly and dealt with in separate sections. While what happens may be basically similar, the purpose is quite different.
On looking back I find that this point has already been raised, but I think a separate section here is justified; it's not jut an artificially narrow definition but two distinct topics, or at least aspects.
(Added later) I've changed the article radically to reflect this distinction. More needs doing.
Pol098 (talk) 10:01, 1 December 2011 (UTC)
replies: text: I'm still confused. I get a vague impression that Dynamic DNS is a catch-phrase rather than a welldefined term, which presumes DNS UPDATE and some DNSSEC and maybe more. The M$ variant presumes that the name resolution is foreign, i.e. through Active Directory (specifically AD DS). Rursus dixit. (mbork3!) 05:48, 12 April 2012 (UTC)
replies: text:  I agree that the article should more clearly (begin by?) state the difference between RFC 2136 and the "proprietary" DynDNS services and their (similar) HTTP-based protocols, but I also think it needs a cleanup and partial rewrite. I also think it should be flagged as "low quality" or such. --TmuSrnn (talk) 17:37, 19 January 2016 (UTC)
thread_title:  Is this article about two rather different topics? 

message: I came to this article to help me understand dynamic addressing in IPv6 and how to assign a hostname. No luck.  — Preceding unsigned comment added by 192.101.136.224 (talk) 21:18, 5 January 2015 (UTC)
thread_title:  Does not include any discussion on IPv4 vs IPv6