dynamic ip host & auto dns changes

Hello list.

I have installed the unbound port on Freebsd release 11.1. My host gets
an dynamic ip address assigned from the ISP service I am using. This is
all very common and normal. But as we all know, the ISP can change not
only the assigned ip address on the fly but also the dns servers ip
addresses. When this occurs the /etc/resolv.conf file gets updated
automatically on the fly.

From reading about unbound I get the concept that unbound is designed
for hosts that have static ip addresses. IE; the dns ip addresses have
to be manually placed in /etc/resolv.conf and will not change without
prior written notice.

For this usage /etc/resolv.conf get populated with
"nameserver 127.0.0.1"
and unbound.conf needs the forward-zone: section with the static dns ip
addresses.

Now my question is, is there any way to configure unbound so when the
dynimic dns ip addresses change unbound will contuine to work
automatically. IE; no human manual editing of the unbound.conf file.

Thanks for your help

Hello list.

I have installed the unbound port on Freebsd release 11.1. My host gets
an dynamic ip address assigned from the ISP service I am using. This is
all very common and normal. But as we all know, the ISP can change not
only the assigned ip address on the fly but also the dns servers ip
addresses. When this occurs the /etc/resolv.conf file gets updated
automatically on the fly.

From reading about unbound I get the concept that unbound is designed
for hosts that have static ip addresses. IE; the dns ip addresses have
to be manually placed in /etc/resolv.conf and will not change without
prior written notice.

For this usage /etc/resolv.conf get populated with
"nameserver 127.0.0.1"
and unbound.conf needs the forward-zone: section with the static dns ip
addresses.

which "static dns ip address" do you like to see there?

Now my question is, is there any way to configure unbound so when the
dynimic dns ip addresses change unbound will contuine to work
automatically. IE; no human manual editing of the unbound.conf file.

simply do no forwarding at all. Let unbound do it's job:
- offer recursiver resolution on 127.0.0.1
- resolve names as usual from the root
You're not required to *use* the ISP's dnsserver even if they are offered.

Andreas

I think maybe I was un-clear. Most of the original post is describing the differences between how the /etc/resolv.conf file is populated based on the host having a static or dynamic ip address.

Asking my question a different way.
How doe's unbound interact with the hosts /etc/resolv.conf file?

How do dns requests arriving at the host from the LAN get directed first to unbound "local-zone: fqdn always_nxdomain" list and then use the "nameservers x.x.x.x" listed in the hosts /etc/resolv.conf file to complete the dsn request?

Please provide example of the unbound.conf statements to get this to happen.

Thank you.

It doesn't really. The resolv.conf file just tells that particular
host where to go to resolve DNS information. It has nothing at all to
do with incoming DNS requests. It may or may not point to an instance
of Unbound.

Hi Ernie,

1. Unbound does not use resolv.conf nor does it depend on your ISP name servers. Instead it does its own DNS resolution by querying internet name servers starting with the DNS root zone. Local zones are looked up before any resolution happens.
2. If you must use your ISP name servers, you must configure a forward-zone option for the root zone (.) pointing to them, and then you need to detect when the ISP name server address(es) change(s) and use the unbound-control forward_remove and forward_add commands to change the settings. (My ISPs have rarely, if ever, changed their DNS server addresses, there is hardly ever a reason to do that. I would just set up the forward-zone and handle DNS changes manually, maybe write a script to translate resolv.conf nameservers to unbound-control commands.)

HTH,

Jan.

    >
    >> Hello list.
    >>
    >> I have installed the unbound port on Freebsd release 11.1. My host gets
    >> an dynamic ip address assigned from the ISP service I am using. This is
    >> all very common and normal. But as we all know, the ISP can change not
    >> only the assigned ip address on the fly but also the dns servers ip
    >> addresses. When this occurs the /etc/resolv.conf file gets updated
    >> automatically on the fly.
    >>
    >> From reading about unbound I get the concept that unbound is designed
    >> for hosts that have static ip addresses. IE; the dns ip addresses have
    >> to be manually placed in /etc/resolv.conf and will not change without
    >> prior written notice.
    >>
    >> For this usage /etc/resolv.conf get populated with
    >> "nameserver 127.0.0.1"
    >> and unbound.conf needs the forward-zone: section with the static dns ip
    >> addresses.
    >
    > which "static dns ip address" do you like to see there?
    >
    >> Now my question is, is there any way to configure unbound so when the
    >> dynimic dns ip addresses change unbound will contuine to work
    >> automatically. IE; no human manual editing of the unbound.conf file.
    > simply do no forwarding at all. Let unbound do it's job:
    > - offer recursiver resolution on 127.0.0.1
    > - resolve names as usual from the root
    > You're not required to *use* the ISP's dnsserver even if they are offered.
    >
    > Andreas
    >
    
    I think maybe I was un-clear. Most of the original post is describing
    the differences between how the /etc/resolv.conf file is populated based
    on the host having a static or dynamic ip address.
    
    Asking my question a different way.
    How doe's unbound interact with the hosts /etc/resolv.conf file?
    
    How do dns requests arriving at the host from the LAN get directed first
    to unbound "local-zone: fqdn always_nxdomain" list and then use the
    "nameservers x.x.x.x" listed in the hosts /etc/resolv.conf file to
    complete the dsn request?
    
    Please provide example of the unbound.conf statements to get this to happen.
    
    Thank you.

Jan Komissar (jkomissa) wrote:

Hi Ernie,

1. Unbound does not use resolv.conf nor does it depend on your ISP name servers. Instead it does its own DNS resolution by querying internet name servers starting with the DNS root zone. Local zones are looked up before any resolution happens.
2. If you must use your ISP name servers, you must configure a forward-zone option for the root zone (.) pointing to them, and then you need to detect when the ISP name server address(es) change(s) and use the unbound-control forward_remove and forward_add commands to change the settings. (My ISPs have rarely, if ever, changed their DNS server addresses, there is hardly ever a reason to do that. I would just set up the forward-zone and handle DNS changes manually, maybe write a script to translate resolv.conf nameservers to unbound-control commands.)

HTH,

How do you tell unbound to go to this public root zone?
Is this root zone an unbound internal hard codded function?

How do you tell unbound to go to this public root zone?
See below.
    Is this root zone an unbound internal hard codded function?
Yes.

Jan Komissar (jkomissa) wrote:

    How do you tell unbound to go to this public root zone?
See below.

There is no below to see.

    Is this root zone an unbound internal hard codded function?
Yes.
    

What os are you running?
Is enabling this internal root zone function a compile time option?
Did you install unbound directly from https://unbound.net ?
Does this function have any thing to do with the hints file?

Beginning to look like the freebsd port of unbound does not have this internal root zone enabled.

The hints file should have it, but even without that, Unbound should have built-in root hints.

If that doesn’t work, you need to inspect the network traffic. It’s possible your ISP is blocking DNS traffic that’s not going to their servers.

You may want to share your unbound.conf (minus identifying features) with the list.

    Jan Komissar (jkomissa) wrote:
    >
    >
    > How do you tell unbound to go to this public root zone?
    > See below.
    
    There is no below to see.
    
    > Is this root zone an unbound internal hard codded function?
    > Yes.
    >
    What os are you running?
    Is enabling this internal root zone function a compile time option?
    Did you install unbound directly from https://unbound.net ?
    Does this function have any thing to do with the hints file?
    
    Beginning to look like the freebsd port of unbound does not have this
    internal root zone enabled.

Jan Komissar (jkomissa) wrote:

The hints file should have it, but even without that, Unbound should have built-in root hints.

If that doesn’t work, you need to inspect the network traffic. It’s possible your ISP is blocking DNS traffic that’s not going to their servers.

I think you just hit the mail on the head with my ISP is blocking DNS traffic that’s not going to their servers.

when I issue drill facebook.com I get rcode NOERROR, but
drill facebook.com @8.8.8.8
I receive error msg Error: error sending query: Error creating socket
I believe 8.8.8.8 is one of googles main dns services. I also tried using the dns ip for at&t and got same results.

Now we both know that things are changing on the public internet to address dos attacks. This is a transparent solution to many people but comes to light with built-in "root zone" function of unbound. This should be brought to the attention of the unbound maintainers so they can remove the built-in "root zone" function from the source as it has become obsolete.

Thanks for you help and insight.

Ernie Luzar via Unbound-users:

when I issue drill facebook.com I get rcode NOERROR, but
drill facebook.com @8.8.8.8
I receive error msg Error: error sending query: Error creating socket
I believe 8.8.8.8 is one of googles main dns services. I also tried using the dns ip for at&t and got same results.

I would switch to an other ISP that not only provide limited/filtered internet access

Andreas

^^^^^^^^^^^^^^^^^^^

"Error creating socket" looks like an entirely different issue than
your interpretation. Something is most likely hosed in your
unbound.conf and/or some other app is interfering.