Re: Help on NXDOMAIN to try next forwarder in the list
On 30.05.13 12:56, sumsum 2000 wrote:
I have zone forwarders as follows with BIND9 setup with forward only option
on a Non Authoritative DNS server
zone mytestdomain101.com IN {
type forward;
forwarders {8.8.8.8;4.2.2.1;8.8.4.4};
forward only;
};
On 30.05.13 15:00, sumsum 2000 wrote:
This is a non-standard behavior and I would like to have the following:
In the case where I am working on,
/etc/resolv.conf contains localhost 127.0.0.1 and BIND is listening on
localhost port 53 as non-authoritative DNS
So all the requests are sent through 127.0.0.1 and based on the domain they
are in forward only mode.
There is no point in forwarding just one domain to google recursive servers.
Either forward ALL domains there (but in such case you could simply avoid
local BIND and point resolv.conf to google), or point the domain directly to
its servers instead of google.
Since BIND 9.8 and you can do it by using type static-stub instead of type
forward and use server-addresses instead of forwarders.
There are specific domains for eg mygeo1.mycompany.com. There are specific
authoritative DNS servers which contain this record.
If you are trying to say that some of authoritative servers for a domain do
know about one record and others do not know, then the servers and the
domain are broken and they need to be fixed.
mygeo1.mycompany.com is forwarded to myDNS1.mycompany.com,
myDNS2.mycompany.com, myDNS3.mycompany.com which are specific authoritative
DNS servers to mycompany.com But administrator does not know which one has
it
So, is that mytestdomain101.com or mycompany.com or mygeo1.mycompany.com?
It would be easier to look at the problem if you provided us correct data.
--
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.
42.7 percent of all statistics are made up on the spot.
___
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: Help on NXDOMAIN to try next forwarder in the list
Hi,
The google DNS server was only examples.. it can be some internal DNS
servers and external DNS servers. For eg 10.10.10.10; 120.10.13.12 etc.
where the DNS requests are being forwarded to..
There are issues with connectivity where the DNS entries are not synced up.
And these entries are all specific to say mycompany.com where the DNS
are residing in several locations..
So when my local DNS is returning NXDOMAIN, the other locations which might
have the entries are not tried.
the example mytestdomain101.mycompany.com is an example where my list is
10.10.10.10; 120.10.13.12 for example.. i try 10.10.10.10 - NXDOMAIN
returned.. i want to try 120.10.13.12 before sending NXDOMAIN to my initial
request.
I hope this helps.
Thanks
On Fri, May 31, 2013 at 1:05 PM, Matus UHLAR - fantomas
uh...@fantomas.skwrote:
On 30.05.13 12:56, sumsum 2000 wrote:
I have zone forwarders as follows with BIND9 setup with forward only
option
on a Non Authoritative DNS server
zone mytestdomain101.com IN {
type forward;
forwarders {8.8.8.8;4.2.2.1;8.8.4.4};
forward only;
};
On 30.05.13 15:00, sumsum 2000 wrote:
This is a non-standard behavior and I would like to have the following:
In the case where I am working on,
/etc/resolv.conf contains localhost 127.0.0.1 and BIND is listening on
localhost port 53 as non-authoritative DNS
So all the requests are sent through 127.0.0.1 and based on the domain
they
are in forward only mode.
There is no point in forwarding just one domain to google recursive
servers. Either forward ALL domains there (but in such case you could
simply avoid
local BIND and point resolv.conf to google), or point the domain directly
to
its servers instead of google.
Since BIND 9.8 and you can do it by using type static-stub instead of
type
forward and use server-addresses instead of forwarders.
There are specific domains for eg mygeo1.mycompany.com. There are
specific
authoritative DNS servers which contain this record.
If you are trying to say that some of authoritative servers for a domain do
know about one record and others do not know, then the servers and the
domain are broken and they need to be fixed.
mygeo1.mycompany.com is forwarded to myDNS1.mycompany.com,
myDNS2.mycompany.com, myDNS3.mycompany.com which are specific
authoritative
DNS servers to mycompany.com But administrator does not know which one
has
it
So, is that mytestdomain101.com or mycompany.com or mygeo1.mycompany.com?
It would be easier to look at the problem if you provided us correct data.
--
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.
42.7 percent of all statistics are made up on the spot.
__**_
Please visit
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/**listinfo/bind-usershttps://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: Help on NXDOMAIN to try next forwarder in the list
On 31.05.13 16:41, sumsum 2000 wrote: The google DNS server was only examples.. it can be some internal DNS servers and external DNS servers. For eg 10.10.10.10; 120.10.13.12 etc. where the DNS requests are being forwarded to.. Then it was bad example. You use type forward when you want to ask other server to recursively resolve the domain instead of yours.the example with google servers even supported this case. As I have stated in my previous e-mail, you can use type static-stub if you want specific server to answer your questions (non-recursively). There are issues with connectivity where the DNS entries are not synced up. How long do the issues usually persist? What kind are they, slaves not fetching from master? Or do you use forwarders and they return NXDOMAIN? In the first case you need to fix connectivity issues or make them less important, in the second lower your SOA minimum value (which affects the negative TTL) And these entries are all specific to say mycompany.com where the DNS are residing in several locations.. So when my local DNS is returning NXDOMAIN, the other locations which might have the entries are not tried. the example mytestdomain101.mycompany.com is an example where my list is 10.10.10.10; 120.10.13.12 for example.. i try 10.10.10.10 - NXDOMAIN returned.. i want to try 120.10.13.12 before sending NXDOMAIN to my initial request. This was answered already: It's impossible and illogical to ask again if someone replies THERE IS NO SUCH RECORD. You need to fix your DNS infrastructure, not try to circumvent it's issues. -- 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. Honk if you love peace and quiet. ___ 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: Help on NXDOMAIN to try next forwarder in the list
I will add my +1: NXDOMAIN does not mean I don't have a number for that name but someone else might. It means The DNS lists this name as having no number (or whatever). There's no more reason to look further than if you got a positive answer from one server and still wondered if some other DNS server might say something else. You might just as well recheck positive A-record answers with other servers because they might say NXDOMAIN. The only reason to look further is if you are monitoring for inconsistencies/brokenness. Settling time is an issue, e.g. when you don't have an effective NOTIFY authoritative servers temporarily disagree for a significant interval. Still, if you get two answers (one NXDOMAIN and one A record) from servers, there is no way to tell which is correct, just as if you got two different A-record answers. It's up to the zone's maintainer to assure the (hopefully temporary) inconsistency doesn't cause issues. John Wobus Cornell Univ 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: Help on NXDOMAIN to try next forwarder in the list
In article mailman.395.1370014330.20661.bind-us...@lists.isc.org, John Wobus jw...@cornell.edu wrote: I will add my +1: NXDOMAIN does not mean I don't have a number for that name but someone else might. It means The DNS lists this name as having no number (or whatever). There's no more reason to look further than if you got a positive answer from one server and still wondered if some other DNS server might say something else. You might just as well recheck positive A-record answers with other servers because they might say NXDOMAIN. The only reason to look further is if you are monitoring for inconsistencies/brokenness. Settling time is an issue, e.g. when you don't have an effective NOTIFY authoritative servers temporarily disagree for a significant interval. Still, if you get two answers (one NXDOMAIN and one A record) from servers, there is no way to tell which is correct, just as if you got two different A-record answers. It's up to the zone's maintainer to assure the (hopefully temporary) inconsistency doesn't cause issues. Theoretically, clients could query multiple servers, and we could have required them to include the SOA serial number in all replies, and the client could select the answer with the highest serial. But that's not how the protocol was designed. DNS makes a trade-off between overhead and perfection -- it makes extensive use of caching, and it's understood that there will be windows during which different clients may have different views of a record. TTLs, refresh times, and NOTIFY allow DNS administrators to limit the size of those windows. Application developers are expected to work around this at higher levels, as best they can. -- Barry Margolin Arlington, MA ___ 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: RHEL, Centos, Fedora rpm 9.9.3 w/ rpz2+rl patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.five-ten-sg.com/mapper/bind contains links to the source rpms, and build instructions. 9.9.3-0.2 is version with the rpz2+rl patches from http://www.redbarn.org/dns/ratelimits -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlGpB9kACgkQL6j7milTFsGZQACfUiHGdQaKXRRSSXMVJc6dJtr8 oSgAoINjhsvivMqzI58plZNSe6X9g5oN =L6lv -END PGP SIGNATURE- ___ 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
focusfeatures.com issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't see where a local dns server picked up the wrong data. It is possible that this was a temporary error that has been fixed, but I am curious. dig FocusFeatures.com soa +short @pdns4.ultradns.org. pdns1.ultradns.net. hostmaster.ge.com. 2013030400 10800 3600 2592000 900 That looks ok. dig focusfeatures.com. soa +short ns-1168.awsdns-18.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 I just did an 'rndc flushname focusfeatures.com.', redid the query, and it picked up the proper 2013030400 soa. If there is currently an inconsistency in focusfeatures.com, I am not seeing it. It looks like amazon is running a different version of that zone. dig FocusFeatures.com soa +short @ns-1168.awsdns-18.org. ns-1168.awsdns-18.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlGpKDgACgkQL6j7milTFsENbACeJdwwMvlfxtV5L2e2cdOyfI9B 0kQAniC2h0ywIV71Qhu2mN3w531mbN1W =rZRk -END PGP SIGNATURE- ___ 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
