Talk:Dynamic DNS

I intend to delete the list of external providers

Any objections? Josh Parris ✉ 23:19, 18 May 2005 (UTC)

Yes, unless you explain why. – Smyth\^talk 14:17, 19 May 2005 (UTC)

The list of providers is transient and non encyclopedic. Wikipedia:What Wikipedia is not#Wikipedia is not a mirror or a repository of links, images, or media files. Surely there is a list of Dynamic DNS providers already kicking around on the web somewhere. Josh Parris ✉ 00:33, 20 May 2005 (UTC)

Alright, I have replaced it with a link to Google Directory. – Smyth\^talk 17:29, 20 May 2005 (UTC)

http update

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)

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)

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)

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)

'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)

Artifically narrow definition for dynamic DNS

There are multiple definitions for 'dynamic dns'. For whatever reason, this article periodically expands to cover both definitions, and then contracts when someone deletes an edit that is 'proprietary'.

RFC based 'dynamic dns' implementations do not get deleted from this article, but 'other' definitions of dynamic DNS ("proprietary") do get deleted. The policing on this article actually harms the average person unfamiliar with the different technologies, and who has been told by someone to 'get dynamic DNS, so you can host a security camera online". People are getting confused or misdirected.

Excluding the concept of vendor supplied dynamic DNS will change usage. There is another context here, one which is used by almost every router on the planet and how people use it in networking forums. The reason folks are injecting things here (which eventually get deleted or edited) is because the article lacks full scope.

I am suggesting we cover the FULL scope of 'dynamic DNS' in a way that is not specific to any vendor or implementation. Where appropriate we can move expanded details off to new stub articles: 'Dynamic_DNS_proprietary' and 'Dynamic_DNS_RFCs'. Agreed?

Note: I am from a DDNS vendor, and if I lead on this edit spree I am susceptible to accusations of bias. Would someone please consider this argument and make a pass at this suggestion? -- Scottprive 18:27, 20 November 2006 (UTC)

I can't see why anyone would oppose splitting the article into three sections (introduction+generic meaning, DDNS defined by the RFC, and proprietary dynamic DNS) – it's screaming for sections anyway. I promise to back you up in any edit wars you might encounter. :)

An alternative would be splitting the article in two with a disambiguation page, but I don't think the concepts are different enough to warrant that -- intgr 19:05, 20 November 2006 (UTC)

Your suggestion is good so I took a shot at splitting the article into sections as you suggested with a few changes to the text. -- Smallpond 17:19, 27 March 2007 (UTC)

Smallpond and Intgr - thanks. The current version is the most helpful version yet, in my opinion. Scottprive

Question / Idea

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) — Preceding unsigned comment added by 68.106.179.249 (talk)

 Done: See the SVCB RRtype. Bill Woodcock (talk) 10:00, 3 September 2021 (UTC)

Is this article about two rather different topics?

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)

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. (^mbork³!) 05:48, 12 April 2012 (UTC)

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)

Does not include any discussion on IPv4 vs IPv6

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)

@ 117.20.115.106 (talk) 08:12, 2 January 2024 (UTC)