Change dns ip

[GoNzCiD]

Hi, is it possible to change the dns ip (in this case i'm interested in change the secondary dns ip) from shell?

Thanks in advance

 

[Yota]

You can changes that by using the nvram command.

This variable is the first DNS of WAN:

wan0_dns

Set it like:

nvram set wan0_dns="8.8.8.8"

Don't forget to enable that DNS for WAN:

nvram set wan0_dnsenable_x="1"

If you enable the DNS filter, it may be invalid, you can use this one to disable the DNS filter:

nvram set dnsfilter_enable_x="0"

And when any nvram change is completed, you need enter this command to save your changes:

nvram commit

There are a lot of DNS variable, if you want to know more please enter it in SSH:

nvram show | grep -i "dns"

DO NOT change any settings you don't know about it, as this may cause your router to become a brick. finally, please always remember that good habit of disable the SSH after use.

 

[bluzfanmr1]

DO NOT change any settings you don't know about it, as this may cause your router to become a brick. finally, please always remember that good habit of disable the SSH after use.

No disrepect intended but do you really disable SSH after each use? Do you not use it regularly? I know that was something said a lot about Telnet in the past but is it still necessary today when using SSH? Again, no disrespect intended and I am just curious what others are doing these days.

 

[ColinTaylor]

No disrepect intended but do you really disable SSH after each use? Do you not use it regularly? I know that was something said a lot about Telnet in the past but is it still necessary today when using SSH? Again, no disrespect intended and I am just curious what others are doing these days.

The issue with telnet (and ftp for that matter) is that it sends all data in plain text over the wire, including user names and passwords.

As for SSH I'd say that's probably one of the most secure components on the router, more so than the web interface, media server, etc. So personally I have absolutely no issue leaving that enabled (for LAN only) as it's something I use most days. I get the philosophy of "if you aren't using it, disable it", but disabling SSH is unnecessary IMHO.

If I thought there was a realistic chance of a targeted SSH attack on my router from within my LAN I think I'd have bigger problems to address.

 

[GoNzCiD]

Thank you so much for the help and the advices. I'll try it next days.

 

[GoNzCiD]

You can changes that by using the nvram command.

This variable is the first DNS of WAN:

wan0_dns

Set it like:

nvram set wan0_dns="8.8.8.8"

Don't forget to enable that DNS for WAN:

nvram set wan0_dnsenable_x="1"

If you enable the DNS filter, it may be invalid, you can use this one to disable the DNS filter:

nvram set dnsfilter_enable_x="0"

And when any nvram change is completed, you need enter this command to save your changes:

nvram commit

There are a lot of DNS variable, if you want to know more please enter it in SSH:

nvram show | grep -i "dns"

DO NOT change any settings you don't know about it, as this may cause your router to become a brick. finally, please always remember that good habit of disable the SSH after use.

Hi, I have been regarding at vars that are affected when changing the dns in the web UI.

wan0_dns1_x=8.8.8.8
wan0_dns2_x=8.8.4.4
wan0_dns=8.8.8.8 8.8.4.4
wan0_dnsenable_x=0
wan0_xdns=8.8.8.8 8.8.4.4
wan1_dns1_x=
wan1_dns2_x=
wan1_dns=
wan1_dnsenable_x=0
wan_dns1_x=8.8.8.8
wan_dns2_x=8.8.4.4
wan_dns=8.8.8.8 8.8.4.4
wan_dnsenable_x=0

I can see that wan0_* and wan_* are affected. I have disabled dns filtering and the interested thing is that all *enable* are always disabled (0), it's correct? I suppose that yes, because it works. But make no sense...

It's normal to that it change wan0_* and wan_* vars?

 

[dave14305]

I can see that wan0_* and wan_* are affected. I have disabled dns filtering and the interested thing is that all *enable* are always disabled (0), it's correct? I suppose that yes, because it works. But make no sense...

It's normal to that it change wan0_* and wan_* vars?

The dnsenable_x settings reflect whether you’re enabling WAN DHCP DNS servers or not. If you select No on the WAN page, this setting will be 0.

The wan0 and wan1 settings are related to the dual-WAN support. Most of us do not have 2 ISPs so we only ever see the wan0 settings populated. I think the corresponding wan_ settings reflect the currently active wan interface (0 or 1).

 

[intr0]

As for SSH I'd say that's probably one of the most secure components on the router, more so than the web interface, media server, etc.

Note I'm commenting on only this part of what you've written. As well as the LAN only part.
Telnet - released as a standard in 1968. Secure enough for IBM to use.
Telnet - STILL being updated by IETF proposals. Now it's called "Virtual Telnet". I wouldn't even think of using it. Except maybe if it's in my LAN only... No, I wouldn't.

SSH - released as a standard in 2006.
SSH - Most recently updated in 2018. By including the use of SHA 256/512 RSA KEYS.

2066 - SSTVMS (super secure tunneling virtual machine shell). It's so secure I don't need to worry about using it. It's not like SSH used to be... I can't believe people even used it...

Pardon me if it sounds sarcastic. It's not meant to be at all. It's just the way these things go.

 

[Yota]

I can see that wan0_* and wan_* are affected.

The WAN and WAN0 may be a duplicate variable caused by a variable added to nvram at different times, they do not want to remove it as perhaps to ensure backward compatibility.

I have disabled dns filtering and the interested thing is that all *enable* are always disabled (0),

It should be enabled. I don’t know if they recently changed the enabled variable or used new variables.

Note I'm commenting on only this part of what you've written. As well as the LAN only part.
Telnet - released as a standard in 1968. Secure enough for IBM to use.
Telnet - STILL being updated by IETF proposals. Now it's called "Virtual Telnet". I wouldn't even think of using it. Except maybe if it's in my LAN only... No, I wouldn't.

SSH - released as a standard in 2006.
SSH - Most recently updated in 2018. By including the use of SHA 256/512 RSA KEYS.

2066 - SSTVMS (super secure tunneling virtual machine shell). It's so secure I don't need to worry about using it. It's not like SSH used to be... I can't believe people even used it...

Pardon me if it sounds sarcastic. It's not meant to be at all. It's just the way these things go.

I agree that nothing is the safest, and should be kept closed if not used, as this can reduce the attack surface.

 

[john9527]

The WAN and WAN0 may be a duplicate variable caused by a variable added to nvram at different times, they do not want to remove it as perhaps to ensure backward compatibility.

No, the wan_ variable is used by the gui. The gui then reads/writes to either wan0_ or wan1_ depending on which one you are configuring. That's how the same page can be used to configure either wan in a dual wan config.

 

[GoNzCiD]

Thanks to all, I have working the scripts I want.

 

[intr0]

I agree that nothing is the safest, and should be kept closed if not used, as this can reduce the attack surface.

Yesterday I was reading an article regarding using a Raspberry Pi combined with a reverse proxy (such as what CloudFlare provides) to host a website. It's all fully locked down in the setup instructions, in the detailed graphics used to visually explain how it's setup, etc. However, the author uses SSH to log in to the Pi to do most of the setup. It's a good, explanatory article. Expect for the fact that no where does it instruct the reader/s to a) use the strongest SSH key possible (password encrypted or not, depending on the capability of the system being logged into; 4096bit RSA / 512bit Elliptic Curve key / SHA512 hashed password etc (despite the fact that it takes a single command or any one of multiple online tools to reverse any hash)). And the author never states to even use key based auth. And they state that they access the remotely via SSH over port 22. Remotely. I wanted to ask the domain name, but there was nowhere to leave comments.