Re: Question about URL being logged by resolver

[Mark Andrews]

People accidentally enter urls as domain names into tools.  
https://app-measurement.com/sdk-exp/A is
a legal, but unusual, domain name consisting of 3 labels 
'https://app-measurement’, 'com/sdk-exp/A’ and ‘.’.

Mark

> On 4 Nov 2023, at 13:29, Nick Tait via bind-users  
> wrote:
> 
> Hi J.
> 
> I'm not sure what the cause of the URLs is, but I can confirm I'm seeing the 
> same URLs in my own logs. The queries originate from multiple devices on my 
> internal network - all Apple devices I think.
> 
> My advice: I wouldn't waste too much effort trying to solve this one, as it 
> is almost certainly something that you will have no control over. E.g. It 
> could be something bogus on a web page that these devices have all accessed?
> 
> Nick.
> 
> 
> On 4/11/23 11:30, J Doe wrote:
>> Hello,
>> 
>> On a Bind 9.18.19 server configured as a recursive resolver, I sometimes see 
>> URL's being noted in the log files.
>> 
>> One such example is:
>> 
>> 02-Nov-2023 23:32:19.435 lame-servers: info: success resolving 
>> 'https://app-measurement.com/sdk-exp/A' after disabling qname minimization 
>> due to 'ncache nxdomain'
>> 
>> This seems unusual to me because Bind usually notes the domain name it is 
>> attempting to resolve, not an URL.  In this particular case, I would expect 
>> to see a notation about "app-measurement.com" and not "http://etc";.
>> 
>> What is the significance of logging the URL and why does this happen in only 
>> some cases ?
>> 
>> Thanks,
>> 
>> - J
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about URL being logged by resolver

[Ondřej Surý]

It means something in your network sent a query containing the literal URL 
below. The message is just misleading - the resolver tries to do QNAME 
minimization on it, it fails, switches to full name which ends with NXDOMAIN 
from root.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 3. 11. 2023, at 23:30, J Doe  wrote:
> 
> Hello,
> 
> On a Bind 9.18.19 server configured as a recursive resolver, I sometimes see 
> URL's being noted in the log files.
> 
> One such example is:
> 
> 02-Nov-2023 23:32:19.435 lame-servers: info: success resolving 
> 'https://app-measurement.com/sdk-exp/A' after disabling qname minimization 
> due to 'ncache nxdomain'
> 
> This seems unusual to me because Bind usually notes the domain name it is 
> attempting to resolve, not an URL.  In this particular case, I would expect 
> to see a notation about "app-measurement.com" and not "http://etc";.
> 
> What is the significance of logging the URL and why does this happen in only 
> some cases ?
> 
> Thanks,
> 
> - J
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How should I configure internal and external DNS servers

[Michael Richardson]

Given VPNs, RemoteAccess and the like, I strongly recommend against split-DNS
configurations.  They were great ideas in 1993, when all sites were concave,
but that's just not the case anymore.

Instead, I recommend having a sub-zone, "internal.example.com", or some other
convenient name.  Put a zone split ("NS" and "DS" records) there, and then
limit who can do queries to this zone by IP address.  You'd acceptlist all of
your VPN sites, the v4 (RFC1918) and v6 (subnet) prefixes for your remote
access clusters.

Split-DNS finally has some actual IETF definition at:
  
https://datatracker.ietf.org/doc/draft-ietf-add-split-horizon-authority/

I'm specifically arguing to do:
  
https://www.ietf.org/archive/id/draft-ietf-add-split-horizon-authority-06.html#name-internal-only-subdomains

It's just so much easier, particularly if you are starting from scratch.


signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Old link in DNSSEC Guide for number of TLDs with DNSSEC

[Kurt Jaeger]

Hi!

In

https://bind9.readthedocs.io/en/v9.18.19/dnssec-guide.html

there's a link to

   https://stats.research.icann.org/dns/tld_report/

which is no longer valid. New data seems to be here:

   https://ithi.research.icann.org/
   ITHI == idenitifier technologies health indicators
   how many TLDs support DNSSEC ?
 https://ithi.research.icann.org/graph-m7.html

-- 
p...@opsec.eu+49 171 3101372Now what ?
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

Thanks for the reply. Interesting.
Option A - It works but I would like to stop maintaining two different 
servers with the same data.

Option B - I have no chance of getting the company to agree to IPv6.
Option C - From your summary, does not appear to remove the requirement 
to maintain the data twice
Option D - No chance of re-zoning internally. It would be a long term 
project like IPv6.

Option E - Agreed. Does not appear to simplify anything
Option F - Looks really interesting. I'll investigate further
Option G - Yes it would be trivial with DNSMasq internally. I don't 
think I have any chance of pushing this through. Also DNSMasq does not 
support replication (but it could be scripted). I could look for other 
solutions but I doubt I would get anywhere in the company.


I'll spend some time investigating option F, thanks.

Nick

On 04/11/2023 02:03, Nick Tait via bind-users wrote:


Hi Nick.

Your current set-up sounds like a fairly common configuration. And 
depending on your requirements there are a number of options that you 
might consider.


But let's start with requirements: I've made some assumptions - please 
advise if I've got any of this wrong?:


  * You have two distinct sets of authoritative servers, which don't
overlap in any way currently. E.g. Servers A (primary/master), B &
C (secondaries/slaves) are authoritative for internal zone
("Bind-internal"); Servers C (primary), D & E (secondaries) are
authoritative for external zone ("Bind-external").
  * The records in Bind-external are a subset of those in
Bind-internal. In other words, for every resource record (not
including SOA & NS records) in Bind-external, there is an
identical record in Bind-internal.
  * Do you have another set of servers that act as recursive resolvers
in your network currently, or do A, B and/or C fulfil that role
currently? (I'm going to assume that A, B & C are used as
recursive resolvers on your internal network for now. It probably
doesn't make a huge difference either way but it is just an extra
factor that needs to be taken into account.)
  * You are not using DNSSEC to sign your zones.
  * Your zone structure is more-or-less flat currently. i.e. You don't
have any delegations to sub-zones.
  * Your primary reason for having separate authoritative servers is
for privacy, rather than simply being a workaround for IPv4
Network Address Translation.

There are a few options worth considering, and I should point out that 
some of these won't fit your requirements, in which case you can 
immediately rule them out. But I believe it is important that the 
decision to rule them out is a conscious one, so you are fully aware 
of the scope/limitations of the solution you end up choosing.


*Option A: Keep using separate sets of authoritative servers*

What you have currently is not a bad configuration. Sure, there is 
additional overhead of having to maintain two separate versions of the 
zone, but it is easy to understand and troubleshoot. If your zones are 
small and are updated infrequently, then this is probably the best 
solution. However the fact you are looking for a better solution 
suggests this isn't the case...


*Option B: Merge the authoritative zones and use IPv6 exclusively for 
internal hosts

*

I only included this because the idea had been put forward already. 
But even if the logistics of assigning public IPv6 addresses to your 
internal hosts was palatable to you, you'd also want to think about 
whether you are comfortable making that information (i.e. the IPv6 
addresses used for internal servers) publicly available? I think most 
organisations wouldn't want to do that?


*Option C: Merge servers but use views to serve separate (existing) 
zone files*


If your goal was consolidation of servers while keeping the existing 
internal and external zones separate, then this might be worth looking 
at. But you haven't mentioned consolidation as a requirement so I'm 
going to skip over this one. Also it doesn't solve the problem of 
having multiple zones to maintain.


*Option D: Simple delegation*

Depending on whether there is opportunity to do some zone refactoring, 
you might consider something like this...


  * In Bind-external, create a new zone: internal.example.com
  * Use permissions (e.g. allow-query) to limit access to
internal.example.com to only internal clients
  * For each zone record in Bind-internal that doesn't exist in
Bind-external, create a CNAME record in Bind-external that points
to the same name in internal.example.com zone.
  * You can then get rid of Bind-internal zone. (The servers could
still be used as recursive resolvers though.)

Then, if x.example.com was a name that was previously defined only in 
Bind-internal:


  * Internally if you attempt to resolve x.example.com, the result
will be a CNAME that points to x.internal.example.com, which
resolves to the 10.x.x.x IP address.
  * Exte

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

As on other replies, a different internal zone is a huge project for the 
company, not a quick win, unfortunately.


On 04/11/2023 08:55, Michael Richardson wrote:

Given VPNs, RemoteAccess and the like, I strongly recommend against split-DNS
configurations.  They were great ideas in 1993, when all sites were concave,
but that's just not the case anymore.

Instead, I recommend having a sub-zone, "internal.example.com", or some other
convenient name.  Put a zone split ("NS" and "DS" records) there, and then
limit who can do queries to this zone by IP address.  You'd acceptlist all of
your VPN sites, the v4 (RFC1918) and v6 (subnet) prefixes for your remote
access clusters.

Split-DNS finally has some actual IETF definition at:
   
https://datatracker.ietf.org/doc/draft-ietf-add-split-horizon-authority/

I'm specifically arguing to do:
   
https://www.ietf.org/archive/id/draft-ietf-add-split-horizon-authority-06.html#name-internal-only-subdomains

It's just so much easier, particularly if you are starting from scratch.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

Unfortunately, redesigning the internal zone is way beyond the scope of 
what I can do, but thanks for the info.


On 04/11/2023 13:40, Greg Choules wrote:

Hi Nick.
First question, does the internal zone *have* to keep the same name? 
As has been said already, this is a fairly common setup done by people 
a long time ago who usually didn't think through the consequences of 
their actions. What follows assumes you could change the name of the 
internal zone.


What would be better (IMHO) is for you to keep "example.com 
" as your external zone in an external (hopefully 
in a DMZ) primary server, serving the world with public addresses they 
need to reach, and internally create a new zone - 
"internal.example.com " (maybe also other 
"somethingX.example.com " too) as your 
internal zone in an internal primary server for serving internal 
clients with the addresses they need.


Internal clients send recursive queries (RD bit set to 1, hence why 
recursion needs to be enabled) to an internal server, if you can 
separate the functions physically: this server is a resolver (aka 
cache) because of that.
That resolver *could* get its internal data from a separate, internal 
primary server in a number of ways - stub, static-stub, secondary or 
forward zones. I won't go into the differences right now.
The internal primary server just sits there and provides answers for 
internal names. It would probably not need to have recursion enabled,


If you only have a single box internally (though I'd recommend at 
least two, for resilience) they can be both resolver *and* 
authoritative in the same box. You don't need views. In this case the 
primary zone is defined on this box rather than on a different box. If 
you have another one and want it to behave identically it could be a 
secondary server to this primary


If the resolver receives queries for non-internal names - 
e.g.public.example.com , 
www.facebook.com  or anything else, they 
won't match the internal zone and thus they are candidates for 
external resolution. It could contact the outside world in a number of 
ways, such as by direct recursion, forwarding to your own forwarder in 
a DMZ (which then does the recursion) or forwarding to a public 
service such as Google (others exist).


The principle is that the internal zone(s) is a subdomain of the 
external zone and hence more specific: a bit like adding host routes 
in a router. Anything that is not in "internal.example.com 
" the resolver deals with as if it were 
anything else in the world. That includes anything in "example.com 
", for which it queries the external primary 
server, just like anyone else in the world would.


The external primary server does not need recursion enabled because 
queries it receives (from resolvers) will have the RD bit set to 0.


One other thing you ought to do in the external primary server, in the 
zone "example.com ", is to delegate 
"internal.example.com " to your internal 
authoritative servers. This doesn't suddenly mean that the world can 
make queries for "name.internal.example.com 
" because they won't be able to 
reach your internal servers to get queries to them. Even if they 
could, an answer like 10.10.10.10 would be meaningless.


The reason for the delegation is DNSSEC. If you enable DNSSEC 
validation on your resolver, which is a good idea, it would work fine 
for the rest of the world. But to validate internal names it needs to 
be able to follow the path to the internal authoritative servers, all 
the way down from the root. So it needs "example.com 
" to tell it where "internal.example.com 
" lives, then the chain is complete. This 
is a bit simplistic, but that's the general idea.


If you cannot change the internal zone name and it *must* stay the 
same as the external zone name, life gets a little more complicated 
but it's still workable.


Internally you would have to split DNS functions into two sets of 
servers - recursive and authoritative. These could be different views 
on the same boxes, but that starts getting tricky and I would 
recommend separate IP addresses for each function if that's the path 
you have to take.


The general principle is still the same: internal names are more 
specific subdomains of the external zone. But in this case each 
internal name would need to be its own zone (stub, static-stub etc.) 
and the resolver would need to be told how to obtain answers for these 
zones. The vital point is that you *must not* configure the zone 
"example.com " internally because that will 
obscure the external version completely. Zones like 
"internal-www.example.com ", 
"in

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 04.11.2023 um 19:41:44 Uhr schrieb Nick Howitt via bind-users:

> Thanks for the reply. Interesting.
> Option A - It works but I would like to stop maintaining two
> different servers with the same data.
> Option B - I have no chance of getting the company to agree to IPv6.

Then you are in a stonehenge company. Tell them about the problem and
that relying on IPv4 creates additional work.
My recommendation: Let the people who refuse IPv6 do the DNS work if
possible. :-)

> Option G - Yes it would be trivial with DNSMasq internally. I don't 
> think I have any chance of pushing this through. Also DNSMasq does
> not support replication (but it could be scripted).

Is it possible to use dnsmasq as the master (does it support zone
transfer?) and bind as a slave?
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How should I configure internal and external DNS servers

[Andrew Latham]

* That sounds like a sadly normal implementation but yes you can do better
* Views is a good place to look https://kb.isc.org/docs/aa-00851
* Make sure to investigate how the company VPN services handle DNS as it
may surprise you

On Fri, Nov 3, 2023 at 9:52 AM Nick Howitt via bind-users <
bind-users@lists.isc.org> wrote:

> Hi,
>
> I am fairly new to bind but I am thinking my company's use of it is
> sub-optimal. We have two bind masters (and a few slaves), one for
> internal use so all our internal servers point to it or its slaves as
> their DNS resolvers. I will call the internal one bind-internal and the
> external one bind-external.
>
> Bind-internal is set up as authoritative for the domain example.com.
> Bind-external is also set up as authoritative for example.com.
>
> Bind-internal has all sorts of entries resolving in the 10.30, 10.40 and
> other private ranges, but it also has entries resolving to our public
> IP's e.g. demo.example.com resolves to 1.2.3.4 (terminated by an F5),
> which is one of our public ips (munged). As this site is externally
> accessible as well, we also have to put an identical entry in
> bind-external so we end up having many identical entries in
> bind-internal and bind-external. We also have some other domains covered
> by bind-internal with external IPs, but externally they are covered by
> the domain host's DNS and they have the same issue where in
> bind-internal we have some public IP's which are also in the domain
> host's DNS for external access.
>
> I have a feeling this is a sub-optimal setup, having to maintain
> external IPs in both bind-internal and bind-external. Does it make sense
> to stop bind-internal from being authoritative and make it a
> resolver/caching name server? This way, if it does not find an entry in
> bind-internal it will then go out to either bind-external or the domain
> host's DNS to get the answer from the authoritative servers and then
> there is no need to maintain external IPs in bind internal.
>
> TIA,
>
> Nick
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>


-- 
- Andrew "lathama" Latham -
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How should I configure internal and external DNS servers

[Greg Choules via bind-users]

Hi Nick.
First question, does the internal zone *have* to keep the same name? As has
been said already, this is a fairly common setup done by people a long time
ago who usually didn't think through the consequences of their actions.
What follows assumes you could change the name of the internal zone.

What would be better (IMHO) is for you to keep "example.com" as your
external zone in an external (hopefully in a DMZ) primary server, serving
the world with public addresses they need to reach, and internally create a
new zone - "internal.example.com" (maybe also other "somethingX.example.com"
too) as your internal zone in an internal primary server for serving
internal clients with the addresses they need.

Internal clients send recursive queries (RD bit set to 1, hence why
recursion needs to be enabled) to an internal server, if you can separate
the functions physically: this server is a resolver (aka cache) because of
that.
That resolver *could* get its internal data from a separate, internal
primary server in a number of ways - stub, static-stub, secondary or
forward zones. I won't go into the differences right now.
The internal primary server just sits there and provides answers for
internal names. It would probably not need to have recursion enabled,

If you only have a single box internally (though I'd recommend at least
two, for resilience) they can be both resolver *and* authoritative in the
same box. You don't need views. In this case the primary zone is defined on
this box rather than on a different box. If you have another one and want
it to behave identically it could be a secondary server to this primary

If the resolver receives queries for non-internal names -
e.g.public.example.com, www.facebook.com or anything else, they won't match
the internal zone and thus they are candidates for external resolution. It
could contact the outside world in a number of ways, such as by direct
recursion, forwarding to your own forwarder in a DMZ (which then does the
recursion) or forwarding to a public service such as Google (others exist).

The principle is that the internal zone(s) is a subdomain of the external
zone and hence more specific: a bit like adding host routes in a router.
Anything that is not in "internal.example.com" the resolver deals with as
if it were anything else in the world. That includes anything in "
example.com", for which it queries the external primary server, just like
anyone else in the world would.

The external primary server does not need recursion enabled because queries
it receives (from resolvers) will have the RD bit set to 0.

One other thing you ought to do in the external primary server, in the zone
"example.com", is to delegate "internal.example.com" to your internal
authoritative servers. This doesn't suddenly mean that the world can make
queries for "name.internal.example.com" because they won't be able to reach
your internal servers to get queries to them. Even if they could, an answer
like 10.10.10.10 would be meaningless.

The reason for the delegation is DNSSEC. If you enable DNSSEC validation on
your resolver, which is a good idea, it would work fine for the rest of the
world. But to validate internal names it needs to be able to follow the
path to the internal authoritative servers, all the way down from the root.
So it needs "example.com" to tell it where "internal.example.com" lives,
then the chain is complete. This is a bit simplistic, but that's the
general idea.

If you cannot change the internal zone name and it *must* stay the same as
the external zone name, life gets a little more complicated but it's still
workable.

Internally you would have to split DNS functions into two sets of servers -
recursive and authoritative. These could be different views on the same
boxes, but that starts getting tricky and I would recommend separate IP
addresses for each function if that's the path you have to take.

The general principle is still the same: internal names are more specific
subdomains of the external zone. But in this case each internal name would
need to be its own zone (stub, static-stub etc.) and the resolver would
need to be told how to obtain answers for these zones. The vital point is
that you *must not* configure the zone "example.com" internally because
that will obscure the external version completely. Zones like "
internal-www.example.com", "internal-mail.example.com" and what have you
are fine because they are more specific than the general "example.com",
queries for which will just fall through to the outide world along with any
other name.

That was a bit of an essay, but I hope at least some of it made sense.

Cheers, Greg

On Fri, 3 Nov 2023 at 16:33, Nick Howitt via bind-users <
bind-users@lists.isc.org> wrote:

> Hmm, I'll admit to only skim reading it but is seems quite complicated
> for what I was hoping for. It would be trivial if I could change the
> bind-internal machine to using dnsmasq (ugh!). Then the bind-internal
> machine would 

RE: How should I configure internal and external DNS servers

[Verne Britton]

you haven’t mentioned your firewall or router config between the private 
corporate network and the public internet (or I missed it).

Cisco firewalls and I bet others too, have a very interesting and powerful 
capability – to examine and edit/change packet data (payload data) on the fly 
in real-time --- that is, when the firewall sees a dns lookup/resolver response 
coming in from the outside, and notices the internal dns ‘answer’ is for an IP 
address that is mapped/translated in the firewall to a 10. address (just an 
example), the firewall will edit that payload and replace the public IP with 
the 10. address so the internal PC (or helper/resolver internal server) that 
asked for the dns lookup will receive the correct 10. answer – to avoid NAT 
hairpinning (?) -- or so I’m told by my co-workers  😊

what this means, if your equipment has this feature, is internal lookups can go 
to your public dns server and will receive the appropriate internal answer 
while outside lookups for the same entry will receive a public IP answer – thus 
you don’t need a duplicate zone internally just to hand out 10. addresses for 
internal servers/equipment for use by internal PCs.  Did you mention you have 
internal entries for internal use that don’t exist in the public zone --- if so 
then decide if exposing just the internal name and its matching 10. address to 
the public is an issue – note that external users, assuming they can guess that 
secret internal name, will only learn the 10. address but hopefully your 
routers and firewalls, as well as the outside user’s equipment, will never 
allow an outside user to connect into your internal network using a 10. address 
for that connection.  That is, its possible there is no harm in having your 
public zone containing the secret name and its 10. address.

Also bind supports ACLs on many items (I forget which one for resolution 
exactly) so if you want, you can have your public dns servers be used as 
resolvers by all your internal 10. PCs while not allowing resolution by any 
outside aka public connections (that is, only serving its authoritative zones 
to public queries).  Not sure if your optional goal was to eliminate any 
internal dns server of any type. And as others have said I believe, if you do 
wish to use bind internally as just a resolver, that’s very easy to set up – 
plus it lets you not have to learn and manage two different dns packages.


Verne Britton

From: bind-users  On Behalf Of Nick Howitt 
via bind-users [*]
Sent: Saturday, November 4, 2023 3:42 PM
To: bind-users@lists.isc.org
Subject: Re: How should I configure internal and external DNS servers

Thanks for the reply. Interesting.
Option A - It works but I would like to stop maintaining two different servers 
with the same data.
Option B - I have no chance of getting the company to agree to IPv6.
Option C - From your summary, does not appear to remove the requirement to 
maintain the data twice
Option D - No chance of re-zoning internally. It would be a long term project 
like IPv6.
Option E - Agreed. Does not appear to simplify anything
Option F - Looks really interesting. I'll investigate further
Option G - Yes it would be trivial with DNSMasq internally. I don't think I 
have any chance of pushing this through. Also DNSMasq does not support 
replication (but it could be scripted). I could look for other solutions but I 
doubt I would get anywhere in the company.

I'll spend some time investigating option F, thanks.

Nick
On 04/11/2023 02:03, Nick Tait via bind-users wrote:

Hi Nick.

Your current set-up sounds like a fairly common configuration. And depending on 
your requirements there are a number of options that you might consider.

But let's start with requirements: I've made some assumptions - please advise 
if I've got any of this wrong?:

  *   You have two distinct sets of authoritative servers, which don't overlap 
in any way currently. E.g. Servers A (primary/master), B & C 
(secondaries/slaves) are authoritative for internal zone ("Bind-internal"); 
Servers C (primary), D & E (secondaries) are authoritative for external zone 
("Bind-external").
  *   The records in Bind-external are a subset of those in Bind-internal. In 
other words, for every resource record (not including SOA & NS records) in 
Bind-external, there is an identical record in Bind-internal.
  *   Do you have another set of servers that act as recursive resolvers in 
your network currently, or do A, B and/or C fulfil that role currently? (I'm 
going to assume that A, B & C are used as recursive resolvers on your internal 
network for now. It probably doesn't make a huge difference either way but it 
is just an extra factor that needs to be taken into account.)
  *   You are not using DNSSEC to sign your zones.
  *   Your zone structure is more-or-less flat currently. i.e. You don't have 
any delegations to sub-zones.
  *   Your primary reason for having separate authoritative servers is for 
privacy, rather than simpl