Forward zone vs stub

Unbound
1

Hi,

I want to use unbound as a caching/recursive DNS server.
However I want unbound to forward all queries about my local domains to the local authoritative DNS servers.

I have setup stub-zones for that

stub-zone:
name: “example.com”
stub-addr: 10.0.0.10

stub-zone:
name: “10.in-addr.arpa”
stub-addr: 10.0.0.10

Is there a way to make this include all subdomains as well?
foo1.example.com
foo2.example.com
bar.foo1.example.com
0.10.in-addr.arpa
1.10.in.addr.arpa
1.1.10.in-addr.arpa
etc

Do I have to specify all zones?

Also I would like to disable caching for these domains or maybe set
a cache-max-ttl but only for these domains. I don’t want local users to wait for a zone to expire to get new entries.
Is this possible?

Should I use forward-zone instead of stub-zone?

regards,

Giannis

2

I have setup stub-zones for that

stub-zone:
    name: "example.com"
    stub-addr: 10.0.0.10

stub-zone:
    name: "10.in-addr.arpa"
    stub-addr: 10.0.0.10

Is there a way to make this include all subdomains as well?

take the usual "dns-way":
at 10.0.0.10 setup NS entries that delegate foo1.example.com to nameserver 10.0.0.10

Do I have to specify all zones?

no

Andreas

3

Thanks for the answer.

Well the problem is that the zone files include external authoritative DNS servers as well (often with different views).

I don't want unbound to contact them at all. It should only contact local authoritative servers.

Giannis

4

Hi,

I have setup stub-zones for that

stub-zone:
    name: "example.com"
    stub-addr: 10.0.0.10

stub-zone:
    name: "10.in-addr.arpa"
    stub-addr: 10.0.0.10

Is there a way to make this include all subdomains as well?

take the usual "dns-way":
at 10.0.0.10 setup NS entries that delegate foo1.example.com to nameserver 10.0.0.10

Do I have to specify all zones?

no

Andreas

Thanks for the answer.

Well the problem is that the zone files include external authoritative DNS servers as well (often with different views).
I don't want unbound to contact them at all. It should only contact local authoritative servers.

I think you need to be significantly more specific in what you're doing here.

You have an external version of "example.com", presumably with nameservers on the public Internet.

You also have an internal version of "example.com", presumably with nameservers on the inside, specifically 10.0.0.10.

Which zone file is it that contains "external authoritative DNS servers as well"?

And if you're using views (apart from the "God help you"-part), then you need to explain that, including your matching rules and what it is that you're trying to achieve.

Regards,

Johan (firm believer in "DNS should be kept simple")

5

You're right about the views. The views are on BIND (authoritative) and have different data for external clients.

What I really want is my internal users to use unbound servers with the following options:

a) unbound should forward all requests for local zones (*.example.com, 123.123.x.x, 10.x.x.x) to local authoritative servers (BIND)
b) the local zones should not be cached on the unbound because I want the updates to be automatically propagated.

In another similar setup (but with bind only) the the caching server is also secondary for each zone, but is not listed in the NS records.

thanks again

Giannis

6

Hi again,

I think you need to be significantly more specific in what you're doing here.

You have an external version of "example.com", presumably with nameservers on the public Internet.

You also have an internal version of "example.com", presumably with nameservers on the inside, specifically 10.0.0.10.

Which zone file is it that contains "external authoritative DNS servers as well"?

And if you're using views (apart from the "God help you"-part), then you need to explain that, including your matching rules and what it is that you're trying to achieve.

Regards,

Johan (firm believer in "DNS should be kept simple")

You're right about the views. The views are on BIND (authoritative) and have different data for external clients.

What I really want is my internal users to use unbound servers with the following options:

a) unbound should forward all requests for local zones (*.example.com, 123.123.x.x, 10.x.x.x) to local authoritative servers (BIND)

Yes, I get that. However, I'd strongly advise that you don't call that to "forward". "Forwarding" is something you implement with "forward-zone:", which is distinctly different from what you do with a "stub-zone:". Forwarding by definition is one recursive server forwarding a query to another recursive server. That's not what's happening when you're using stub-zone:, which is basically pre-loading the cache with static entries for the nameservers of a particular zone.

b) the local zones should not be cached on the unbound because I want the updates to be automatically propagated.

This is yet another requirement. However, let's ignore that for the moment, as that's orthogonal to the issue of your stubs.

In another similar setup (but with bind only) the the caching server is also secondary for each zone, but is not listed in the NS records.

Yeah, I know that's a popular party trick, but let's not go there as this is the Unbound-list.

However, you never answered my question: Which zone file is it that contains "external authoritative DNS servers as well"?

Regards,

Johan

7

You're right about the views. The views are on BIND (authoritative) and have different data for external clients.

What I really want is my internal users to use unbound servers with the following options:

a) unbound should forward all requests for local zones (*.example.com, 123.123.x.x, 10.x.x.x) to local authoritative servers (BIND)

Yes, I get that. However, I'd strongly advise that you don't call that to "forward". "Forwarding" is something you implement with "forward-zone:", which is distinctly different from what you do with a "stub-zone:". Forwarding by definition is one recursive server forwarding a query to another recursive server. That's not what's happening when you're using stub-zone:, which is basically pre-loading the cache with static entries for the nameservers of a particular zone.

Yes I've already read in the manual that stub-zone is really what I want and that's why I've setup stub-zones and not forward-zones. It does it for the zones but not for the sub-zones. Should I list every zone/sub-zone or is there a trick?

b) the local zones should not be cached on the unbound because I want the updates to be automatically propagated.

This is yet another requirement. However, let's ignore that for the moment, as that's orthogonal to the issue of your stubs.

In another similar setup (but with bind only) the the caching server is also secondary for each zone, but is not listed in the NS records.

Yeah, I know that's a popular party trick, but let's not go there as this is the Unbound-list.

However, you never answered my question: Which zone file is it that contains "external authoritative DNS servers as well"?

Regards,

Johan

The authoritative server keeps two files for most of the zones.
On each view they load different file with different entries (zone.pub, zone.priv)

The unbound is on the internal view so it queries for zone.priv.

The external authoritative NS records are on both files. You're suggesting I should alter .priv zones to list only
internal DNS servers? That is a thought but I should think of it's implications it might have on secondary authoritative servers...

G

8

Hi,

You're right about the views. The views are on BIND (authoritative) and have different data for external clients.

What I really want is my internal users to use unbound servers with the following options:

a) unbound should forward all requests for local zones (*.example.com, 123.123.x.x, 10.x.x.x) to local authoritative servers (BIND)

Yes, I get that. However, I'd strongly advise that you don't call that to "forward". "Forwarding" is something you implement with "forward-zone:", which is distinctly different from what you do with a "stub-zone:". Forwarding by definition is one recursive server forwarding a query to another recursive server. That's not what's happening when you're using stub-zone:, which is basically pre-loading the cache with static entries for the nameservers of a particular zone.

Yes I've already read in the manual that stub-zone is really what I want and that's why I've setup stub-zones and not forward-zones. It does it for the zones but not for the sub-zones. Should I list every zone/sub-zone or is there a trick?

b) the local zones should not be cached on the unbound because I want the updates to be automatically propagated.

This is yet another requirement. However, let's ignore that for the moment, as that's orthogonal to the issue of your stubs.

In another similar setup (but with bind only) the the caching server is also secondary for each zone, but is not listed in the NS records.

Yeah, I know that's a popular party trick, but let's not go there as this is the Unbound-list.

However, you never answered my question: Which zone file is it that contains "external authoritative DNS servers as well"?

Regards,

Johan

The authoritative server keeps two files for most of the zones.
On each view they load different file with different entries (zone.pub, zone.priv)

You didn't answer the question of which matching rules you're using for your views. So, not trying to be overly picky here, but when someone tries to help you and to be able to do that asks specific questions about your setup then you really should try to answer those questions, because otherwise... I cannot help.

The unbound is on the internal view so it queries for zone.priv.

So my guess here is that you're matching on the src address. Don't Do That(tm). If you have to use views (you don't) then match on destination, i.e. regard your servers as multiple distinct nameservers with individual addresses collapsed into a single box. Then it becomes quite obvious that you should use distinct IP addresses for the nameserver for the internal view and the nameserver for the external view.

The external authoritative NS records are on both files. You're suggesting I should alter .priv zones to list only
internal DNS servers?

No, I'm suggesting that you should alter the internal zone to only list servers that are authoritative for the internal zone. The internal and external versions of the zone are distinct, but they must each be internally consistent otherwise you'll break DNS coherency.

That is a thought but I should think of it's implications it might have on secondary authoritative servers...

As long as you don't go down the rabbit hole of trying to use the same nameserver address for multiple views, with multiple roles, you'll be fine. If you're using the same address, and do src address matching on the queries, and intend to keep it that way... then I'll have to leave you to your current and upcoming pain.

Regards,

Johan

9

However, you never answered my question: Which zone file is it that contains "external authoritative DNS servers as well"?

Regards,

Johan

The authoritative server keeps two files for most of the zones.
On each view they load different file with different entries (zone.pub, zone.priv)

You didn't answer the question of which matching rules you're using for your views. So, not trying to be overly picky here, but when someone tries to help you and to be able to do that asks specific questions about your setup then you really should try to answer those questions, because otherwise... I cannot help.

I'm not trying to be picky at all. I've tried to answer your question "Which zone file is it that contains..."
that's why I' ve told about the zone files.

So my guess here is that you're matching on the src address. Don't Do That(tm). If you have to use views (you don't) then match on destination, i.e. regard your servers as multiple distinct nameservers with individual addresses collapsed into a single box. Then it becomes quite obvious that you should use distinct IP addresses for the nameserver for the internal view and the nameserver for the external view.

Correct, I'm matching according to source address of clients. I've never thought of using distinct IPs on the DNS server to serve different zones since I had the views feature. Also I'm not quite sure if a single instance of BIND can do that but that's not a problem of this list.

The external authoritative NS records are on both files. You're suggesting I should alter .priv zones to list only
internal DNS servers?

No, I'm suggesting that you should alter the internal zone to only list servers that are authoritative for the internal zone. The internal and external versions of the zone are distinct, but they must each be internally consistent otherwise you'll break DNS coherency.

So if internal NS servers are the only authoritative for the internal zone, then only the internal NS should be listed correct? Doesn't this break DNS coherency as you say? I've lost you on this.

That is a thought but I should think of it's implications it might have on secondary authoritative servers...

As long as you don't go down the rabbit hole of trying to use the same nameserver address for multiple views, with multiple roles, you'll be fine. If you're using the same address, and do src address matching on the queries, and intend to keep it that way... then I'll have to leave you to your current and upcoming pain.

Regards,

Johan

I still don't get the advantages on using different IPs on the authoritative NS server instead of src matching.
So far it has served as well. If you could point to some documentation with complete setup and advantages I would be happy to read and see the whole picture.

Giannis

10

Hi,

That is a thought but I should think of it's implications it might have on secondary authoritative servers...

As long as you don't go down the rabbit hole of trying to use the same nameserver address for multiple views, with multiple roles, you'll be fine. If you're using the same address, and do src address matching on the queries, and intend to keep it that way... then I'll have to leave you to your current and upcoming pain.

Regards,

Johan

I still don't get the advantages on using different IPs on the authoritative NS server instead of src matching.
So far it has served as well. If you could point to some documentation with complete setup and advantages I would be happy to read and see the whole picture.

Let me put it this way:

One of your users complain that a nameserver is giving out the wrong response. Which nameserver and what query you ask. The user says "the nameserver at [wherever] responds wrongly when I query it for [qname] [qtype]. Now what do you do? Well, you do this:

dig @[wherever] [qname] [qtype]

Everything is fine, right? Except that if you do source matching then this nameserver may treat you and the user differently so you will never see the problem unless the user actually reports it.

Now replace the user with an expensive box that doesn't complain (or a user that doesn't complain for that matter). I.e. the only way to KNOW how the nameserver behaves is to put on your roller-blades, skate over to the next building where the user is, unplug his machine, plug in your laptop and test using HIS IP address. That's not convenient for debugging and it is completely impossible to monitor.

On the Internet it is possible to do so-called "source routing". For some reason that's not much in favour. The entire Internet works on routing based on where the packet is going, not from where it is coming. Same problem, at the bottom.

Here's the five cent summary of what I think you should do with your setup and your problems. I may have misunderstood a detail or two but I think this ought to work much better:

1. Drop all your views. That's mostly a vendor lock-in that you don't need these days.

2. Run separate auth nameservers for the internal and external versions of the zone. Whether that's separate physical boxes or if you're just replacing the views with separate virtual machines is up to you.

3. Use "stub-zone:" to direct your recursive server to the internal version of the zone (you're already doing this).

4. [If needed] Use "forward-zone:" to arrange forwarding to the outside if your firewall requires that.

5. If or when you do DNSSEC, use the same keys for both internal and external version of zone, and do validation in the recursive server; both versions of the zone will validate nicely, to the benefit of both external and internal users of your data.

Done.

But now I really must get back to what I really should be doing today.

Regards,

Johan

11

Thanks for your help. I will really think about the setup you 're proposing.

thanks again for your time.

Giannis

12

I agree with the below story line.....

1. Drop all your views. That's mostly a vendor lock-in that you don't need these days.

2. Run separate auth nameservers for the internal and external versions of the zone. Whether that's separate physical boxes or if you're just replacing the views with separate virtual machines is up to you.

3. Use "stub-zone:" to direct your recursive server to the internal version of the zone (you're already doing this).

4. [If needed] Use "forward-zone:" to arrange forwarding to the outside if your firewall requires that.

5. If or when you do DNSSEC, use the same keys for both internal and external version of zone, and do validation in the recursive server; both versions of the zone will validate nicely, to the benefit of both external and internal users of your data.

Done.

You forgot to add that you need to load the trust anchor for the internal only
zone loaded on the internal resolvers. This is assuming the internal
zone is not visible in the external view. I guess if you leave an empty
"internal" zone out in public, (with NS and DS) then you could
potentially skip this part, but I have never tested that.

But now I really must get back to what I really should be doing today.

So say we all :slight_smile:

Paul

13

Hi Paul,

I agree with the below story line.....

1. Drop all your views. That's mostly a vendor lock-in that you don't need these days.

2. Run separate auth nameservers for the internal and external versions of the zone. Whether that's separate physical boxes or if you're just replacing the views with separate virtual machines is up to you.

3. Use "stub-zone:" to direct your recursive server to the internal version of the zone (you're already doing this).

4. [If needed] Use "forward-zone:" to arrange forwarding to the outside if your firewall requires that.

5. If or when you do DNSSEC, use the same keys for both internal and external version of zone, and do validation in the recursive server; both versions of the zone will validate nicely, to the benefit of both external and internal users of your data.

Done.

You forgot to add that you need to load the trust anchor for the internal only
zone loaded on the internal resolvers. This is assuming the internal
zone is not visible in the external view. I guess if you leave an empty
"internal" zone out in public, (with NS and DS) then you could
potentially skip this part, but I have never tested that.

No, that's not needed. As long as you use the SAME keys (as I said) when signing the internal and the external zones the signature chain from the public root, via the DS in the external parent, to the internal signed zone (that you find through the stub-zone: declaration) will work just fine. I've used that for years (after Wouter long ago fixed a bug for me to make it work).

You only need the trust anchor for root, nothing else, for validation of the internal version of "example.com".

Umm, well, now I see what you actually wrote, "internal only zone". My assumption (based on his example) was that the zones exist in a public version and an internal version, i.e. "example.com" does exist on the public side (as well as the internal side), and does have a DS. For zones that do not exist on the public side (like RFC1918 reverses, if you really need DNSSEC validation for them) your point is correct.

But now I really must get back to what I really should be doing today.

So say we all :slight_smile:

And we all fail :wink:

Johan