Re:

[Crist Clark]

You need to explicitly define the root zone. Last I knew, BIND still
gets the root zone hardcoded into the executable and will try to Do
the Right Thing and find the root on its own even if the administrator
does not define one or provide hints.

You need something like,

zone "." {
type master;
file "empty.db";
};


On Tue, Feb 19, 2019 at 10:29 AM Roberto Carna  wrote:
>
> Dear Matus and Kevin, please tell me if it's OK if I do thsi:
>
> named.conf:
> include "/etc/bind/named.conf.default-zones";
>
> named.conf.default-zones:
> recursion yes;
> zone "teamviewer.com" {
> type forward;
> forwarders { 8.8.8.8; };
> };
>
> named.conf.local:
> 
>
> I define "recursion yes" in named.conf.default-zones.
>
> Thanks again, regards !!!
>
> El mar., 19 feb. 2019 a las 15:13, Matus UHLAR - fantomas via bind-users 
> () escribió:
>>
>> On 19.02.19 09:45, Roberto Carna wrote:
>> >Dear Kevin, I am sorry but I didn't see your past response.
>> >
>> >Please can you show me with an example what you say: "Define root zone.
>> >Delegate teamviewer.com from root. Define teamviewer.com as 'type forward'".
>> >
>> >An also what is the benefit in defining a root zone with the teamviewer.com
>> >delegated into it??? Because I put to work this zone just as a forward
>> >zone, without a root zone definition.
>>
>> the benefit is it does exactly what you want.
>> the "teamviewer.com" zone of type forward causes DNS resolution of 
>> teamviewer.com
>> domain.
>> the root zone effectively disables everything else (because bind thinks
>> nothing else exists).
>>
>> >El lun., 18 feb. 2019 a las 17:00, Kevin Darcy ()
>> >escribió:
>> >
>> >> I've already posted a solution for this. Basically, "Define root zone.
>> >> Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
>> >> forward'".
>> >>
>> >> "Recursion yes" is implied. No views necessary. It doesn't make any sense
>> >> anyway, to have the same match-clients list for all of one's views, since
>> >> the first one matched is the one that's used.
>> >>
>> >> Did you not see my response, or did you perhaps dislike the approach I
>> >> suggested?
>> >>
>> >> There was some subsequent discussion about not relying on DNS resolution
>> >> as one's *only* control over what sites one's clients can or cannot 
>> >> access.
>> >> While I agree with that, my position is that there's nothing wrong with
>> >> controlling DNS resolution, in addition to other controls.
>>
>> --
>> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>> Warning: I wish NOT to receive e-mail advertising to this address.
>> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>> M$ Win's are shit, do not use it !
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS load balancing: UDP or TCP ?

[Nico CARTRON]

On 19-Feb-2019 20:00 CET,  wrote:

> Agree with Tony on TCP not going to be tried. Have you looked at using
> anycast? It is not true load balancing but it allows you to stand up
> multiple DNS servers that “shares” a single IP address.

or just use a software load-balancer which has been designed to deal
specifically with DNS, i.e. dnsdist - as mentioned by Tony already :)

-- 
Nico

> On Wed, Feb 20, 2019 at 12:25 AM Tony Finch  wrote:
> 
> > Roberto Carna  wrote:
> >
> > > Dear, I have to balance two DNS servers for a special reason.
> >
> > https://www.powerdns.com/dnsdist.html
> >
> > > The DNS clients are a mix of Windows, Cisco and Linux machines, so I
> > > think they ask for a FQDN using UDP and after that -if there is no
> > > response-, they ask the same FQDN using TCP, and so the load balancing
> > > will be succesful.
> >
> > No, fallback to TCP relies on receiving a truncated UDP response. You
> > never want a DNS client to be waiting around for a response that will
> > not arrive.
> >
> > Tony.
> > --
> > f.anthony.n.finchhttp://dotat.at/
> > Rockall, Malin: Southeast veering southwest 6 to gale 8, occasionally 5
> > later.
> > Rough or very rough. Rain. Moderate or poor.
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >

> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS load balancing: UDP or TCP ?

[Kevin Darcy]

If you go with Anycast via BGP, make sure your network infrastructure has
"multipath" enabled, otherwise the traffic will be skewed to one node or
the other.
https://tools.ietf.org/id/draft-lapukhov-bgp-ecmp-considerations-01.html is
one source which summarizes some of the literature and standards on the
subject.


- Kevin

On Tue, Feb 19, 2019 at 2:01 PM Josh Kuo  wrote:

> Agree with Tony on TCP not going to be tried. Have you looked at using
> anycast? It is not true load balancing but it allows you to stand up
> multiple DNS servers that “shares” a single IP address.
>
> On Wed, Feb 20, 2019 at 12:25 AM Tony Finch  wrote:
>
>> Roberto Carna  wrote:
>>
>> > Dear, I have to balance two DNS servers for a special reason.
>>
>> https://www.powerdns.com/dnsdist.html
>>
>> > The DNS clients are a mix of Windows, Cisco and Linux machines, so I
>> > think they ask for a FQDN using UDP and after that -if there is no
>> > response-, they ask the same FQDN using TCP, and so the load balancing
>> > will be succesful.
>>
>> No, fallback to TCP relies on receiving a truncated UDP response. You
>> never want a DNS client to be waiting around for a response that will
>> not arrive.
>>
>> Tony.
>> --
>> f.anthony.n.finchhttp://dotat.at/
>> Rockall, Malin: Southeast veering southwest 6 to gale 8, occasionally 5
>> later.
>> Rough or very rough. Rain. Moderate or poor.
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS load balancing: UDP or TCP ?

[Josh Kuo]

Agree with Tony on TCP not going to be tried. Have you looked at using
anycast? It is not true load balancing but it allows you to stand up
multiple DNS servers that “shares” a single IP address.

On Wed, Feb 20, 2019 at 12:25 AM Tony Finch  wrote:

> Roberto Carna  wrote:
>
> > Dear, I have to balance two DNS servers for a special reason.
>
> https://www.powerdns.com/dnsdist.html
>
> > The DNS clients are a mix of Windows, Cisco and Linux machines, so I
> > think they ask for a FQDN using UDP and after that -if there is no
> > response-, they ask the same FQDN using TCP, and so the load balancing
> > will be succesful.
>
> No, fallback to TCP relies on receiving a truncated UDP response. You
> never want a DNS client to be waiting around for a response that will
> not arrive.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Rockall, Malin: Southeast veering southwest 6 to gale 8, occasionally 5
> later.
> Rough or very rough. Rain. Moderate or poor.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re:

[Roberto Carna]

Dear Matus and Kevin, please tell me if it's OK if I do thsi:

*named.conf:*
include "/etc/bind/named.conf.default-zones";

*named.conf.default-zones:*
recursion yes;
zone "teamviewer.com" {
type forward;
forwarders { 8.8.8.8; };
};

*named.conf.local:*


I define "recursion yes" in named.conf.default-zones.

Thanks again, regards !!!

El mar., 19 feb. 2019 a las 15:13, Matus UHLAR - fantomas via bind-users (<
bind-users@lists.isc.org>) escribió:

> On 19.02.19 09:45, Roberto Carna wrote:
> >Dear Kevin, I am sorry but I didn't see your past response.
> >
> >Please can you show me with an example what you say: "Define root zone.
> >Delegate teamviewer.com from root. Define teamviewer.com as 'type
> forward'".
> >
> >An also what is the benefit in defining a root zone with the
> teamviewer.com
> >delegated into it??? Because I put to work this zone just as a forward
> >zone, without a root zone definition.
>
> the benefit is it does exactly what you want.
> the "teamviewer.com" zone of type forward causes DNS resolution of
> teamviewer.com
> domain.
> the root zone effectively disables everything else (because bind thinks
> nothing else exists).
>
> >El lun., 18 feb. 2019 a las 17:00, Kevin Darcy ( >)
> >escribió:
> >
> >> I've already posted a solution for this. Basically, "Define root zone.
> >> Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
> >> forward'".
> >>
> >> "Recursion yes" is implied. No views necessary. It doesn't make any
> sense
> >> anyway, to have the same match-clients list for all of one's views,
> since
> >> the first one matched is the one that's used.
> >>
> >> Did you not see my response, or did you perhaps dislike the approach I
> >> suggested?
> >>
> >> There was some subsequent discussion about not relying on DNS resolution
> >> as one's *only* control over what sites one's clients can or cannot
> access.
> >> While I agree with that, my position is that there's nothing wrong with
> >> controlling DNS resolution, in addition to other controls.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> M$ Win's are shit, do not use it !
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re:

[Matus UHLAR - fantomas via bind-users]

On 19.02.19 09:45, Roberto Carna wrote:

Dear Kevin, I am sorry but I didn't see your past response.

Please can you show me with an example what you say: "Define root zone.
Delegate teamviewer.com from root. Define teamviewer.com as 'type forward'".

An also what is the benefit in defining a root zone with the teamviewer.com
delegated into it??? Because I put to work this zone just as a forward
zone, without a root zone definition.


the benefit is it does exactly what you want. 
the "teamviewer.com" zone of type forward causes DNS resolution of teamviewer.com

domain.
the root zone effectively disables everything else (because bind thinks
nothing else exists).


El lun., 18 feb. 2019 a las 17:00, Kevin Darcy ()
escribió:


I've already posted a solution for this. Basically, "Define root zone.
Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
forward'".

"Recursion yes" is implied. No views necessary. It doesn't make any sense
anyway, to have the same match-clients list for all of one's views, since
the first one matched is the one that's used.

Did you not see my response, or did you perhaps dislike the approach I
suggested?

There was some subsequent discussion about not relying on DNS resolution
as one's *only* control over what sites one's clients can or cannot access.
While I agree with that, my position is that there's nothing wrong with
controlling DNS resolution, in addition to other controls.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
M$ Win's are shit, do not use it !
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Empty .local zone

[Tony Finch]

Ben Bridges  wrote:
>
> Would it be advisable or inadvisable to define an empty zone for .local
> on a recursive, unicast BIND server that is not hosting any Microsoft
> Windows AD domains or other .local zones in order to keep the queries
> for .local off the root servers?

If you are running BIND 9.12 with `dnssec-validation auto` then it isn't
necessary, because `named` will do NXDOMAIN synthesis for .local so you
won't leak queries to the root servers.

Before 9.12 I had a fairly extensive list of empty local zones most of
which was quite boring, except for .local, which had extra complications.
Avahi has a tricky interpretation of RFC 6762 section 22.1 point 4: it
tests the SOA at the apex of .local, and when it gets an answer it stops
doing mDNS. So an empty zone doesn't work so well, but NXDOMAIN synthesis
works nicely.

# Misdirected mDNS queries get REFUSED
# so that Avahi does not think we have a real .local zone.
zone local {
type master;
file "/etc/db.null";
allow-query { !0.0.0.0/0; !::/0; };
};

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
reject all prejudice and discrimination based upon race, colour,
religion, age, disability, gender, or sexual orientation
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Empty .local zone

[Ben Bridges]

Greetings.

Would it be advisable or inadvisable to define an empty zone for .local on a 
recursive, unicast BIND server that is not hosting any Microsoft Windows AD 
domains or other .local zones in order to keep the queries for .local off the 
root servers?  It seems to me like it would be a good idea, but online searches 
have returned mixed views on the subject, and BIND doesn't appear to have a 
built-in zone for it, suggesting there might be a reason not to create an empty 
zone for it.

(My definition of an empty zone is one that has no records in it except an SOA 
record and an NS record which returns either "localhost" (preferably) or the 
BIND server itself.)

Thanks,

Ben Bridges


[City Utilities]

[SpringNet]

Sales 417.575.7000 | Support 417.874.8000 | 
springnet.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS load balancing: UDP or TCP ?

[Tony Finch]

Roberto Carna  wrote:

> Dear, I have to balance two DNS servers for a special reason.

https://www.powerdns.com/dnsdist.html

> The DNS clients are a mix of Windows, Cisco and Linux machines, so I
> think they ask for a FQDN using UDP and after that -if there is no
> response-, they ask the same FQDN using TCP, and so the load balancing
> will be succesful.

No, fallback to TCP relies on receiving a truncated UDP response. You
never want a DNS client to be waiting around for a response that will
not arrive.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall, Malin: Southeast veering southwest 6 to gale 8, occasionally 5 later.
Rough or very rough. Rain. Moderate or poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

DNS load balancing: UDP or TCP ?

[Roberto Carna]

Dear, I have to balance two DNS servers for a special reason.

I need your comments please:

1) If I use HAProxy for DNS load balancing, this software only works with
TCP protocol (not UDP). The DNS clients are a mix of Windows, Cisco and
Linux machines, so I think they ask for a FQDN using UDP and after that -if
there is no response-, they ask the same FQDN using TCP, and so the load
balancing will be succesful.

2) Or do you recommend the use of a UDP load balancing method, maybe for
faster responses??? In this case what UDP load balancer can I try ???

Thanking in advance.

Robert
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re:

[Roberto Carna]

Dear Kevin, I am sorry but I didn't see your past response.

Please can you show me with an example what you say: "Define root zone.
Delegate teamviewer.com from root. Define teamviewer.com as 'type forward'".

An also what is the benefit in defining a root zone with the teamviewer.com
delegated into it??? Because I put to work this zone just as a forward
zone, without a root zone definition.

Special thanks again!!!

El lun., 18 feb. 2019 a las 17:00, Kevin Darcy ()
escribió:

> I've already posted a solution for this. Basically, "Define root zone.
> Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
> forward'".
>
> "Recursion yes" is implied. No views necessary. It doesn't make any sense
> anyway, to have the same match-clients list for all of one's views, since
> the first one matched is the one that's used.
>
> Did you not see my response, or did you perhaps dislike the approach I
> suggested?
>
> There was some subsequent discussion about not relying on DNS resolution
> as one's *only* control over what sites one's clients can or cannot access.
> While I agree with that, my position is that there's nothing wrong with
> controlling DNS resolution, in addition to other controls.
>
>   - Kevin
>
> On Mon, Feb 18, 2019 at 10:44 AM Roberto Carna 
> wrote:
>
>> Dear I've implemented two views, one for local resolution and the other
>> for forward a public zone to our resolver.
>>
>> But now I have a problem:
>>
>> If I define the same clients for the local zone view and forward view,
>> depending on the order of the views the client can resolve or not the
>> query. In this case client 10.12.1.1 will match view INT and not view
>> EXT:
>>
>> acl internal { 10.12.1. 1; };
>> acl external { 10.12.1.1; };
>>
>> view "INT" {
>> match-clients { internal; };
>> recursion no;
>> zone "company.com" {
>> type master;
>> file "/etc/bind/zones/company.com.db";
>> };
>>
>> view "EXT" {
>> match-clients { external; };
>> recursion yes;
>> zone "teamviewer.com" {
>> type forward;
>> forward only;
>> forwarders {
>> 172.1 8.1.1;
>> };
>> };
>>
>> If I define just one view with local and forward zones, I have to define
>> "recursion yes" because the forward zone need this option, but in this case
>> a query for a local zone is trying to be resolved against ROOT Servers and
>> finally against master zone but it takes some seconds:
>>
>> acl unique { 10.12.1. 1; };
>>
>> view "INT-EXT" {
>> match-clients { unique; };
>> recursion yes;
>> zone "company.com" {
>> type master;
>> file "/etc/bind/zones/company.com.db";
>> };
>> zone "teamviewer.com" {
>> type forward;
>> forward only;
>> forwarders {
>> 172.1 8.1.1;
>> };
>> };
>>
>> How can I define same clients to try resolving first view and -if there
>> is no response- they try with second view ???
>>
>> Or is there any other way to do what I want?
>>
>> Regards
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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