Re: Negative zones; NXDOMAIN responses
In message <519b9008.7040...@chrysler.com>, Kevin Darcy writes: > > Ugh, I'm trying _really_ hard not to be an annoying nitpicker (yeah, I > know, try harder :-), but... > > The relevant verbiage of RFC 6762 is: > > Caching DNS servers SHOULD recognize these names as special and > SHOULD NOT attempt to look up NS records for them, or otherwise > query authoritative DNS servers in an attempt to resolve these > names. Instead, caching DNS servers SHOULD generate immediate > NXDOMAIN responses for all such queries they may receive (from > misbehaving name resolver libraries). This is to avoid unnecessary > load on the root name servers and other name servers. > > I'm not sure that slaving the root zone (although it is the "simplest > solution" and undoubtedly _works_) is really compatible with the letter > or spirit of that verbiage... > > - Kevin And doing that doesn't work if you have a validating stub resolver as there is no insecure delegation to .local in the root zone. Synthesis of DNS records is not straight forward in the presence of DNSSEC. See RFC 6303 Locally Served DNS Zones for how it needs to be done. You will note that IANA was tasked with the job of getting insecure delegations added for all the zones listed. When you slave the root you do not need a insecure delegation. It is possible to cryptographically identify when secure delegations have been tampered with which will cover the majority of the delegations in the root zone. All new TLDs are required to support DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Negative zones; NXDOMAIN responses
Ugh, I'm trying _really_ hard not to be an annoying nitpicker (yeah, I
know, try harder :-), but...
The relevant verbiage of RFC 6762 is:
Caching DNS servers SHOULD recognize these names as special and
SHOULD NOT attempt to look up NS records for them, or otherwise
query authoritative DNS servers in an attempt to resolve these
names. Instead, caching DNS servers SHOULD generate immediate
NXDOMAIN responses for all such queries they may receive (from
misbehaving name resolver libraries). This is to avoid unnecessary
load on the root name servers and other name servers.
I'm not sure that slaving the root zone (although it is the "simplest
solution" and undoubtedly _works_) is really compatible with the letter
or spirit of that verbiage...
- Kevin
On 5/20/2013 9:03 PM, Mark Andrews wrote:
The simplest solution is to slave the root zone and
turn off notify to so you don't spam the official
root servers. 192.5.5.241 is f.root-servers.net.
zone "." IN {
type slave;
file "slave/root";
masters { 192.5.5.241; };
notify no;
};
If you want to use DNSSEC to validate the contents then
you can use views to achieve this.
managed-keys {
. initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};
view "secure" {
match-clients { localnets; };
match-recursive-only yes;
zone . {
type static-stub;
server-addresses { 127.0.0.1; };
};
};
view "external" {
recursion no;
allow-recursion { none; };
zone "." IN {
type slave;
file "slave/root";
masters { 192.5.5.241; };
notify no;
};
};
Mark
___
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: Negative zones; NXDOMAIN responses
In message <2013052109.ga18...@fantomas.sk>, Matus UHLAR - fantomas writes: > >> On 21.05.13 11:03, Mark Andrews wrote: > >> > The simplest solution is to slave the root zone and > >> > turn off notify to so you don't spam the official > >> > root servers. 192.5.5.241 is f.root-servers.net. > > >In message <20130521072352.ga17...@fantomas.sk>, Matus UHLAR - fantomas > >writes: > >> I thought this is not oficially recommended for ordinary users to prevent > >> root servers from being overloaded (transfers use much more resources than > >> ordinary lookups). Has this changed? > > On 21.05.13 18:02, Mark Andrews wrote: > >Zone transfers of the root zone by recursive servers would actually > >reduce the overall load on root nameservers. The bigger the recursive > >server the more this is true as most queries to the root servers > >are for non-existent domains. Actual referrals get cached which > >draws legitimate traffic away from the root servers towards the TLD > >servers. 16 SOA queries a day plus 2 AXFR/IXFR requests for normal > >operations. > > > >Just don't add lots the root servers in the masters cause as the > >root server operators do check that their servers are transfering > >the root zone. > > But this makesthe situation worse for those who decided to do the slaving > - it creates a risk that root server forbids slaving in the future and after > zone expiration the resolution will fail for all zones. > > ...I did slave root at my former employee (an ISP in slovakia), since I > believed that this ISP is big enough that even roots would benefit from > lower traffic. I found that 5 of root servers allow the transfer. > and I found that the traffic towards root servers is really smaller enough. > > I'm just asking if this is wise for small hosts/companies. I don't think that it matters much about the size of the server. The roots are massively over provisioned with respect to serving slave versions of the root. That said if you are worried about it use the servers referenced in Doug's email xfr.lax.dns.icann.org or xfr.cjr.dns.icann.org which have been specifically offered by ICANN for this use. Mark > -- > 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. > Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Negative zones; NXDOMAIN responses
On 21.05.13 11:03, Mark Andrews wrote: >The simplest solution is to slave the root zone and >turn off notify to so you don't spam the official >root servers. 192.5.5.241 is f.root-servers.net. In message <20130521072352.ga17...@fantomas.sk>, Matus UHLAR - fantomas writes: I thought this is not oficially recommended for ordinary users to prevent root servers from being overloaded (transfers use much more resources than ordinary lookups). Has this changed? On 21.05.13 18:02, Mark Andrews wrote: Zone transfers of the root zone by recursive servers would actually reduce the overall load on root nameservers. The bigger the recursive server the more this is true as most queries to the root servers are for non-existent domains. Actual referrals get cached which draws legitimate traffic away from the root servers towards the TLD servers. 16 SOA queries a day plus 2 AXFR/IXFR requests for normal operations. Just don't add lots the root servers in the masters cause as the root server operators do check that their servers are transfering the root zone. But this makesthe situation worse for those who decided to do the slaving - it creates a risk that root server forbids slaving in the future and after zone expiration the resolution will fail for all zones. ...I did slave root at my former employee (an ISP in slovakia), since I believed that this ISP is big enough that even roots would benefit from lower traffic. I found that 5 of root servers allow the transfer. and I found that the traffic towards root servers is really smaller enough. I'm just asking if this is wise for small hosts/companies. -- 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. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... ___ 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: Negative zones; NXDOMAIN responses
On 05/21/2013 09:28 AM, Doug Barton wrote: ...which IIRC some configs for root-slaving (FreeBSD?) use by default. It's not used by default, but it is in the config, commented out. Ah, faulty RAM on my part ;o) ___ 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: Negative zones; NXDOMAIN responses
On 05/21/2013 12:39 AM, Phil Mayers wrote:
On 05/21/2013 08:23 AM, Matus UHLAR - fantomas wrote:
On 21.05.13 11:03, Mark Andrews wrote:
The simplest solution is to slave the root zone and
turn off notify to so you don't spam the official
root servers. 192.5.5.241 is f.root-servers.net.
zone "." IN {
type slave;
file "slave/root";
masters { 192.5.5.241; };
notify no;
};
I thought this is not oficially recommended for ordinary users to prevent
root servers from being overloaded (transfers use much more resources
than
ordinary lookups). Has this changed?
ICANN run a specifc AXFR service for various infrastructure zones:
http://dns.icann.org/services/axfr/
...which IIRC some configs for root-slaving (FreeBSD?) use by default.
It's not used by default, but it is in the config, commented out.
___
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: Negative zones; NXDOMAIN responses
In message <20130521072352.ga17...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 21.05.13 11:03, Mark Andrews wrote:
> > The simplest solution is to slave the root zone and
> > turn off notify to so you don't spam the official
> > root servers. 192.5.5.241 is f.root-servers.net.
> >
> >zone "." IN {
> >type slave;
> >file "slave/root";
> >masters { 192.5.5.241; };
> >notify no;
> >};
>
> I thought this is not oficially recommended for ordinary users to prevent
> root servers from being overloaded (transfers use much more resources than
> ordinary lookups). Has this changed?
Zone transfers of the root zone by recursive servers would actually
reduce the overall load on root nameservers. The bigger the recursive
server the more this is true as most queries to the root servers
are for non-existent domains. Actual referrals get cached which
draws legitimate traffic away from the root servers towards the TLD
servers. 16 SOA queries a day plus 2 AXFR/IXFR requests for normal
operations.
Just don't add lots the root servers in the masters cause as the
root server operators do check that their servers are transfering
the root zone.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Negative zones; NXDOMAIN responses
On 05/21/2013 08:39 AM, Phil Mayers wrote: ICANN run a specifc AXFR service for various infrastructure zones: http://dns.icann.org/services/axfr/ ...which IIRC some configs for root-slaving (FreeBSD?) use by default. I should probably add that, AFAICT, opinion about the value of slaving "." can be politely described as "mixed". There are a number of interesting and (to varying degrees) tetchy threads on various mailing lists/blogs about this, which a few minutes googling will get you to. Personally, we don't do it. But I can see merit in both sides of the argument. Suggest anyone wanting to resurrect that particular zombie head over to one of the various forums more suited for this kind of dicussion ;o) ___ 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: Negative zones; NXDOMAIN responses
On 05/21/2013 08:23 AM, Matus UHLAR - fantomas wrote:
On 21.05.13 11:03, Mark Andrews wrote:
The simplest solution is to slave the root zone and
turn off notify to so you don't spam the official
root servers. 192.5.5.241 is f.root-servers.net.
zone "." IN {
type slave;
file "slave/root";
masters { 192.5.5.241; };
notify no;
};
I thought this is not oficially recommended for ordinary users to prevent
root servers from being overloaded (transfers use much more resources than
ordinary lookups). Has this changed?
ICANN run a specifc AXFR service for various infrastructure zones:
http://dns.icann.org/services/axfr/
...which IIRC some configs for root-slaving (FreeBSD?) use by default.
___
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: Negative zones; NXDOMAIN responses
On 21.05.13 11:03, Mark Andrews wrote:
The simplest solution is to slave the root zone and
turn off notify to so you don't spam the official
root servers. 192.5.5.241 is f.root-servers.net.
zone "." IN {
type slave;
file "slave/root";
masters { 192.5.5.241; };
notify no;
};
I thought this is not oficially recommended for ordinary users to prevent
root servers from being overloaded (transfers use much more resources than
ordinary lookups). Has this changed?
--
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.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
___
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: Negative zones; NXDOMAIN responses
The simplest solution is to slave the root zone and
turn off notify to so you don't spam the official
root servers. 192.5.5.241 is f.root-servers.net.
zone "." IN {
type slave;
file "slave/root";
masters { 192.5.5.241; };
notify no;
};
If you want to use DNSSEC to validate the contents then
you can use views to achieve this.
managed-keys {
. initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};
view "secure" {
match-clients { localnets; };
match-recursive-only yes;
zone . {
type static-stub;
server-addresses { 127.0.0.1; };
};
};
view "external" {
recursion no;
allow-recursion { none; };
zone "." IN {
type slave;
file "slave/root";
masters { 192.5.5.241; };
notify no;
};
};
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Negative zones; NXDOMAIN responses
On 5/20/2013 11:36 AM, Chris Buxton wrote:
On May 20, 2013, at 12:51 AM, Narcis Garcia wrote:
- Yes, I thought about not using DNS from the same internet provider,
but wanted to know if there is a way to patch only the .local response.
- This is the configuration I use in one of the LANs:
view "local-nets" {
match-clients { acl_local-nets; };
recursion yes;
forwarders {
62.151.2.8;
};
include "/etc/bind/named.conf.default-zones";
}
- These are the tests to be done from a client:
$ host -t SOA local.
$ host -t SOA local. 62.151.2.8
- I've tried to create an empty zone, or lacking of A or SOA records,
but then BIND9 doesn't load it:
zone local/IN: has 0 SOA records
zone local/IN: has no NS records
zone local/IN: not loaded due to errors.
- I'm using BIND 9.7.3 from Debian 6, and I see that I need to upgrade
to BIND 9.8.4 from Debian 7 to configure an RPZ zone.
But I'm not sure if it's useful for SOA records.
For the time being, .local is not delegated from the root. So just not using
your ISP's resolvers will do what you want -- recurse directly to the Internet.
There is no way to create an empty .local zone that won't have even an SOA
record. I'm not sure if you could do this via RPZ -- probably -- but why bother
when you could just remove your ISP's servers from the equation?
I'm not a big fan of solutions that bombard the root servers with "junk"
traffic. According to the Wikipedia entry for ".local",
l.root-servers.net is already getting hit with about 2300 qps for
".local" names (thus 4th behind .com, .net and .org). Let's not add to that.
This is fairly trivial to deal with via RPZ:
local CNAME .; for the apex
*.local CNAME . ; for everything else
Full disclosure: I'd love to implement this myself, but
a) my strategic product for DNS resolution charges extra for the RPZ
functionality, and
b) my biggest business partner, having followed Microsoft's
recommendation of many years (until their recent reversal) has deployed
several "real" internal zones under the .local TLD. I can't afford to
blind myself to those.
- Kevin
P.S. Wikipedia might want to update their figures, since I just did a
query via
http://stats.l.root-servers.org/cgi-bin/dsc-grapher.pl?window=86400&plot=qtype_vs_all_tld&server=L-root
and "local" shows as third on the graph, the figure appearing closer to
2500 qps than 2300 qps.
___
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: Negative zones; NXDOMAIN responses
On May 20, 2013, at 12:51 AM, Narcis Garcia wrote:
> - Yes, I thought about not using DNS from the same internet provider,
> but wanted to know if there is a way to patch only the .local response.
>
> - This is the configuration I use in one of the LANs:
>
> view "local-nets" {
>match-clients { acl_local-nets; };
>recursion yes;
>forwarders {
>62.151.2.8;
>};
>include "/etc/bind/named.conf.default-zones";
> }
>
> - These are the tests to be done from a client:
> $ host -t SOA local.
> $ host -t SOA local. 62.151.2.8
>
> - I've tried to create an empty zone, or lacking of A or SOA records,
> but then BIND9 doesn't load it:
> zone local/IN: has 0 SOA records
> zone local/IN: has no NS records
> zone local/IN: not loaded due to errors.
>
> - I'm using BIND 9.7.3 from Debian 6, and I see that I need to upgrade
> to BIND 9.8.4 from Debian 7 to configure an RPZ zone.
> But I'm not sure if it's useful for SOA records.
For the time being, .local is not delegated from the root. So just not using
your ISP's resolvers will do what you want -- recurse directly to the Internet.
There is no way to create an empty .local zone that won't have even an SOA
record. I'm not sure if you could do this via RPZ -- probably -- but why bother
when you could just remove your ISP's servers from the equation?
Regards,
Chris
___
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: Negative zones; NXDOMAIN responses
You need the soa record. It has to be empty but not THAT empty :-)
Sent from my iPad
On 20 May 2013, at 04:51, Narcis Garcia wrote:
> - Yes, I thought about not using DNS from the same internet provider,
> but wanted to know if there is a way to patch only the .local response.
>
> - This is the configuration I use in one of the LANs:
>
> view "local-nets" {
>match-clients { acl_local-nets; };
>recursion yes;
>forwarders {
>62.151.2.8;
>};
>include "/etc/bind/named.conf.default-zones";
> }
>
> - These are the tests to be done from a client:
> $ host -t SOA local.
> $ host -t SOA local. 62.151.2.8
>
> - I've tried to create an empty zone, or lacking of A or SOA records,
> but then BIND9 doesn't load it:
> zone local/IN: has 0 SOA records
> zone local/IN: has no NS records
> zone local/IN: not loaded due to errors.
>
> - I'm using BIND 9.7.3 from Debian 6, and I see that I need to upgrade
> to BIND 9.8.4 from Debian 7 to configure an RPZ zone.
> But I'm not sure if it's useful for SOA records.
>
>
> Al 20/05/13 09:00, En/na Matus UHLAR - fantomas ha escrit:
On 19 May 2013 20:51, Narcis Garcia wrote:
> The internet ISP returns positive values for .local
> queries, and I need that LAN clients receive NXDOMAIN instead.
>>
>> do they return positive answers for any non-existing domains?
>> (is this one of ISPs wanting to make money on mistypes and ling to the
>> people?)
>> On 19.05.13 21:26, Steven Carr wrote:
>>> But in response to the actual question... what you want to do is not
>>> possible in BIND zone configs as you can't create a negative zone
>>> (that I'm aware of).
>>
>> He can create empty .local zone that will return NXDOMAIN for everything.
>>
>>> On 19 May 2013 21:22, Steven Carr wrote:
Why are you forwarding queries to the ISP? Implement your own caching
layer, I for one would never use/trust an ISPs caching servers. If I
want to resolve a domain I go direct to the source, not via a 3rd
party.
>>
>> This is the real solution. You should not use services broken like this of
>> any ISP. I'd even recommend not to use ANY services of such ISPs.
> ___
> 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: Negative zones; NXDOMAIN responses
- Yes, I thought about not using DNS from the same internet provider,
but wanted to know if there is a way to patch only the .local response.
- This is the configuration I use in one of the LANs:
view "local-nets" {
match-clients { acl_local-nets; };
recursion yes;
forwarders {
62.151.2.8;
};
include "/etc/bind/named.conf.default-zones";
}
- These are the tests to be done from a client:
$ host -t SOA local.
$ host -t SOA local. 62.151.2.8
- I've tried to create an empty zone, or lacking of A or SOA records,
but then BIND9 doesn't load it:
zone local/IN: has 0 SOA records
zone local/IN: has no NS records
zone local/IN: not loaded due to errors.
- I'm using BIND 9.7.3 from Debian 6, and I see that I need to upgrade
to BIND 9.8.4 from Debian 7 to configure an RPZ zone.
But I'm not sure if it's useful for SOA records.
Al 20/05/13 09:00, En/na Matus UHLAR - fantomas ha escrit:
>>> On 19 May 2013 20:51, Narcis Garcia wrote:
The internet ISP returns positive values for .local
queries, and I need that LAN clients receive NXDOMAIN instead.
>
> do they return positive answers for any non-existing domains?
> (is this one of ISPs wanting to make money on mistypes and ling to the
> people?)
> On 19.05.13 21:26, Steven Carr wrote:
>> But in response to the actual question... what you want to do is not
>> possible in BIND zone configs as you can't create a negative zone
>> (that I'm aware of).
>
> He can create empty .local zone that will return NXDOMAIN for everything.
>
>> On 19 May 2013 21:22, Steven Carr wrote:
>>> Why are you forwarding queries to the ISP? Implement your own caching
>>> layer, I for one would never use/trust an ISPs caching servers. If I
>>> want to resolve a domain I go direct to the source, not via a 3rd
>>> party.
>
> This is the real solution. You should not use services broken like this of
> any ISP. I'd even recommend not to use ANY services of such ISPs.
>
___
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: Negative zones; NXDOMAIN responses
On 19 May 2013 20:51, Narcis Garcia wrote: The internet ISP returns positive values for .local queries, and I need that LAN clients receive NXDOMAIN instead. do they return positive answers for any non-existing domains? (is this one of ISPs wanting to make money on mistypes and ling to the people?) On 19.05.13 21:26, Steven Carr wrote: But in response to the actual question... what you want to do is not possible in BIND zone configs as you can't create a negative zone (that I'm aware of). He can create empty .local zone that will return NXDOMAIN for everything. On 19 May 2013 21:22, Steven Carr wrote: Why are you forwarding queries to the ISP? Implement your own caching layer, I for one would never use/trust an ISPs caching servers. If I want to resolve a domain I go direct to the source, not via a 3rd party. This is the real solution. You should not use services broken like this of any ISP. I'd even recommend not to use ANY services of such ISPs. -- 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. "To Boot or not to Boot, that's the question." [WD1270 Caviar] ___ 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: Negative zones; NXDOMAIN responses
On 19 May 2013 23:14, Sten Carlsen wrote: > .local actually has meaning for most modern systems, so I would question the > wisdom of what you want to do. > > You may find some functions of systems not working any more. Obviously it is > up to you in the end. Looking at the bug link that would seem to indicate why he wants to send back NXDOMAIN. Avahi seems to check for .local on startup by default and if it gets a valid response then doesn't start publishing. ___ 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: Negative zones; NXDOMAIN responses
>> These LAN have a BIND9 service to provide name resolving and caching for >> internet access, and I want to intercept the .local domain to give a >> NXDOMAIN response. The internet ISP returns positive values for .local >> queries, and I need that LAN clients receive NXDOMAIN instead. .local actually has meaning for most modern systems, so I would question the wisdom of what you want to do. You may find some functions of systems not working any more. Obviously it is up to you in the end. >>> >>> Can I create a zone file for .local domain and specify there NXDOMAIN >>> values for SOA and A RRs? How should be the content of the zone sheet? >>> >>> -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ 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: Negative zones; NXDOMAIN responses
But in response to the actual question... what you want to do is not possible in BIND zone configs as you can't create a negative zone (that I'm aware of). However in later versions of BIND9 you can create a local RPZ zone which you could then use to send back a negative response for .local http://www.isc.org/software/rpz http://jpmens.net/2011/04/26/how-to-configure-your-bind-resolvers-to-lie-using-response-policy-zones-rpz/ On 19 May 2013 21:22, Steven Carr wrote: > Why are you forwarding queries to the ISP? Implement your own caching > layer, I for one would never use/trust an ISPs caching servers. If I > want to resolve a domain I go direct to the source, not via a 3rd > party. > > > On 19 May 2013 20:51, Narcis Garcia wrote: >> Hello, >> >> I'm trying to solve this problem in some local networks, without >> intervention to client computers: >> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/327362 >> >> These LAN have a BIND9 service to provide name resolving and caching for >> internet access, and I want to intercept the .local domain to give a >> NXDOMAIN response. The internet ISP returns positive values for .local >> queries, and I need that LAN clients receive NXDOMAIN instead. >> >> Can I create a zone file for .local domain and specify there NXDOMAIN >> values for SOA and A RRs? How should be the content of the zone sheet? >> >> Thanks. >> ___ >> 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: Negative zones; NXDOMAIN responses
Why are you forwarding queries to the ISP? Implement your own caching layer, I for one would never use/trust an ISPs caching servers. If I want to resolve a domain I go direct to the source, not via a 3rd party. On 19 May 2013 20:51, Narcis Garcia wrote: > Hello, > > I'm trying to solve this problem in some local networks, without > intervention to client computers: > https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/327362 > > These LAN have a BIND9 service to provide name resolving and caching for > internet access, and I want to intercept the .local domain to give a > NXDOMAIN response. The internet ISP returns positive values for .local > queries, and I need that LAN clients receive NXDOMAIN instead. > > Can I create a zone file for .local domain and specify there NXDOMAIN > values for SOA and A RRs? How should be the content of the zone sheet? > > Thanks. > ___ > 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
Negative zones; NXDOMAIN responses
Hello, I'm trying to solve this problem in some local networks, without intervention to client computers: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/327362 These LAN have a BIND9 service to provide name resolving and caching for internet access, and I want to intercept the .local domain to give a NXDOMAIN response. The internet ISP returns positive values for .local queries, and I need that LAN clients receive NXDOMAIN instead. Can I create a zone file for .local domain and specify there NXDOMAIN values for SOA and A RRs? How should be the content of the zone sheet? Thanks. ___ 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
