Nameserver not removed? Working as designed?

[Richard G]

I just discovered something with might be a bug in DA.

Lets say I have a main admin domain mydomain.nl with nameservers ns1 and ns2.
For this example ns1 has 192.168.0.1 and ns2 has 192.168.0.2 as ip address.

Now I changed servers, restored my domain and the new ip's are 192.168.100.1 and 192.168.100.2.
Both ip's are already installed on the new server and main domain restored.

The main domain now has ns1 192.168.100.1 and ns2 192.168.0.2.

So I go to reseller level, select both new ip's and use the function "create ns1 and ns2 ... mydomain.nl".
This works oke. But the second nameserver, which should be overwritten or replaced is still present. It's like this now.

ns1.mydomain.nl 192.168.100.1
ns2.mydomain.nl 192.168.100.2
ns2.mydomain.nl 192.168.0.2

As you can see, the old ns2 is still in there and I have to remove it manually. Is this normal, so working as designed? Shouldn't the old ns2 not be replace by the new one I created with that method?

 

[nobaloney]

It's likely a simple cosmetic issue. Did you try creating a new domain in an account using those nameservers to see what it creates in the new zone file?

Jeff

 

[Richard G]

It's not only a cosmetic issue. There are also 3 nameservers like this in the mydomain.nl.db present. This only happened after I changed the nameservers.
When I create a new domain, only the 2 correct nameservers are present.
Still... it works confusing if the old one stays visible in the DNS administration when nameservers are changed.

 

[Arieh]

Not sure if I understand entirely, but maybe ns1 has changed because it had the same IP as all other records and at restore it just changed all those records with that IP; and as ns2 has a different IP address it won't touch it. And if you create the new nameservers, it won't create a duplicate for ns1, but it will add the ns2 <> new ip, since that one doesn't exist.

Question is if it should indeed remove an existing ns2; are there cases where this is undesirable? Also, a create button would indicate an addition of records, not to manage it entirely.

Just my 2 cents.

 

[Richard G]

and as ns2 has a different IP address it won't touch it. And if you create the new nameservers, it won't create a duplicate for ns1, but it will add the ns2 <> new ip, since that one doesn't exist.

Exactly! That is what I was talking about.

But why should removal of an existnig ns2 be undesirable if it has the same hostname as the new ns2?
That's what I was wondering about. Because there is no benefit in having 2 exactly the same hostnames (ns2.mydomain.nl) with different ip adresses, at least I can't think of any.

I also thought the new DA versions would have a button to change records (ip addresses and/or hostname)? But I presume this is not implemented yet?

 

[nobaloney]

But why should removal of an existnig ns2 be undesirable if it has the same hostname as the new ns2?
That's what I was wondering about. Because there is no benefit in having 2 exactly the same hostnames (ns2.mydomain.nl) with different ip adresses, at least I can't think of any.

There may be advantages since DNS gives out whatever it has. If it's got two A records for ns2, it'll give out both of them (in random order) every time it's asked. So it can be used to spread server load over multiple servers.

That doesn't mean this isn't an oversight, but it does have [pssible advantages .

Jeff

Jeff

 

[Richard G]

LoL Jeff... you're making me laugh now.
Having 2 exactly the same hostnames with different ip's goes against all RFC's and networking protocols and lessons.
More strongly, in earlier days in windows for example, 2 hostnames with different ip's in a workgroup could even cause network conflicts, resulting in one or even both pc's not being able to be reached in the network anymoer (like an ip conflict).

So there is no advantage at all, it's crap.

 

[nobaloney]

Having 2 exactly the same hostnames with different ip's goes against all RFC's and networking protocols and lessons.

And so does having two nameserver names pointing to two different IP#s, both pointing to the same machine. Yet how many hosters do that?

How come you've never written anything when I've written about my poor man's fail-over method, where I recommend hosting your site on two different servers, each hosting it's own DNS and poionting to it's own IP#s?

And have you ever been to one of the many meetings in which I've stood up, made fool of myself, and argued that RFC simply means Request For Quotation (though over the yearts we've given it a lot more import.

More strongly, in earlier days in windows for example, 2 hostnames with different ip's in a workgroup could even cause network conflicts, resulting in one or even both pc's not being able to be reached in the network anymoer (like an ip conflict).

Yeah, but if they were Windows machines that could have been a good thing .

If you know why you're breaking the RFCs it may not be so bad. While I don't like how Dan Bernstein broke RFCs when he wrote his own DNS server, I admit it's a high-speed server with lots of features and advantages.

So there is no advantage at all, it's crap.

Personally I think the whole method of assigning Nameservers in DirectAdmin is overly complex. I only use virtual nameservers; I don't need to worry about the IP#s. But I suppose some people need the handholding. I did many years ago, when I read DNS books instead of writing them (no, my DNS book was never published; that's a hard hurdle to... well... hurdle).

Perhaps John needs to visit this thread.

And I hope I made you laugh some more .

I've always strived to make everyone happy. Some people are happy when I arrive, others when I leave. But eventually everyone is happy.

Jeff

 

[DirectAdmin Support]

The ns2 pointing to 192.168.0.2 is going to be a limitation as to what DA could know..
Often, ns2 is going to point to some external box, so in that case, we wouldn't want it to change.

1) Since a restore is only ever assigned to 1 IP address, I guess the next best thing might be to record somewhere in the backup, the fact that 192.168.0.2 was another IP on the original system.
That way DA could at least assign ns2 to the IP the account is being assigned to (both ns1 and ns2 would be pointing to the same value)..
as DA wouldn't have been given any sort of permission to play around with the other IPs on the box.
But, this would still require manual intervention to set ns2 to another value.

2) Or... for the case where the ns2 matches the IP virtual ns2 (admin settings)... store that fact, and then set it to the IP of the new virtual ns2 IP.

Regardless, there isn't enough info in the backups right now to know what do do with ns2. We don't know if it's custom, local, external, etc..

3) For external IPs, it's easy, in which case the 192.168.0.2 would be correct.
On a side-note, the restore is what will be re-adding the dns settings, so you really shouldn't need to "create nameservers" again.


Anyway, let me know if you guys have any opinion on #1 or #2 .... #2 may be better as it wouldn't require any extra steps...
But.. it comes down to "is this the correct answer to the problem?"

John

 

[Richard G]

And so does having two nameserver names pointing to two different IP#s, both pointing to the same machine. Yet how many hosters do that?

A lot, but that is quite different from a machine having 2 exactly the same hostnames which should be unique, but with different ip's. That's against all networking lessons. Having 2 different nameservers with differnt ip's is still a difference on both, even if they point to the same machine. It's not good practice to do it that way, but it's not against lessons we learn about networking, how to use ip's and hostnames I mean.
Indeed RFC's are agreements not rules.

How come you've never written anything when I've written about my poor man's fail-over method, where I recommend hosting your site on two different servers, each hosting it's own DNS and poionting to it's own IP#s?

I probably missed or overseen that.
But I know RFC's are Request For Quotation, but it's used as agreements for good practice.

Als I agree with you that the nameserver method is a bit complex. However, I don't have problem with it. It's fairly easy to setup once you know what a nameserver is and how you put the A records in Directadmin or any other control panel or server.
On our servers we mostly use nameservers on one domain. Resellers mostly use virtual nameservers. Works great, so if things change, we only need to change ip's on 1 domain. Only a couple of resellers don't use the virtual stuff.
However, if you really want to go deep into DNS, it's complex.

And just for your info. You did not made me laugh more, because I only had to laugh about using the exact same hostnames. And that's not because I laugh at you but because I found it funny because this was coming from you. You always have good points and comments and I highly respect you, as you might know.
FYI... I personally belong to the group of people which is always are happy when you arrive, not when you go. And I like your sense of humor.

@John:
I'ts not good practice as Jeff already pointed out, but sometimes it's necessary or temporarily necessary to use the second ip on the local machine for ns2.
So I might think that option #2 would be the best option.
However, the same goes when you want to change things afterwards and use the nameserver function in DA to change it. Maybe a confirmation like "nameserver already exist, do you want to overwrite it with the selected ip's"? Or any other way to point out that now there are 2 ns2 nameservers and one needs to be removed.

 

[nobaloney]

You always have good points and comments and I highly respect you, as you might know.
FYI... I personally belong to the group of people which is always are happy when you arrive, not when you go. And I like your sense of humor.

Thanks!

I know there's a problem with small hosters who don't have second machine to use as a second nameserver, and who don't realize the importance of having a second nameserver.

And I still see arguments from time to time (even on these forums) from admins who say it doesn't matter because if your server is down it's okay if your name service is down as well. So I know it's not a battle easily won to get everyone on board with proper DNS practice.

A part of me wishes that DirectAdmin would not seem to condone using two logical nameservers on the same physical server by allowing you to select two IP#s from the same machine; if it only allowed one, and then forced you to add the other as a virtual nameserver at least it might make a few folk think.

But then of course I realize the support load that would cause, often because admin's aren't really experienced enough, especially in DNS, which as you know, once yu get into the real guts, isn't as easy at appears to be as first.

There have been several good DNS books written both before and after my abortive attempt, so I won't try to write another . And I likely won't offer low-priced automated slave DNS services again, as my first time got me only a few customers who only lasted a few years.

I'll let John get some other replies, hopefully, besides just yours. And hopefully we can get a resolution to everyone's satisfaction and to RFCs and best practices.

Jeff

 

[Richard G]

because if your server is down it's okay if your name service is down as well.

That's an argument indeed used. I normally respond to that, that emails will get send back to the sender because the domain can't be found and mx records are not found if server is down. On a real secondary dns, they still point to the server, can be found and so the sending mailserver will try again to send the mail xx hours later. That's a benefit.
But some just don't care. We did it like that too in the beginning, or very temporarily sometimes nowadays if needed, mostly when a new server is still being configured and secured.
If we don't have another DA server to exchange with, we take a cheap vps and use directslave.

It might be an idea what you have with that virtual secondary nameserver. But there are company's who wouldn't want to see google's nameserver appearing to customers when they do a reverse lookup.
But the more people will get aware of the importance and in fact the very low cost to be able to set it up the correct way (f.e. with a cheap vps), the better it is.

Let's hope indeed there will be more reply's with thoughts about the options John gave.

 

[nobaloney]

We rDNS our nameservers to a relatively anonymous domain: namelessnet.net, and we register that anonymously. Which helps even the paranoia of our clients.

We can also do nameservice at dedicated IP#s but they tend to be expensive because we need a dedicated IP# for the client at each of our nameservers. (Or at least each which they advertise.)

We now only do this for our own hosting clients, resellers, and Dedicated and VPS users, as we've stopped selling slave DNS to the outside world.

Jeff