Semantics of 'forward'

Dear all,

I have an unbound resolver that has worked correctly in several situations but recently failed when I connected it to a new network.

If U is my unbound server, D the DNS server in the network to which U connects (i.e. which U is using), and C a client of U, then I found that:

DNS clients on U receive correct results from D as expected.
But when C requests a resolution result via U, D does not reply.

In other words, D has a setting that drops recursive requests not originating with the requestor.

At least, I think that was what was happening. I had relatively little time to investigate (I was travelling with U and C!). I double-checked that there was full internet connectivity via U from C: it wasn't a TCP/IP layer problem.

Looking at the documentation, forward zones sound like the answer to this problem.

I tried:

forward-zone:
         name: "."
         forward-addr: <IP of D>

-- but this didn't seem to solve the problem. I'm sorry I can't be more specific but I was concentrating on a work-around with very little time.

I have a few questions:

1. Am I right that forward zones are in principle the way to get around D's behaviour? If so, why wasn't it working?
2. Does a forward zone apply to subdomains by default, i.e. if I set up a forward zone for example.org, will foo.example.org get forwarded in the same way?
3. Except that if I have local data for a subdomain such as foo.example.org, does that override the forwarding for example.org, i.e. will unbound use the local data in preference?

Thanks very much in advance for any help you can provide.

Tim

* Tim Kindberg:

DNS clients on U receive correct results from D as expected.
But when C requests a resolution result via U, D does not reply.

In other words, D has a setting that drops recursive requests not
originating with the requestor.

The DNS protocol currently does not support that because it does not
distinguish forwarded from original requests (but there is a draft
which would change this).

So D probably just refuses to respond to EDNS requests which U happens
to send. This would also happen to C if they sent EDNS requests, too.

Thanks Florian.

Is there a way of making U use DNS rather than EDNS to get around this situation? If it uses EDNS for forward zones, that would explain why they didn't solve my problem.

Tim

* Tim Kindberg:

Is there a way of making U use DNS rather than EDNS to get around this
situation? If it uses EDNS for forward zones, that would explain why
they didn't solve my problem.

I don't think so. See the discussion in this thread: