Re: Bind takes a long time to resolve requests
On 10/4/2011 12:40 PM, Pablo Maurelli wrote:
hello, pick up a dns server with bind9, is resolving claims, but
it takes time to resolve a lot, sometimes throw timeout error and
the second time resolved, any ideas?
I pass below my named.conf, host.conf and nsswitch.conf
*_DIG:_*
; DiG 9.7.3
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 90
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 517816 IN NS g.root-servers.net
http://g.root-servers.net.
. 517816 IN NS a.root-servers.net
http://a.root-servers.net.
. 517816 IN NS m.root-servers.net
http://m.root-servers.net.
. 517816 IN NS f.root-servers.net
http://f.root-servers.net.
. 517816 IN NS b.root-servers.net
http://b.root-servers.net.
. 517816 IN NS e.root-servers.net
http://e.root-servers.net.
. 517816 IN NS j.root-servers.net
http://j.root-servers.net.
. 517816 IN NS k.root-servers.net
http://k.root-servers.net.
. 517816 IN NS i.root-servers.net
http://i.root-servers.net.
. 517816 IN NS h.root-servers.net
http://h.root-servers.net.
. 517816 IN NS d.root-servers.net
http://d.root-servers.net.
. 517816 IN NS c.root-servers.net
http://c.root-servers.net.
. 517816 IN NS l.root-servers.net
http://l.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net http://a.root-servers.net. 604216 IN A
198.41.0.4
a.root-servers.net http://a.root-servers.net. 604216 IN
2001:503:ba3e::2:30
b.root-servers.net http://b.root-servers.net. 604216 IN A
192.228.79.201
c.root-servers.net http://c.root-servers.net. 604216 IN A
192.33.4.12
d.root-servers.net http://d.root-servers.net. 604216 IN A
128.8.10.90
d.root-servers.net http://d.root-servers.net. 604216 IN
2001:500:2d::d
e.root-servers.net http://e.root-servers.net. 604216 IN A
192.203.230.10
f.root-servers.net http://f.root-servers.net. 604216 IN A
192.5.5.241
f.root-servers.net http://f.root-servers.net. 604216 IN
2001:500:2f::f
g.root-servers.net http://g.root-servers.net. 604216 IN A
192.112.36.4
h.root-servers.net http://h.root-servers.net. 604216 IN A
128.63.2.53
i.root-servers.net http://i.root-servers.net. 604216 IN A
192.36.148.17
j.root-servers.net http://j.root-servers.net. 604216 IN A
192.58.128.30
j.root-servers.net http://j.root-servers.net. 604217 IN
2001:503:c27::2:30
;; Query time: 0 msec
;; SERVER: 172.31.26.85#53(172.31.26.85)
;; WHEN: Tue Oct 4 13:34:03 2011
;; MSG SIZE rcvd: 500
I would check connectivity to all of those root nameservers using the
+norec and +buf=4096 options so as to mimic how named itself would
query them.
If by some chance you have IPv6 enabled on your nameserver, with an
assigned (non-link-local) IPv6 address, but no actual IPv6 connectivity
to the Internet, you should probably start named with the -4 option,
to prevent it wasting time trying to talk to root nameservers (and
others) over the IPv6 transport.
- Kevin
*_DIG ns1.resolver01.net http://ns1.resolver01.net_*
root@resolver01:/var/named# dig ns1.resolver01.net
http://ns1.resolver01.net
; DiG 9.7.3 ns1.resolver01.net http://ns1.resolver01.net
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 61061
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.resolver01.net http://ns1.resolver01.net.IN A
;; ANSWER SECTION:
ns1.resolver01.net http://ns1.resolver01.net. 43200 IN A
172.31.26.85
;; AUTHORITY SECTION:
resolver01.net http://resolver01.net. 43200 IN NS
ns1.resolver01.net http://ns1.resolver01.net.
;; Query time: 0 msec
;; SERVER: 172.31.26.85#53(172.31.26.85)
;; WHEN: Tue Oct 4 13:34:42 2011
;; MSG SIZE rcvd: 66
Both queries returned in 0 milliseconds. Are you looking for something
faster than that? :-)
*_NAMED.CONF_*
// Mis redes permitidas
acl redes_sky {
172.31.26.0/24 http://172.31.26.0/24;
172.31.25.0/24 http://172.31.25.0/24;
172.31.24.0/24 http://172.31.24.0/24;
};
options {
directory /var/named;
dump-file /var/named/data/cache_dump.db;
Re: DNS-cache with custom gTLDs
On 9/21/2011 10:01 PM, Drunkard Zhang wrote: Why are you going through all of these gyrations? The forwarding algorithm in BIND has for a long time been based on RTT, so if one forwarder, or a set of forwarders, stops working, the other(s) will be used automatically. In other words, forwarder failover works without any special configuration. I don't even understand your forward first solution. Forward first says to use iterative (non-recursive) resolution if forwarding fails (i.e. all the forwarders are non-responsive). How then can you use it to fail over from one set of forwarders to another? I don't get it. If you send a non-recursive query to a forwarder, you're at the mercy of whatever happens to be in its cache at that particular time. You can't get reliable resolution that way. Oops, I misunderstood. But I want to resolve this problem: take news.qq.com for example, I DID saw that it's unresolvable to one group (they returned NXDomain), at meantime it's no problem to another group, and dig news.qq.com +trace returned correct answer on both group. It seems like it's just a temporary failure, but I want to correct. Any other choices? NXDOMAIN is a *permanent* response; at least it's permanent in the absence of any change the relevant DNS RRset or zone. You're almost certainly getting the NXDOMAIN because you're spoofing the root servers, and your fake root servers don't have the same knowledge as the real ones, so they'll return NXDOMAIN for some queries (whereas dig +trace does not, because it follows the hierarchy down and asks different nameservers). In other words, you're shooting yourself in the foot with your hints-file trickery. Just go with the standard root nameservers and think harder about the real problem you're trying to solve here. - Kevin ___ 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-cache with custom gTLDs
On 9/22/2011 6:03 AM, Drunkard Zhang wrote: Oops, I misunderstood. But I want to resolve this problem: take news.qq.com for example, I DID saw that it's unresolvable to one group (they returned NXDomain), at meantime it's no problem to another group, and dig news.qq.com +trace returned correct answer on both group. It seems like it's just a temporary failure, but I want to correct. Any other choices? We have told you already. Id server returns NXDOMAIN, then the host name does not exist and you have nothing more to try. unless you break your DNS clients which is dangerous thing to do. Thanks for your patient. So I can just wait for the recovery, or flushname by hand? Guess I have to face client's complains all the time :-( See my other message. I think you're creating those NXDOMAINs by spoofing root nameservers in your hints file. If my speculation is correct, use the real roots and the problem should go away. - Kevin ___ 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: Max Cache Objects
On 9/21/2011 5:00 PM, TMK wrote: I have couple of questions. bind cache memory limit is 4GB. can I increase it. or this is hard-coded limit. i'm running the x64 bit version. You can _try_ to raise that limit above 4Gb (see the various configuration elements under Operating System Resource Limits in the ARM), but your OS may still limit you. You'd need to look at your OS documentation to see how to raise soft and/or hard limits. also to increase the cache hit ratio I have created script to query my dns for the top 1 million sites. would this give any performance advantages or is it useless. Since a large percentage of those top sites use DNS-based load-balancing with small TTLs on their records, it's pretty useless. Of course, you can measure your cache hit ratio to see if it's really helping you or not. Real data always beats pure speculation. - Kevin ___ 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-cache with custom gTLDs
On 9/20/2011 5:08 AM, Drunkard Zhang wrote: I got 4 DNSs doing recursive resolution, which splited into 2 groups, and a couple of dns caches. Each group of recursion DNS using their own net link, which is different. Here's problem: I want a dns-cache to use one group of recursion DNS as their forwarders, and use another group as backup. ( I have to, because 2 groups of recursion DNS get different results, and sometimes one of them can't resolves, while another can. ) All solution I can find out is forward first to one group, and use all 2 groups as gTLDs, is this __safe__? Why are you going through all of these gyrations? The forwarding algorithm in BIND has for a long time been based on RTT, so if one forwarder, or a set of forwarders, stops working, the other(s) will be used automatically. In other words, forwarder failover works without any special configuration. I don't even understand your forward first solution. Forward first says to use iterative (non-recursive) resolution if forwarding fails (i.e. all the forwarders are non-responsive). How then can you use it to fail over from one set of forwarders to another? I don't get it. If you send a non-recursive query to a forwarder, you're at the mercy of whatever happens to be in its cache at that particular time. You can't get reliable resolution that way. Another problem: there's a lot of resolution on dns-cache querying a.root-servers.net, is it safe that i hijack a.root-servers.net to my own DNS? If it's safe, I can cut down queries to a.root-servers.net by millions of times per hour. If you're getting a lot of recursive queries for a.root-servers.net, you have a misbehaving client that you need to track down and vaporize. - Kevin ___ 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: Query regarding NS record
Are you talking about recursive clients failing over? Or other nameservers trying to talk to yours, non-recursively? Recursive clients don't use NS records at all and you need to approach the failover problem in a completely different way (e.g. relying on the client failing over from one resolver IP address to another, or implementing an Anycast solution). If you're talking about nameserver-to-nameserver traffic, then just publish multiple NS records for the relevant zone(s) and the nameserver-selection algorithm embedded in every known iterative-resolver implementation will take care of the load-balancing and failover; to summarize, faster-responding nameservers will be chosen over slower-responding ones. - Kevin On 9/16/2011 11:17 AM, babu dheen wrote: Hi, Can anyone let me know how i can resolve the below requirement. Requirement: We have two offices. One is main office and another one is remote branch office. Now my company client requirement is that if main office DNS server is not reachable, all DNS query should be sent to branch office DNS server. How this can be acheived using BIND? For example, my company mail website is; mail.mycompany.com which is pointed as below in ISP name server. mail.mycompany.comINNSns1.mainoffice.com mail.mycompany.comINNSns1.branceoffice.com Is the above record is correct or not? Please suggest. Regards papdheen M ___ 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: Correct SRV configuration
The name goyello.com *itself* owns no SRV records. You never added any with that name. host doesn't have any special knowledge of SRV records, and, besides, you didn't tell it what service and protocol, so it didn't even have enough information to construct the appropriate name to look up. You have to treat the names of SRV records like any other DNS names, and spell them out completely. Look up _sip._tls.goyello.com and _sipfederationtls._tcp.goyello.com and you should find the relevant SRV records in the appropriate places. Example lookups can be found at http://en.wikipedia.org/wiki/SRV_record - Kevin P.S. 9.2.4 is really old. Upgrade. On 9/18/2011 10:46 AM, Piotr Pawlowski wrote: Dear all, I have named 9.2.4 . Everything is working fine. Unfortunately yesterday I faced issue with setting up SRV record. Below is how I tried to configure it for MS Lync service: _sip._tls3600INSRV100 1 443 sipdir.online.lync.com. _sipfederationtls._tcp3600INSRV100 1 5061 sipfed.online.lync.com. Everything looks like it is described in RFC2782: Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target The point is, that when I ask domain for SRV record I receive: $ host -t SRV goyello.com goyello.com has no SRV record Does anybody know where I made a mistake? Thank you in advance for a help and tips. Best Regards -- Piotr Pawlowski ___ 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: Query regarding NS record
ANY. That NS record tells *the*world* (not just your ISP) that they can come to your nameserver to resolve names in the zone. It wouldn't be much a failover strategy if you were relying on your ISP's nameservers to somehow proxy the queries over to you, when they're down. Open up inbound destination port 53 TCP/UDP (for queries) and outbound source port 53 TCP/UDP (for responses). The destination port outbound will be the same as the source port inbound, for a given DNS transaction, if your firewalls are stateful enough to keep track of such things. - Kevin On 9/18/2011 12:01 PM, babu dheen wrote: Hi, Once i delegated NS record in my ISP name server to my company name server for mail.myoffice.com website as below. Do i need to allow DNS port from ANY(INTERNET) to my DNS server in firewall or i just need to allow DNS traffic only from ISP DNS server ISP DNS server configuration mycompany-dns-server-ip INA 10.10.10.10 mail.myoffice.com INNSmycompany dns server ip Regards Papdheen M *From:* Kevin Darcy k...@chrysler.com *To:* bind-users@lists.isc.org *Sent:* Sunday, 18 September 2011 5:09 PM *Subject:* Re: Query regarding NS record Are you talking about recursive clients failing over? Or other nameservers trying to talk to yours, non-recursively? Recursive clients don't use NS records at all and you need to approach the failover problem in a completely different way (e.g. relying on the client failing over from one resolver IP address to another, or implementing an Anycast solution). If you're talking about nameserver-to-nameserver traffic, then just publish multiple NS records for the relevant zone(s) and the nameserver-selection algorithm embedded in every known iterative-resolver implementation will take care of the load-balancing and failover; to summarize, faster-responding nameservers will be chosen over slower-responding ones. - Kevin On 9/16/2011 11:17 AM, babu dheen wrote: Hi, Can anyone let me know how i can resolve the below requirement. Requirement: We have two offices. One is main office and another one is remote branch office. Now my company client requirement is that if main office DNS server is not reachable, all DNS query should be sent to branch office DNS server. How this can be acheived using BIND? For example, my company mail website is; mail.mycompany.com which is pointed as below in ISP name server. mail.mycompany.comINNSns1.mainoffice.com mail.mycompany.comINNSns1.branceoffice.com Is the above record is correct or not? Please suggest. Regards papdheen M ___ Please visithttps://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org mailto: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 mailto: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: Proper CNAME interpretation
On 9/14/2011 5:52 PM, Chuck Swiger wrote: On Sep 14, 2011, at 2:27 PM, Ronald F. Guilmette wrote: The second part however seems to go more to my question, which is What is the resolver supposed to do when some knucklehead breaks the rules and puts a CNAME in with some other stuff? Depends on which query one issued. The very next paragraph of RFC-1034 is: CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted. In other words, if you ask for an A record, and you get back both a CNAME and an A record, then the A record matches and that's what gethostbyname()/getaddrinfo() or whatever should receive from the resolver. If you asked for an record, and got that same reply of a CNAME and an A record, then the resolver should chase the CNAME's data field. It sure _sounds_ like that second sentence is encouraging any all people who are writing resolvers, or other related tools, that they should ignore any flotsam jetsum that appear along side a CNAME. But is that encourage- ment espressed anywhere as a MUST? By no means. You only ought to chase a CNAME if you got a CNAME *instead* of the resource type that you asked for.' Indeed. It should be noted that not only does the graphiteops.com name break the CNAME and other rule, but it's a *self-referential* CNAME (rdata = graphiteops.com), so if one tried to chase it, one could chase infinitely. This is, presumably, what RFC 1034 calls a CNAME loop, and according to that document (Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error) I would have expected nslookup and/or dig to have error'ed out when encountering this. Are those utilities not considered domain software? Hard to know, since neither 1034 nor 1035 define that term... - Kevin ___ 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: DiG unexpected source with a Subnet-Router anycast address
Why are you trying to use the SRAA for DNS resolution? SRAA has a special meaning to network-infrastructure devices; I don't think it was ever intended for anycasting general network services. Just pick one of your global-unicast address, and anycast that instead. There was an old Internet-Draft specifying common *site-local* addresses for DNS resolvers, but that draft expired many years ago, and since site-local itself has been deprecated, could be considered doubly obsolete. (Although I still see those fec0:* addresses appended to the resolver list on a Windows XP PC with IPv6 enabled). Note that RFC 4291 obsoletes RFC 3513 which obsoletes RFC 2373. - Kevin On 9/7/2011 10:48 AM, François-Xavier Le Bail wrote: Hello, I send with DiG 9.7.3 a request to a router/DNS forwarder with the Subnet-Router anycast address of the router (SRAA, RFC 2373, § 2.6.1). The answer is : reply from unexpected source:GUA of the router#53, expectedSRAA#53 Is there an option to relax the IPv6 address request/reply control for this use case ? Best regards, François-Xavier Le Bail -Message d'origine- De : LE BAIL Francois-Xavier RD-RESA-LAN Envoyé : mercredi 7 septembre 2011 16:29 À : LE BAIL Francois-Xavier RD-RESA-LAN Objet : DiG subnet-anycast router address DiG 9.7.3 ;; reply from unexpected source: 2001:1:1:100:209:a9ff:fe13:1500#53, expected 2001:1:1:100::#53 ___ 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: [UNsolved] was: what does dig +trace do?
On 9/6/2011 8:40 PM, Mark Andrews wrote: In message4e66b5b5.30...@chrysler.com, Kevin Darcy writes: On 9/1/2011 7:57 PM, Mark Andrews wrote: In message4e5fb1ab.4040...@data.pl, Torinthiel writes: On 09/01/11 17:56, Tom Schmitt wrote: =20 I found the cause of my problem (and a solution): =20 dig +trace actually has another behaviour than doing the trace manually= step by step with dig. =20 =20 For a trace, dig is asking for the NS-records, then for the IP-address = of the nameserver found and then go on asking this nameserver. Till the d= estination is reached. =20 In my case, dig is asking for the nameservers of the root-zone and is g= etting the answer: . IN NS root1 . IN NS root2=20 etc =20 Next dig is asking for the A-record of root1. And here is the differren= ce: =20 If I do dig root1 dig is asking exactly this, it is asking for the A-= record of root1. And of course I get the correct answer from named. =20 The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf= and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. =20 After deleting the searchsuffix in resolv.conf, dig +trace is working f= ine without any error. =20 In my oppinion it's a bug that dig +trace behave in a differrent way th= an doing the queries with dig one by one. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say =2E IN NS root1. =2E IN NS root2. (with dots appended) and you should be home. dig +trace calls getaddrinfo() and that needs to be able to resolve the hostname (without dots at the end). getaddrinfo() is called so that we don't have to have a full blown iterative resolver in dig. The Internet moved from being a flat namespace (names without dots) for hostnames to a heirachical namespace (names with *internal* dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 Hostnames without dots are now local (e.g. localhost) or need to be qualified (resolv.conf: search). Actually, RFC 1123 requires a way to suppress domain suffixing, and mentions the trailing dot convention: 6.1.4.3 Interface Abbreviation Facilities User interfaces MAY provide a method for users to enter abbreviations for commonly-used names. Although the definition of such methods is outside of the scope of the DNS specification, certain rules are necessary to insure that these methods allow access to the entire DNS name space and to prevent excessive use of Internet resources. If an abbreviation method is provided, then: (a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed. A trailing dot is the usual method. But it appears that getaddrinfo() doesn't, apparently (according to a quick wrapper program I tested with) support the trailing dot convention for suppressing domain suffixing, or, AFAIK, any other way to suppress domain suffixing, therefore dig +trace is stuck either -- as you said -- implementing a full iterative resolver itself, or calling getaddrinfo() and confusing the user with unwanted domain suffixing, in the special case of a delegation to a root name. Let's be clear, though: dig +trace *should* be able to deal with a delegation to a root name, as twisted and obscure as that is. It only fails to do so because of some design decisions/tradeoffs made with getaddrinfo() and/or dig itself. Not because the user is doing something wrong. Well really they are. Address records on TLD labels will *never* work reliably unless you can get the world to agree to stop using search lists. Seriously, if a TLD label *only* appears in the RDATA of NS records, and *never* as a hostname (in the RFC 952/1123 sense), why would we worry about searchlisting complications? And even if a TLD label is presented at the user-to-program interface, as long as the prevailing convention for disabling searchlists (mandatory as per RFC 1123) is present (e.g. trailing dot), it too can be unambiguously resolved. So there's really no *technical* reason for dig to malfunction when encountering a delegation to a TLD label. IMO, this smacks more of prioritizing a personal preference against the use of TLD labels, over fixing a _bona_fide_ bug in the dig +trace algorithm. You may not like TLD labels, but they should still work regardless. - Kevin P.S. Don't get me wrong, as a general rule I hate shortnames and searchlisting, and I've been trying to eradicate their use here for decades, but in the spirit of dig's give me what I ask for, not what you think is best for me, and mere consistency, I think that if named itself can handle delegations to TLD labels, dig +trace should be able to handle them too. People do, after all, use dig +trace to mimic
Re: [UNsolved] was: what does dig +trace do?
On 9/1/2011 7:57 PM, Mark Andrews wrote: In message4e5fb1ab.4040...@data.pl, Torinthiel writes: On 09/01/11 17:56, Tom Schmitt wrote: =20 I found the cause of my problem (and a solution): =20 dig +trace actually has another behaviour than doing the trace manually= step by step with dig. =20 =20 For a trace, dig is asking for the NS-records, then for the IP-address = of the nameserver found and then go on asking this nameserver. Till the d= estination is reached. =20 In my case, dig is asking for the nameservers of the root-zone and is g= etting the answer: . IN NS root1 . IN NS root2=20 etc =20 Next dig is asking for the A-record of root1. And here is the differren= ce: =20 If I do dig root1 dig is asking exactly this, it is asking for the A-= record of root1. And of course I get the correct answer from named. =20 The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf= and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. =20 After deleting the searchsuffix in resolv.conf, dig +trace is working f= ine without any error. =20 In my oppinion it's a bug that dig +trace behave in a differrent way th= an doing the queries with dig one by one. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say =2E IN NS root1. =2E IN NS root2. (with dots appended) and you should be home. dig +trace calls getaddrinfo() and that needs to be able to resolve the hostname (without dots at the end). getaddrinfo() is called so that we don't have to have a full blown iterative resolver in dig. The Internet moved from being a flat namespace (names without dots) for hostnames to a heirachical namespace (names with *internal* dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 Hostnames without dots are now local (e.g. localhost) or need to be qualified (resolv.conf: search). Actually, RFC 1123 requires a way to suppress domain suffixing, and mentions the trailing dot convention: 6.1.4.3 Interface Abbreviation Facilities User interfaces MAY provide a method for users to enter abbreviations for commonly-used names. Although the definition of such methods is outside of the scope of the DNS specification, certain rules are necessary to insure that these methods allow access to the entire DNS name space and to prevent excessive use of Internet resources. If an abbreviation method is provided, then: (a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed. A trailing dot is the usual method. But it appears that getaddrinfo() doesn't, apparently (according to a quick wrapper program I tested with) support the trailing dot convention for suppressing domain suffixing, or, AFAIK, any other way to suppress domain suffixing, therefore dig +trace is stuck either -- as you said -- implementing a full iterative resolver itself, or calling getaddrinfo() and confusing the user with unwanted domain suffixing, in the special case of a delegation to a root name. Let's be clear, though: dig +trace *should* be able to deal with a delegation to a root name, as twisted and obscure as that is. It only fails to do so because of some design decisions/tradeoffs made with getaddrinfo() and/or dig itself. Not because the user is doing something wrong. - Kevin ___ 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: Split PTR zone (internal and external)
On 7/28/2011 12:26 PM, CT wrote: I am wondering what might be a good workaround for this legacy setup... Will do my best to explain.. IP Space - 1 Class B Global Unique (used Externally and Internally) - 1 Class B RFC1918 DNS Setup External DNS (Linux - Bind 9.8.x) - example-ext.com DNS domain - authoritative for PTR Global Unique Mid Teir DNS (Linux - Bind 9.8.x) - Mixture of Class B Global and RFC 1918 - not accessible from the Internet - forwards all RFC 1918 PTR to the Internal DNS - can resolve any Internal / External A records Internal DNS(MS DNS - w/DDNS) - only internal DNS zones (i.e. inside.example.com) - MS DNS use Mid Tier DNS for external name resolution (i.e. isc.org) - Has the *same* Global Unique Class B PTR as the External DNS ** Scenario - internal hosts using the Internal DNS can not resolve External PTR for example-ext.com. since a valid PTR zone already exists.. The only solution that I have come up with is to manually put the external PTR records in the AD PTR Zone file. Not sure if there is a resolution to do in MS DNS but will ask the same question in that group. Wanted to start here.. Delegate out the relevant /24 ranges as subzones of your main /16 in-addr.arpa zone. Define only the internal reverse subzones in your Internal DNS and then use slave/stub/forward to resolve all of the external ones. - Kevin ___ 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 Caching Issue
On 7/25/2011 10:22 AM, Sathyan Arjunan (sarjunan) [CONTRACTOR] wrote: Recent days, I am facing frequent caching issues with my DNS servers which are responsible for recursive lookup to external queries. As a temporary solution, we used to refresh the named daemon to clear the cache. To isolate this issue we upgraded the BIND to BIND 9.7.3 but even after the upgrade issue repeats. If I do a nslookup for *mail.sin.gpi-g.com*, it fails. *nslookup mail.sin.gpi-g.com** *Server: dnsserver Address:x.x.x.x#53 *** server can't find mail.sin.gpi-g.com: SERVFAIL* To fix this I have to restart the named daemon in caching DNS server. Once I restart, the lookup resolves well. However the issue appears again in few days. Any thoughts? nslookup mail.sin.gpi-g.com Server: dnsserver Address:x.x.x.x#53 Non-authoritative answer: Name: mail.sin.gpi-g.com Address: 203.175.163.180 nameserver2.gpi-g.com is persistently responding with SERVFAIL.for anything at sin.gpi-g.com or beneath. Looks to me like a misconfiguration of some sort. nameserver1.gpi-g.com is responding reasonably, *but* only gives nameserver2.gpi-g.com in the Authority Section of its response. So only that NS gets cached, and named will keep trying the bad nameserver until you restart named, which will get it working temporarily until the bad NS is cached again. There is nothing you can do to fix this in your instance(s) of BIND. The domain owner has created a Single Point of Failure, and then that node has failed. They need to fix the node failure, put more diversity into their published NS records, or (preferably) implement both options. - Kevin ___ 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: Forward only zones.
On 7/24/2011 2:15 AM, Vbvbrj wrote:
options {
allow-transfer { none; };
recursion yes;
forward first;
forwarders { a.b.c.d; }; // Forward to providers dns.
};
zone my_domain.com IN {
type forward;
forward only;
forwarders { a.b.c.d; }; // Forward to Windows DNS.
};
I would like BIND to respond to local LAN like this: All queries for
local domain my_domain.com to be forwarded to local Microsoft DNS to
server Acrive Directory. Other queries to sites to forward to external
dns servers.
But BIND does not forward everything to microsoft dns. I want that
BIND forward every query and return answer, without any caching so
that record updating, adding or deleting will be always up-to-date.
When I try this configuration, BIND not forwarding every query.
Correct. That's the distinction which is typically made between a DNS
*forwarder* (which caches) and a DNS *proxy* (which doesn't). As far as
I know, BIND cannot be configured to be a DNS proxy.
Answers from its cache, that may be out of date.
This is tunable via the TTL values on the relevant RRsets. Consult the
manual of your authoritative DNS server software, for details.
Also, records not always are update when adding or removing computers
from domain.
Either a) you're just restating the previous problem (answers might be
from cached data) or b) this is a data-consistency or lag problem
between various components in Microsoft-land -- BIND cannot fix that.
- Kevin
___
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: howto know if a query was delegated to cache
On 7/25/2011 6:14 AM, harish badrinath wrote:
(Originally sent to bind-workers, sorry if this is considered cross
posting. Slightly modified from the original message)
Hello,
I am using Bind version:BIND 9.7.1-P2
I am doing some small internal changes to bind and i have to know when
a query is being answered from internal cache and when from resolvers.
That information doesn’t seem to be recorded in client.attributes or
client-query.attributes ??
Can any one tell me where the code branches for cached/non cached
responses in function query_find in the file bin/named/query.c *or*
if the current client was responsible for cache insertion/addition for
client-query.qname.
I need help, to generate a construct along the lines of,
if(condition|binary_function == (true|false))
{
response was given by cache
}
*or*
#define ISFROMCACHE(client/query) ...
Whatever you're trying to accomplish, it's would not appear to be
consistent with the founding RFCs for DNS:
(RFC 1034, Section 5.3.3, Resolver Algorithm):
Step 1 searches the cache for the desired data. If the data is in the
cache, IT IS ASSUMED TO BE GOOD ENOUGH FOR NORMAL USE [capitalization
added - kcd]. Some resolvers have an option at the user interface which
will force the resolver to ignore the cached data and consult with an
authoritative server. This is not recommended as the default.
Perhaps it would help if you explained *why* you care whether the data
is from cache or not (?) If you're concerned about the *integrity* of
the DNS data, you should do some research on DNSSEC.If you have a
different reason, maybe there's a better way to accomplish your goal.
- Kevin
___
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: sort list and view
On 7/20/2011 1:15 AM, AMANI M. BIN SUWAIF wrote:
Hi,
The problem is that fail-over between A records is not standard and
might/might not work with various SIP clients. On the other hand SRV
in my opinion has been designed with that in mind, that's why the
additional complexity with 2 SRV records.
Thanks Regards,
*Amani*
On 7/20/2011 2:50 AM, Kevin Darcy wrote:
On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
Hi,
I have the below scenario
_TCP.EXAMPLE.COMIN SRV1005060
primary-sbg.example.com
_TCP.EXAMPLE.COMIN SRV2005060
secondary-sbg.example.com
I have 2 IP ranges and 2 SBGs host, my intention is
for client in IP range1
primary-sbg INA1.1.1.1
secondary-sbgINA2.2.2.2
for client in IP range2
primary-sbg INA2.2.2.2
secondary-sbgINA1.1.1.1
can this be achieved without using a views?
I thought this can be solved just by a sortlist, where
primary-sbgINA1.1.1.1
primary-sbgINA2.2.2.2
secondary-sbgINA2.2.2.2
secondary-sbgINA1.1.1.1
and then introduce the sortlist, which sorts the position of IP
addresses based on the IP range client comes from?
something like,
sortlist {
{
IPRANGE1; // 1st client IP selection matches any of these
{1.1.1.1; // return any of these response IPs as 1st preference
};
{
IPRANGE2; // 1st client IP selection matches any of these
{2.2.2.2; // return any of these response IPs as 1st preference
};
};
but in this case,
client from IPRANGE1 receive 1.1.1.1 as a first choice for both
primary-sbg and secondary-sbg
and
client from IPRANGE2 receive 2.2.2.2 as a first choice for both
primary-sbg and secondary-sbg
which is not the intention. sortlist doesn't not consider domain name.
The intention is to have primary SBG for first iprange act as a
secondary SBG for the second ip range and vice verse and in similar
manner for multiple IP ranges and SBGs. Problem with views is that
anytime this setup gets bigger and we will have additional ip ranges
and additional SBGs, it will require additional views...
(LOC)RANGEPRIMARY(LOC) SECONDARY(LOC)
(L1)IPRANGE1 SBG1(L1) SBG6(L2)
(L1)IPRANGE2 SBG2(L1) SBG7(L2)
(L1)IPRANGE3 SBG3(L1) SBG8(L2)
(L1)IPRANGE4 SBG4(L1) SBG9(L2)
(L1)IPRANGE5 SBG5(L1) SBG10(L2)
(L2)IPRANGE6 SBG6(L2) SBG1(L1)
(L2)IPRANGE7 SBG7(L2) SBG2(L1)
(L2)IPRANGE8 SBG8(L2) SBG3(L1)
(L2)IPRANGE9 SBG9(L2) SBG4(L1)
(L2)IPRANGE10 SBG10(L2) SBG5(L1)
half of the SBGs is in one location (L1) and half in other (L2),
that's why it is important that for clients from ranges in one
location, first half of SBGs is preferred, and for other clients
from second location other half of SBGs is preferred. Client
configuration should be uniformed (same SRV) regardless the location.
Are you over-engineering this? If the A-record failover by your
client is fast enough you might only need 1 SRV record, and then
sortlisting will work fine (subject to the usual caveats: as long as
you can control the sortlist config of every resolver your clients
will use, and keep them in sync).
- Kevin
Well, you could always stand up some virtual IPs on the same servers (or
possibly NAT it upstream) and then perform some *fancy* sortlisting, e.g.
for clients in IP range1
primary-sbg 1.1.1.1, 2.2.2.3
secondary-sbg 2.2.2.2, 1.1.1.2
for clients in IP range2
primary-sbg 2.2.2.3, 1.1.1.1
secondary-sbg 1.1.1.2, 2.2.2.2
That way range1 clients would always fail over -- via SRV failover or
A-record failover -- from the 1.1.1.x server to the 2.2.2.x server and
range2 clients would always fail over from the 2.2.2.x server to the
1.1.1.x server.
Bear in mind that views, i.e. giving different answers to the same DNS
query, depending on the client, is not something which is (as far as I'm
aware) sanctioned by the Internet Standards, but A-record failover was
specified as far back as RFC 1123 (1989):
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address translation will
return a list of alternative IP addresses. As specified in Section
6.1.3.4, this list should be in order of decreasing preference.
Application protocol implementations SHOULD be prepared to try multiple
addresses from the list until success is obtained. More specific
requirements for SMTP are given in Section 5.3.4.
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address
translation will return a list of alternative IP addresses. As
specified in Section 6.1.3.4, this list should be in order of
decreasing preference. Application protocol implementations
SHOULD be prepared to try multiple addresses from the list until
Re: sort list and view
On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
Hi,
I have the below scenario
_TCP.EXAMPLE.COMIN SRV1005060primary-sbg.example.com
_TCP.EXAMPLE.COMIN SRV2005060
secondary-sbg.example.com
I have 2 IP ranges and 2 SBGs host, my intention is
for client in IP range1
primary-sbg INA1.1.1.1
secondary-sbgINA2.2.2.2
for client in IP range2
primary-sbg INA2.2.2.2
secondary-sbgINA1.1.1.1
can this be achieved without using a views?
I thought this can be solved just by a sortlist, where
primary-sbgINA1.1.1.1
primary-sbgINA2.2.2.2
secondary-sbgINA2.2.2.2
secondary-sbgINA1.1.1.1
and then introduce the sortlist, which sorts the position of IP
addresses based on the IP range client comes from?
something like,
sortlist {
{
IPRANGE1; // 1st client IP selection matches any of these
{1.1.1.1; // return any of these response IPs as 1st preference
};
{
IPRANGE2; // 1st client IP selection matches any of these
{2.2.2.2; // return any of these response IPs as 1st preference
};
};
but in this case,
client from IPRANGE1 receive 1.1.1.1 as a first choice for both
primary-sbg and secondary-sbg
and
client from IPRANGE2 receive 2.2.2.2 as a first choice for both
primary-sbg and secondary-sbg
which is not the intention. sortlist doesn't not consider domain name.
The intention is to have primary SBG for first iprange act as a
secondary SBG for the second ip range and vice verse and in similar
manner for multiple IP ranges and SBGs. Problem with views is that
anytime this setup gets bigger and we will have additional ip ranges
and additional SBGs, it will require additional views...
(LOC)RANGEPRIMARY(LOC) SECONDARY(LOC)
(L1)IPRANGE1 SBG1(L1) SBG6(L2)
(L1)IPRANGE2 SBG2(L1) SBG7(L2)
(L1)IPRANGE3 SBG3(L1) SBG8(L2)
(L1)IPRANGE4 SBG4(L1) SBG9(L2)
(L1)IPRANGE5 SBG5(L1) SBG10(L2)
(L2)IPRANGE6 SBG6(L2) SBG1(L1)
(L2)IPRANGE7 SBG7(L2) SBG2(L1)
(L2)IPRANGE8 SBG8(L2) SBG3(L1)
(L2)IPRANGE9 SBG9(L2) SBG4(L1)
(L2)IPRANGE10 SBG10(L2) SBG5(L1)
half of the SBGs is in one location (L1) and half in other (L2),
that's why it is important that for clients from ranges in one
location, first half of SBGs is preferred, and for other clients from
second location other half of SBGs is preferred. Client configuration
should be uniformed (same SRV) regardless the location.
Are you over-engineering this? If the A-record failover by your client
is fast enough you might only need 1 SRV record, and then sortlisting
will work fine (subject to the usual caveats: as long as you can control
the sortlist config of every resolver your clients will use, and keep
them in sync).
- Kevin
___
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: Clients get DNS timeouts because ipv6 means more queries for each lookup
On 7/13/2011 2:35 AM, Jonathan Kamens wrote: On 07/13/2011 02:13 AM, Mark Andrews wrote: Well, all the prodding from people here prompted me to investigate further exactly what's going on. The problem isn't what I thought it was. It appears to be a bug in glibc, and I've filed a bug report and found a workaround. There is no bug in glibc. To be blunt, that's bullshit. If glibc makes an A query and an query, and it gets back a valid response to the A query and an invalid response to the query, then it should ignore the invalid response to the query and return the valid A response to the user as the IP address for the host. Please note, furthermore, that as I explained in detail in my bug report and in my last message, glibc behaves differently based on the /order/ in which the two responses are returned by the DNS server. Since there's nothing that says a DNS server has to respond to two queries in the order in which they were received, and that would be an impossible requirement to impose in any case, since the queries and responses are sent via UDP which doesn' guarantee order, it's perfectly clear that glibc needs to be prepared to function the same regardless of the order in which it receives the responses. I agree that the order of the A/ responses shouldn't matter to the result. The whole getaddrinfo() call should fail regardless of whether the failure is seen first or the valid response is seen first. Why? Because getaddrinfo() should, if it isn't already, be using the RFC 3484 algorithm (and/or whatever the successor to RFC 3484 ends up being) to sort the addresses, and for that algorithm to work, one needs *both* the IPv4 address(es) *and* the IPv6 address(es) available, in order to compare their scopes, prefixes, etc.. If one of the lookups fails, and this failure is presented to the RFC 3484 algorithm as NODATA for a particular address family, then the algorithm could make a bad selection of the destination address, and this can lead to other sorts of breakage, e.g. trying to use a tunneled connection where no tunnel exists. The *safe* thing for glibc to do is to promote the failure of either the A lookup or the lookup to a general lookup failure, which prompts the user/administrator to find the source of the problem and fix it. It's rarely a good idea to mask undeniable errors as if there were no error at all. It leads to unpredictable behavior and really tough troubleshooting challenges. I think glibc is erring on the side of openness and transparency here, rather than trying to cover up the fact that something is horribly wrong. Note your fix won't help clients that only ask for records because it is the authoritative servers that are broken, not the resolver library or the recursive server. I am aware of that. It is irrelevant, because it is not the problem I am trying to solve. I, and 99.99% of the users in the world, are /not/ only ask[ing] for records. Nobody actually trying to use the internet for day-to-day work is doing that right now, because to say that IPv6 support is not yet ubiquitous would be a laughably momentous understatement. What about clients in a NAT64/DNS64 environment? They could be configured as IPv6-only but normally able to access the IPv4 Internet just fine. Even with your glibc fix in place, though, they'll presumably break if the authoritative nameservers are giving garbage responses to queries (could someone with practical experience in DNS64 please confirm this?). Another possibility you're not considering is that the invoking application itself may make independent IPv4-specific and IPv6-specific getaddrinfo() lookups. Why would it do this? Why not? Maybe IPv6 capability is something the user has to buy a separate license for, so the IPv6 part is a slightly separate codepath, added in a later version, than the base product, which is IPv4-only. When one of the getaddrinfo() calls returns address records and the other returns garbage, your fix doesn't prevent such an application from doing something unpredictable, possibly catastrophic. So it's really not a general solution to the problem. - Kevin ___ 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: Clients get DNS timeouts because ipv6 means more queries for each lookup
On 7/13/2011 1:06 PM, Kevin Darcy wrote: On 7/13/2011 2:35 AM, Jonathan Kamens wrote: On 07/13/2011 02:13 AM, Mark Andrews wrote: Well, all the prodding from people here prompted me to investigate further exactly what's going on. The problem isn't what I thought it was. It appears to be a bug in glibc, and I've filed a bug report and found a workaround. There is no bug in glibc. To be blunt, that's bullshit. If glibc makes an A query and an query, and it gets back a valid response to the A query and an invalid response to the query, then it should ignore the invalid response to the query and return the valid A response to the user as the IP address for the host. Please note, furthermore, that as I explained in detail in my bug report and in my last message, glibc behaves differently based on the /order/ in which the two responses are returned by the DNS server. Since there's nothing that says a DNS server has to respond to two queries in the order in which they were received, and that would be an impossible requirement to impose in any case, since the queries and responses are sent via UDP which doesn' guarantee order, it's perfectly clear that glibc needs to be prepared to function the same regardless of the order in which it receives the responses. I agree that the order of the A/ responses shouldn't matter to the result. The whole getaddrinfo() call should fail regardless of whether the failure is seen first or the valid response is seen first. Why? Because getaddrinfo() should, if it isn't already, be using the RFC 3484 algorithm (and/or whatever the successor to RFC 3484 ends up being) to sort the addresses, and for that algorithm to work, one needs *both* the IPv4 address(es) *and* the IPv6 address(es) available, in order to compare their scopes, prefixes, etc.. If one of the lookups fails, and this failure is presented to the RFC 3484 algorithm as NODATA for a particular address family, then the algorithm could make a bad selection of the destination address, and this can lead to other sorts of breakage, e.g. trying to use a tunneled connection where no tunnel exists. The *safe* thing for glibc to do is to promote the failure of either the A lookup or the lookup to a general lookup failure, which prompts the user/administrator to find the source of the problem and fix it. It's rarely a good idea to mask undeniable errors as if there were no error at all. It leads to unpredictable behavior and really tough troubleshooting challenges. I think glibc is erring on the side of openness and transparency here, rather than trying to cover up the fact that something is horribly wrong. Note your fix won't help clients that only ask for records because it is the authoritative servers that are broken, not the resolver library or the recursive server. I am aware of that. It is irrelevant, because it is not the problem I am trying to solve. I, and 99.99% of the users in the world, are /not/ only ask[ing] for records. Nobody actually trying to use the internet for day-to-day work is doing that right now, because to say that IPv6 support is not yet ubiquitous would be a laughably momentous understatement. What about clients in a NAT64/DNS64 environment? They could be configured as IPv6-only but normally able to access the IPv4 Internet just fine. Even with your glibc fix in place, though, they'll presumably break if the authoritative nameservers are giving garbage responses to queries (could someone with practical experience in DNS64 please confirm this?). Another possibility you're not considering is that the invoking application itself may make independent IPv4-specific and IPv6-specific getaddrinfo() lookups. Why would it do this? Why not? Maybe IPv6 capability is something the user has to buy a separate license for, so the IPv6 part is a slightly separate codepath, added in a later version, than the base product, which is IPv4-only. When one of the getaddrinfo() calls returns address records and the other returns garbage, your fix doesn't prevent such an application from doing something unpredictable, possibly catastrophic. So it's really not a general solution to the problem. Oh, I should also point out that this brokenness by the wikipedia/wikimedia nameservers *isn't* just specific to queries, and therefore *isn't* fixable with getaddrinfo() alone. Try doing an MX query of en.wikipedia.org. Or a PTR query. Or any of the other old (yet non-deprecated) query types (e.g. NS, TXT, HINFO). The only QTYPEs that are answered correctly are A, CNAME and (oddly enough) SOA. So they don't even have the excuse of well, queries are kinda new, we haven't got around to handling them properly yet. This behavior has failed to conform to the standard, for as long as the standard has existed; it's not recent, IPv6-specific breakage
Re: Clients get DNS timeouts because ipv6 means more queries for each lookup
On 7/13/2011 2:39 PM, Jonathan Kamens wrote: I agree that the order of the A/ responses shouldn't matter to the result. The whole getaddrinfo() call should fail regardless of whether the failure is seen first or the valid response is seen first. Why? Because getaddrinfo() should, if it isn't already, be using the RFC 3484 algorithm (and/or whatever the successor to RFC 3484 ends up being) to sort the addresses, and for that algorithm to work, one needs *both* the IPv4 address(es) *and* the IPv6 address(es) available, in order to compare their scopes, prefixes, etc.. RFC 3484 tells you how to sort addresses you've got. If you've only got one address, then bang! It's already sorted for you. You don't need RFC 3484 to tell you how to sort it. No, you've got one address, and one unspecified nameserver failure. Garbage in, garbage out. To say that a nameserver failure is equivalent to NODATA is not only technically incorrect, it leads to all sorts of operational problems in the real world. I have to say that some of the people on this list seem completely detached from what real users in the real world want their computers to do. Really? Do you think I'm an academic? Do you think I sit and write Internet Drafts and RFCs all day? No, I'm an implementor. I deal with DNS operational problems and issues all day, every workday. And I can tell you that I don't appreciate library routines making wild-ass assumptions that, in the face of some questionable behavior by a nameserver, maybe, possibly some quantity of addresses that I've acquired from that dodgy nameserver are good enough for my clients to try and connect to. No thanks. If there's a real problem I want to know about it as clearly and unambiguously as possible. I can't deal effectively with a problem if it's being masked by some library routine doing something weird behind my back. If I am trying to connect to a site on the internet, then I want my computer to do its best to try to connect to the site. I don't want it to throw up its hands and say, Oh, I'm sorry, one of my address lookups failed, so I'm not going to let you use the /other/ address lookup, the one that succeeded, because some RFC somewhere could be interpreted as implying that's a bad idea, if I wanted to do so. Please, that's ridiculous. No, what's more ridiculous is if users can't get to a site SOME OF THE TIME, because someone's DNS is broken, a moronic library routine then routes the traffic some unexpected way, and a whole raft of other variables enter the picture, without anyone realizing or paying attention to the dependencies and interconnectivity that is required to keep the client working. There is a certain threshold of brokenness where the infrastructure has to throw up its hands, as you put it, and say nuh uh, not gonna happen, because to try to work around the problem based on not enough information about the topology, the environment, the dependencies, etc. you're likely to cause more harm than good by making the failure modes way more complex than necessary. If one of the lookups fails, and this failure is presented to the RFC 3484 algorithm as NODATA for a particular address family, then the algorithm could make a bad selection of the destination address, and this can lead to other sorts of breakage, e.g. trying to use a tunneled connection where no tunnel exists. If the address the client gets doesn't work, then the address doesn't work. How is being unable to connect because the address turned out to not be routable different from being unable to connect because the computer refused to even try? Because the failure modes are substantially different and it could take significant man-hours to determine that the root cause of the problem is actually DNS brokenness rather than something else in the network infrastructure (routers, switches, VPN concentrators, firewalls, IPSes, load-balancers, etc.) or in the client or server (OS, application, middleware, etc.) Have you ever actually troubleshot a difficult connectivity problem in a complex networking environment? Trust me, you want clear symptoms, clear failure modes. Not a bunch of components making dumb assumptions and/or trying to be helpful outside of their defined scope of functionality. That kind of help is like offering a glass of water to a drowning man. Another possibility you're not considering is that the invoking application itself may make independent IPv4-specific and IPv6-specific getaddrinfo() lookups. Why would it do this? Why not? Maybe IPv6 capability is something the user has to buy a separate license for, so the IPv6 part is a slightly separate codepath, added in a later version, than the base product, which is IPv4-only. When one of the getaddrinfo() calls returns address records and the other returns garbage, your fix doesn't prevent such an application from doing something unpredictable, possibly catastrophic.
Re: Allowing resolution of off-server CNAMEs
On 7/8/2011 12:11 PM, Joseph S D Yao wrote:
It should be possible to set up an authoritative-only name server so
that it does not recurse for anyone [except perhaps itself], but still
allow someone to get a full resolution of a name whose canonical name is
elsewhere. IMHBUCO.
I started with this:
view all {
match-clients { any; };
allow-query { any; };
allow-query-cache { any; }; // Only on those RHEL servers
// which allowed it (*sigh*)
allow-recursion { none; };
zone tld.example {
type master;
file data/zone.tld.example;
};
};
zone.tld.example:
$TTL3h
@ SOA ...
@ NS ns1.tld.example.
@ NS ns2.tld.example.
sub NS ns1.sub.tld.example.
sub NS ns2.sub.tld.example.
ns1 A ...
ns2 A ...
ns1.sub A ...
ns2.sub A ...
target CNAME target.sub
In this case, trying to look up target.tld.example directly from
ns1.tld.example just gets you the CNAMEs but no A record. Of course, I
says to myself, it is trying to do recursion, which is not allowed. I
will fix it so that it does not have to do recursion, but to do
forwarding, which is an entirely completely and totally different
operation. I added to the view:
zone sub.tld.example {
type forward;
forward only;
forwarders { ns1.sub's IP; ns2.sub's IP; };
};
Still not working. Unless I allow recursion! Which is SUPPOSED to be
an entirely etc.
Any ideas how to have a conceptually correct non-recursive authoritative
name server but still allow it to serve the A records?
Yes, I could have a slaved copy of the zone, but the master copy of the
zone is on an appliance, and one support person was horrified that I
used the GUI they supplied to do something else that BIND can do but
that is not part of the specific value-added software they supply.
(*sigh*) I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.
Joe,
Look at how RFC 1034 distinguishes recursive from iterative:
- In any system that has a distributed database, a particular name
server may be presented with a query that can only be answered by
some other server. The two general approaches to dealing with this
problem are recursive, in which the first server pursues the query
for the client at another server, and iterative, in which the
server refers the client to another server and lets the client
pursue the query.
I think it's pretty clear that what BIND calls forwarding is just a
subset of what the standards consider recursive resolution, and the
distinction you're trying to make between forwarding and recursion
isn't sanctioned by the standards. Moreover, in terms of bits and bytes,
a forwarded query *is* recursive (it has the RD set).
Maybe you need to ask yourself why you want to run a non-authoritative
nameserver in the first place (?) Are you following best practices for
purposes of security? Well, if you selectively poke forwarding holes
in that non-authoritative wall, then you're deviating from the best
practices and compromising your security. Think about it: when you
forward, you're trusting your forwarders (usually either by IP address
or TSIG key), validating their responses (hopefully there's enough
randomness to prevent a Kaminsky-style attack), populating a cache, etc.
All the things that have led to security issues in the past. It's
exactly those things which led to the authoritative-only best practice
in the first place -- it simplifies the interaction, reduces the number
of moving parts, and thus prevents all sorts of issues. I don't think
you want to be in the position of creating a *false*, Potemkin-Village
sense of security by claiming outwardly to be authoritative-only, yet
all the while engaging in questionable forwarding practices behind the
proverbial facade. Authoritative-only means authoritative-only: no
recursive resolution allowed, not even on the back-end and/or going by a
different name (forwarding).
- Kevin
___
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: Clients get DNS timeouts because ipv6 means more queries for each lookup
On 7/11/2011 2:11 PM, Jonathan Kamens wrote: The number of DNS queries required for each address lookup requested by a client has gone up considerably because of IPV6. The problem is being exacerbated by the fact that many DNS servers on the net don't yet support IPV6 queries. The result is that address lookups are frequently taking so long that the client gives up before getting the result. The example I am seeing this with most frequently is my RSS feed reader, rss2email, trying to read a feed from en.wikipedia.org in a cron job that runs every 15 minutes. I am regularly seeing this in the output of the cron job: W: Name or service not known [8] http://en.wikipedia.org/w/index.php?title=/[elided]/feed=atomaction=history The wikipedia.org domain has three DNS servers. Let's assume that the root and org. nameservers are cached already when rss2email does its query. If so, then it has to do the following queries: wikipedia.org DNS en.wikipedia.org en.wikipedia.org A This is fine when the wikipedia.org nameservers are working, but let's postulate for the moment that two of them are down, unreachable, or responding slowly, which apparently happens pretty often. Then we end up doing: wikipedia.org DNS en.wikipedia.org /times out /en.wikipedia.org /times out /en.wikipedia.org en.wikipedia.org A /times out/ en.wikipedia.org A /times out /en.wikipedia.org A By now the end of that sequence, the typical 30-second DNS request timeout has been exceeded, and the client gives up. The math isn't working. I just ran a quick test and named (9.7.x) failed over from a non-working delegated NS to a working delegated NS in less than 30 milliseconds. How are you reaching a 30-*second* timeout threshold in only 6 queries? In practice, it would also be quite unlikely that named would pick dead nameservers before live ones for *both* the and the A query. At the very least, once the timeouts were encountered for the query, those NSes would be penalized in terms of NS selection, so they are unlikely to be chosen *again*, ahead of the working NS, for the A query. Any en.wikipedia.org NSes which were found to be *persistently* broken, would gravitate to the bottom of the selection list, and be tried approximately never. I think maybe you need to probe deeper and find out what _else_ is going on. - Kevin ___ 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: about AUTHORITY SECTION
On 7/8/2011 3:04 AM, Chris Buxton wrote: On Jul 7, 2011, at 6:32 PM, Feng He wrote: 2011/7/8 Kevin Darcyk...@chrysler.com: I think it's worth emphasizing that in the first case, the contents of the Authority Section were *mandatory* (see RFC 2308, Negative Caching), whereas in the second case the authoritative nameserver was *optionally* providing NS records in the Authority Section. It could have legally left the Authority Section completely empty, and in fact many load-balancers, pretending (to various degrees of competence) to be authoritative nameservers, will give responses that look like that. In the second case I think the NS records should be there in the Authority Section. Consider this case: example.com. IN NSdns.example.com. l2.example.com. IN NS dns.example.com. l3.l2.example.com. IN NS dns.example.com. When a query for example, dig l3.l2.example.com @dns.example.com, the nameserver answser without the Authority Section, then the client won't know the answer is in which authority zone. While that is correct, it is also unimportant. Everything will work as expected if the resolver never finds that out. Ditto if the resolver does discover it. As for Kevin's assertion that the SOA record in the authority section is required for a negative response, this is also incorrect. RFC 2308 is a proposed standard, not a standard. OK, I stand corrected. It's mandatory per a Proposed Standard that hasn't had any major objections, reported flaws, or updates in years, and is implemented in virtually every authoritative nameserver -- including load-balancers, pretending to be auth nameservers, and which break a whole raft of other standards and/or best practices -- and resolver. *Technically* a negative response can be given that does not conform to RFC 2308, and no RFC Police will show up at one's doorstep wielding an arrest warrant... Further, section 8 of this RFC does not say explicitly that an SOA must be included in a negative response, only that it must be cached (presumably only if present). We might ask the author, Mark Andrews, for clarification of this point. Um, Section 8 talks about how resolvers deal with negative caching. Section 3 talks about responses from authoritative servers, and that was the subject of this thread. Section 3 is quite clear on the point: 3 - Negative Answers from Authoritative Servers Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. - Kevin ___ 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: about AUTHORITY SECTION
On 7/7/2011 1:50 AM, Torinthiel wrote: On 07/07/11 04:56, pa...@laposte.net wrote: Hello, I got two different forms of AUTHORITY SECTION from the dig, for example, $ dig mydots.net @ns7.dnsbed.com ; DiG 9.4.2-P2.1 mydots.net @ns7.dnsbed.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 36520 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mydots.net. IN A ;; AUTHORITY SECTION: mydots.net. 3600 IN SOA ns7.dnsbed.com. support.dnsbed.com. 6 10800 3600 604800 3600 This one means that there's no such record. Your answer is empty. See, you don't have answer section and RFCs state that authorative nameservers should send SOA record in authority section if there's no data. ;; Query time: 90 msec ;; SERVER: 58.22.107.162#53(58.22.107.162) ;; WHEN: Thu Jul 7 09:54:07 2011 ;; MSG SIZE rcvd: 86 $ dig www.mydots.net @ns7.dnsbed.com ; DiG 9.4.2-P2.1 www.mydots.net @ns7.dnsbed.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3327 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.mydots.net. IN A ;; ANSWER SECTION: www.mydots.net. 900 IN A 61.144.56.101 ;; AUTHORITY SECTION: mydots.net. 3600 IN NS ns7.dnsbed.com. mydots.net. 3600 IN NS ns8.dnsbed.com. And this one has correct answer, and the NS records are there just in case - to notify you that you got your answer from authorative ns and what other authorative ns'es are. I think it's worth emphasizing that in the first case, the contents of the Authority Section were *mandatory* (see RFC 2308, Negative Caching), whereas in the second case the authoritative nameserver was *optionally* providing NS records in the Authority Section. It could have legally left the Authority Section completely empty, and in fact many load-balancers, pretending (to various degrees of competence) to be authoritative nameservers, will give responses that look like that. - Kevin ___ 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: Doubt with towiresorted
On 7/6/2011 4:36 AM, Vignesh Gadiyar wrote:
Got your point. I meant answer sections in the Response from the DNS
server itself. It contains 4 sections namely Question, Answer,
Authoritative and Additional sections right. I used the rrset-order in
named.conf to set order to random which was normally Cyclic. The
result was that only the answer section records were getting sorted in
the random order and all other records were cyclic. Is this the
behavior if we set order to any order we want.
-Vignesh.
On Mon, Jul 4, 2011 at 9:38 PM, Kevin Darcy k...@chrysler.com
mailto:k...@chrysler.com wrote:
On 7/1/2011 2:40 AM, Vignesh Gadiyar wrote:
I have created a static zone file for www.abcd.com
http://www.abcd.com with the Answer section entries
Hold it right there. A zone file doesn't contain answer
sections, it contains zone data. That's an important, fundamental
distinction. Answer sections sometimes form part of responses,
which are produced through the name-resolution process/algorithm,
and then rendered in wire format for passing back to the client.
Hopefully you understand both the differences and
interrelationship of a nameserver's private data structures and
data storage mechanisms, on the one hand, and, on the other hand,
the standards-defined network protocol for sending bits and bytes
of data between the server and the client. Any given RRset is
going to be formatted differently, depending on whether it's in
text form in a zone file (defined by standard), held in binary
form in some sort of organized data structure in volatile memory
while named is running (proprietary to BIND), or on the wire
being passed between a nameserver and one of its clients (also
defined by standard).
containing 2 IP addresses like 1.1.1.1 and 2.2.2.2. I tried to
print these addresses in the towiresorted function for the random
order like -
for(i=0;icount;i++)
{
char adstr[40];
isc_uint32_t ip_host=(*(isc_uint32_t
*)sorted[i].rdata-data);
inet_ntop(AF_INET,(ip_host),adstr,adstr,40);
printf(%s \n,adstr);
}
thinking that rdata-data contains the IP addresses of the answer
section. But i am getting different IP addresses when i'm running
named and using dig www.abcd.com http://www.abcd.com. Some help
as to what exactly stores the IPs contained in the Answer section
would be really great.
towiresorted() is just an internal BIND conversion function, and
the product of towiresorted() would *not* be suitable, I don't
think, for feeding directly to inet_ntop(), since inet_ntop()
won't be able to handle DNS-style label compression (it doesn't
have the whole context of the response packet, so how could it?).
What exactly are you trying to do here?
If you just want a program to read a text file containing IP
addresses and then spit them out in random order, then that's not
even DNS-related and you don't need BIND libraries for that. Heck,
you could just use the sort command.
If you're trying to query some particular DNS name and then
present the results in random order, then I think the modern
algorithm -- although I haven't done any network programming in C
for years now -- would be to call getaddrinfo(), which will return
a linked list of addrinfo structures. Parse through that linked
list and randomize to your heart's content. Please understand,
however, that the vast majority of DNS resolver implementations
will *already* randomize the results (with a notable exception
being Windows' default, but de-configurable behavior of subnet
prioritization), so re-randomizing in a client program may be
wasted effort.
I don't believe rrset-order or sortlist act on any records other than
the ones in the Answer Section. There really isn't any reason to sort
records in any other section of the response, because those records are
almost always chosen according to some defined algorithm: if they are NS
records, or address records associated with NS records, then they are
selected based on historical RTT observations/calculations (if
available, otherwise random, and then RTTs histories are built up over
time); if they are Additional Section address records related to the
targets of MX or SRV records in the Answer Section, then any desired
ordering can be implemented by the domain owner via distinct Answer
Section records using preference as defined in the respective
specification of the MX or SRV record type.
Of course, if QNAME happens to match a CNAME, then address records
associated with the target of that CNAME may appear in the response, but
they'll be in the Answer Section, so rrset-order/sortlist would apply.
Offhand, I can't imagine what other record type - besides the ones I've
already mentioned above -- might result
Re: Client cannot resolve communities.intel.com
On 7/5/2011 12:28 AM, Fajar A. Nugraha wrote: On Tue, Jul 5, 2011 at 10:29 AM, vrbind-u...@iotk.net wrote: Hello, I am trying to visit http://communities.intel.com; using Iceweasel on a Debian desktop PC. No proxies. My clients etc/resolv.conf point to my own Debian BIND 9.7.3 installed on a separate server and installed from distribution packages (bind9 1:9.7.3.dfsg-1~squeeze2). From myDesktop, NSLOOKUP fails but DIG shows a CNAME record. I see the same results from the BIND server so I've included just the output from myDesktop below. Also included below is my named.conf. Do I have something obvious in BIND screwed up? Quite possibly so. And you use dig incorrectly too. me@myDesktop:~$ dig communities.intel.com ns.iotk.net this should be $ dig communities.intel.com @ns.iotk.net ;; ANSWER SECTION: communities.intel.com. 207 IN CNAME intel-2.hs.llnwd.net. so it finds the cname ... ;; AUTHORITY SECTION: llnwd.net. 604800 IN SOA localhost. root.localhost. 2008071301 604800 86400 2419200 604800 ... but your DNS has a broken record for llnwd.net. It should be ;; ANSWER SECTION: llnwd.net. 3600IN SOA dns11.llnwd.net. hostmaster.llnwd.net. 210 900 300 604800 300 Yeah, there's some nasty stuff in that nameserver's version of the llnwd.net zone: % dig llnwd.net ns +norec @99.30.25.1 ; DiG 9.4.3-P3 llnwd.net ns +norec @99.30.25.1 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1589 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;llnwd.net. IN NS ;; ANSWER SECTION: llnwd.net. 604800 IN NS localhost. ;; ADDITIONAL SECTION: localhost. 604800 IN A 127.0.0.1 localhost. 604800 IN ::1 ;; Query time: 36 msec ;; SERVER: 99.30.25.1#53(99.30.25.1) ;; WHEN: Tue Jul 5 16:02:45 2011 ;; MSG SIZE rcvd: 94 Since the nameserver is responding authoritatively, the llnwd.net zone would appear to be defined as type master or type slave, despite the fact that it was missing from the named.conf posted earlier. - Kevin ___ 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: Logging Response Results
On 6/23/2011 4:27 PM, Stefan Certic wrote: Thanks Chuck Yes, that would be a solution, but i need logs processed through syslog and stored into database (matching the initial query from query log). Pharsing tcpdump is not going to be suitable for highly loaded system. I was more looking for a solution to log responses same way queryes are logged. Regards, On Thursday, June 23, 2011 09:44:46 pm Chuck Swiger wrote: On Jun 23, 2011, at 12:16 PM, Stefan Certic wrote: Does anyone have idea on following... Apart from bind9 query log, is it possible to log response returned to client? Sure: use tcpdump, wireshark, or another network sniffer of your choice and observe DNS responses to the clients you're interested in. (Whether this is better than using query logging is another question entirely.) The parsing can be done off-line. Depending on your LAN structure, you might be able to capture the packets off-box as well. - Kevin ___ 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: servfail when refresh aws.amazon.com
On 6/22/2011 7:26 AM, Eric Yiu wrote: Hi, I am using bind9.7.3-P1 with solaris10x86. I notice that sometimes our bind server will reply servfail when querying a zone aws.amazon.com http://aws.amazon.com which is expiring, while this aws.amazon.com http://aws.amazon.com only 60sec cache lifetime, eg. /usr/local/bin/dig a aws.amazon.com http://aws.amazon.com ; DiG 9.7.3-P1 a aws.amazon.com http://aws.amazon.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26307 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1 ;; QUESTION SECTION: ;aws.amazon.com http://aws.amazon.com.IN A ;; ANSWER SECTION: aws.amazon.com http://aws.amazon.com. 1 IN A 72.21.210.163 ;; AUTHORITY SECTION: aws.amazon.com http://aws.amazon.com. 6517IN NS ns-932.amazon.com http://ns-932.amazon.com. aws.amazon.com http://aws.amazon.com. 6517IN NS ns-931.amazon.com http://ns-931.amazon.com. aws.amazon.com http://aws.amazon.com. 6517IN NS ns-912.amazon.com http://ns-912.amazon.com. aws.amazon.com http://aws.amazon.com. 6517IN NS ns-923.amazon.com http://ns-923.amazon.com. aws.amazon.com http://aws.amazon.com. 6517IN NS ns-911.amazon.com http://ns-911.amazon.com. aws.amazon.com http://aws.amazon.com. 6517IN NS ns-921.amazon.com http://ns-921.amazon.com. ;; ADDITIONAL SECTION: ns-911.amazon.com http://ns-911.amazon.com. 3108IN A 207.171.178.13 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jun 22 18:59:30 2011 ;; MSG SIZE rcvd: 190 /usr/local/bin/dig a aws.amazon.com http://aws.amazon.com ; DiG 9.7.3-P1 a aws.amazon.com http://aws.amazon.com ;; global options: +cmd ;; Got answer: *;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 20884 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0* ;; QUESTION SECTION: ;aws.amazon.com http://aws.amazon.com.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jun 22 18:59:31 2011 ;; MSG SIZE rcvd: 32 /usr/local/bin/dig a aws.amazon.com http://aws.amazon.com ^[[A ; DiG 9.7.3-P1 a aws.amazon.com http://aws.amazon.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47970 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1 ;; QUESTION SECTION: ;aws.amazon.com http://aws.amazon.com.IN A ;; ANSWER SECTION: aws.amazon.com http://aws.amazon.com. 60 IN A 72.21.210.163 ;; AUTHORITY SECTION: aws.amazon.com http://aws.amazon.com. 6516IN NS ns-932.amazon.com http://ns-932.amazon.com. aws.amazon.com http://aws.amazon.com. 6516IN NS ns-911.amazon.com http://ns-911.amazon.com. aws.amazon.com http://aws.amazon.com. 6516IN NS ns-912.amazon.com http://ns-912.amazon.com. aws.amazon.com http://aws.amazon.com. 6516IN NS ns-931.amazon.com http://ns-931.amazon.com. aws.amazon.com http://aws.amazon.com. 6516IN NS ns-921.amazon.com http://ns-921.amazon.com. aws.amazon.com http://aws.amazon.com. 6516IN NS ns-923.amazon.com http://ns-923.amazon.com. ;; ADDITIONAL SECTION: ns-911.amazon.com http://ns-911.amazon.com. 3107IN A 207.171.178.13 ;; Query time: 229 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jun 22 18:59:31 2011 ;; MSG SIZE rcvd: 190 I couldn't really see anything that would explain the SERVFAIL. Each of those nameservers appears to be a load-balancer of some sort. When queried individually for aws.amazon.com/A, they give a diversity of answers, implying that they are attempting some form of DNS geolocation. None of them seem bothered by EDNS0 or DNSSEC stuff (most likely they're completely oblivious). When queried individually for aws.amazon.com/NS, all of them except for one return a single NS record with their own name in the RDATA. The only exception I saw was ns-912.amazon.com, which returned ns-945.amazon.com. But, I don't think that's the cause of the SERVFAIL, since ns-945.amazon.com answers authoritatively for the name, even though it's not one of the delegated nameservers for the zone. Time to look at logs, run named in debug mode and/or fire up a packet tracer and see what's really going on. Possibly something between you and the amazon.com nameservers is mangling or blocking packets. - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org
Re: Doubt
On 6/20/2011 7:04 AM, Vignesh Gadiyar wrote: What do the client.c and server.c programs in the /bin/named do? They're not programs, they're C source files in the BIND distribution: % ls bin/named/client.c bin/named/server.c bin/named/client.c bin/named/server.c % As part of the build process, those source files get compiled into object files, which then get linked, along with some libraries, to produce the named executable program, which might be installed as /bin/named or some other pathname, depending on platform and/or the personal preference of whoever is building/installing it at the time. I suggest that if you're new to traditional cross-platform, open-source software development, using the C language, a diversity of compilers, linkers, libraries, etc., and you want to learn more, you pick some other package besides BIND to start the learning process. There are a number of smaller, simpler packages out there. - Kevin ___ 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: Views and no answers ...
On 6/18/2011 12:08 AM, Thomas Schweikle wrote:
Hi!
I have set up a view for one site. It is bound to change answers as
necessary for different IP-ranges. It works as far as I could see.
But with one ip-range there is a problem ...
I can query internal addresses:
!user@kvm2~# host intweb.example.de
!intweb.example.de has address 192.168.180.46
But external ones do not work:
!user@kvm2:~# host google.com
!user@kvm2:~#
The host I am trying on has address 192.168.112.4 and I've set up my
view as:
!view ex {
!match-clients { 192.168.112.0/23; };
!recursion yes;
!
!include /etc/named/master/rootns.conf;
!include /etc/named/master/localhost.conf;
!include /etc/named/master/empty.conf;
!
!zone example.de. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zhz/fwd.example;
!};
!zone mgm.example.de. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/fwd.example.mgm;
!};
!
!zone 1.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.1;
!};
!zone 112.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.112;
!};
!zone 113.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.113;
!};
!zone 180.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.180;
!};
!zone 181.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.181;
!};
!
!zone hz.example.de. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/fwd.example.hz;
!allow-update { key examplekey; };
!};
!zone in.example.de. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/fwd.example.in;
!allow-update { key examplekey; };
!};
!zone no.example.de. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/fwd.example.no;
!allow-update { key examplekey; };
!};
!
!zone 1.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.1;
!allow-update { key examplekey; };
!};
!zone 112.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.112;
!allow-update { key examplekey; };
!};
!zone 113.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.113;
!allow-update { key examplekey; };
!};
!zone 180.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.180;
!allow-update { key examplekey; };
!};
!zone 181.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.181;
!allow-update { key examplekey; };
!};
!};
Any idea why the server resolves internal names, but no external
ones to this view, while it does answer internal and external names
to an other view (same setup, only a different view-line)?
!view no {
!match-clients { 127.0.0.1/8; 192.168.180.0/23; };
!recursion yes;
![... same as above ...]
I've set up query logging, but this just tells me queries are
correctly processed. But not why no answer was sent.
1. Turn on query logging. See where the query is coming from and what
view is being matched.
2. What's in those include files? You're not showing a complete
picture of your config
3. What on earth is in-dyn.arpa?
4. What's with all the trailing dots in your zone names? At the very
least, they occupy unnecessary space; at the worst, they might be
confusing named.
Re: I can't resolve one domain: nhs.uk
On 6/17/2011 8:01 AM, Phil Mayers wrote: On 17/06/11 12:10, Andrew Benton wrote: And it works well for every domain on the internet. Except for www.nhs.uk - I can't resolve nhs.uk www.nhs.uk is, currently, a CNAME to www.prod.nhs.uk.akadns.net You might be suffering from the bind 9.8 CNAME issue. See the recent, repeated discussions in the archives, including a link to a quick one-line patch you can apply to see if it fixes it. I know this is a moot point now (since Andrew eventually discovered that upgrading his Netgear router's firmware fixed the problem), but it was obvious from the first post of the thread that it was *not* a CNAME issue, since Andrew was having problems resolving an A record for even the name nhs.uk: Jun 17 12:02:38 eccles named[4689]: client 127.0.0.1#36651: query failed (SERVFAIL) for nhs.uk/IN/A at query.c:6199 I'm happy for Andrew that his problem is fixed, but it would have been more satisfying to know what the root cause was. Upgrading the firmware fixed it unfortunately doesn't even necessarily imply that there was a bug in the old version of firmware, since sometimes the mere act of upgrading a networking device clears out some bogus/corrupted configuration data and thus fixes the problem. - Kevin ___ 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: question about thehartford.com domain
On 6/15/2011 7:41 PM, M. Meadows wrote: The DNS admins at thehartford.com seem to feel that this nameserver mismatch is working as expected. Here's some of the feedback we received from them when we questioned the setup: ~ We use load balancers for the majority of our internet facing URLs. We have multiple datacenters. We typically have our URLs defined in multiple datacenters. Each datacenter has a pair of redundant load balancers. Typically each URL we have is defined in each datacenter with its own address. The active load balancer in a particular datacenter 'owns' one of the NS servers you see when you lookup our authoritative name servers, ie: ns1 or ns2.thehartford.com. There is a 'floating' address shared between the active and failover load balancers that is associated with ns1 or ns2.thehartford.com. hfdns3, hfdns4, simns3, simns4 are the addresses for the specific bind processes running on the actual physical devices. NS1.thehartford.com will be shared between hfdns3 and hfdns4. NS2.thehartford.com between the simns3 and simns4 name servers. ~ So I'm just wondering if anyone still feels that the nameserver mismatch seen with the digs in earlier parts of this email thread may present a problem to servers requesting name resolution for address records in the thehartford.com domain. Do they understand that the in-zone NS records *override* the delegation NS records (see RFC 2181) when seen, so they're forcing the rest of the Internet to refresh all 8 records (4 NSes and 4 As) potentially as often as every 120 seconds? That seems rather inconsiderate. Also, what's the point of having load-balancer VIPs in your delegation records, if they're just going to be overwritten, in cache, with the real IPs of the BIND processes anyway? Are they really getting their money's worth from those load-balancers, which aren't used most of the time for this particular function? Load-balancer or no load-balancer, I think the Best Practice of Under normal circumstances, your delegation records should match your in-zone records still applies here. The only exception to that general rule is when you're migrating from one set of nameservers to another. - Kevin From: sun-g...@live.com To: mich...@rancid.berkeley.edu Subject: RE: question about thehartford.com domain Date: Wed, 15 Jun 2011 12:59:32 -0400 CC: bind-users@lists.isc.org Just wanted to say thanks to everyone for the quick feedback! We appreciate your assistance on this. Marty Date: Wed, 15 Jun 2011 08:25:00 -0700 From: mich...@rancid.berkeley.edu To: sun-g...@live.com CC: bind-users@lists.isc.org Subject: Re: question about thehartford.com domain On Wed, 15 Jun 2011, M. Meadows wrote: Question : our check of whois indicates that ns1.thehartford.com and ns2.thehartford.com are the authoritative nameservers for thehartford.com. A dig with a +trace for eftc.thehartford.com seems to indicate that they are indeed the auth nameservers. It?s interesting, though, that an http://www.kloth.net/services/nslookup.php lookup for thehartford.com query for NS records shows a non-authoritative answer of hfdns3.thehartford.com, hfdns4.thehartford.com, simns3.thehartford.com, simns3.thehartford.com and simns4.thehartford.com. We?re unsure what?s going on with that. Instead of doing 'dig +trace eftc.thehartford.com', do 'dig +trace ns thehartford.com', and you'll see the problem. This is a classic authority mismatch, as others have pointed out. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Trouble
On 6/12/2011 4:00 PM, Rodrigo Faria Tavares wrote:
Hello,
I installed bind in CentOS release 5.6 (Final).
My DNS Server not ping alias (with cname), so the steps:
I installed this packages:
[root@centos ~]# rpm -qa | grep bind
ypbind-1.19-12.el5
bind-libs-9.3.6-16.P1.el5
bind-chroot-9.3.6-16.P1.el5
bind-9.3.6-16.P1.el5
bind-utils-9.3.6-16.P1.el5
[root@centos ~]# rpm -qa | grep nameserver
caching-nameserver-9.3.6-16.P1.el5
[root@centos ~]#
Then i'm using chroot.
[root@centos ~]# cd /var/named/
[root@centos named]# ls -las
total 32
8 drwxr-x--- 5 root named 4096 Jun 12 14:58 .
8 drwxr-xr-x 24 root root 4096 Jun 12 10:04 ..
8 drwxr-x--- 7 root named 4096 Fev 22 19:35 chroot
4 drwxrwx--- 2 named named 4096 Jun 12 14:58 data
0 lrwxrwxrwx 1 root named 45 Jun 12 14:58 localdomain.zone
- /var/named/chroot//var/named/localdomain.zone
0 lrwxrwxrwx 1 root named 43 Jun 12 14:58 localhost.zone
- /var/named/chroot//var/named/localhost.zone
0 lrwxrwxrwx 1 root named 44 Jun 12 14:58 named.broadcast
- /var/named/chroot//var/named/named.broadcast
0 lrwxrwxrwx 1 root named 37 Jun 12 14:58 named.ca
- /var/named/chroot//var/named/named.ca
0 lrwxrwxrwx 1 root named 44 Jun 12 14:58 named.ip6.local
- /var/named/chroot//var/named/named.ip6.local
0 lrwxrwxrwx 1 root named 40 Jun 12 14:58 named.local
- /var/named/chroot//var/named/named.local
0 lrwxrwxrwx 1 root named 39 Jun 12 14:58 named.zero
- /var/named/chroot//var/named/named.zero
0 lrwxrwxrwx 1 root named 43 Jun 12 14:58 redefariat.com
- /var/named/chroot//var/named/redefariat.com
Now I configured the domain.
[root@centos named]# cat /var/named/chroot//var/named/redefariat.com
$TTL43200
@ IN SOA redefariat.com. root.redefariat.com. (
2011061214 ; Serial
28800 ; Refresh
14400 ; Retry
360 ; Expire
86400 ; Minimum
)
@ IN NS redefariat.com.
@ IN MX 0 mail.redefariat.com
@ IN A 192.168.1.100
IN CNAME redefariat.com.
ftp IN CNAME redefariat.com.
mailIN CNAME redefariat.com.
pop IN CNAME redefariat.com.
pop3IN CNAME redefariat.com.
smtpIN CNAME redefariat.com.
rodrigo IN A 192.168.1.100
rodrigo.redefariat.com.IN A 192.168.1.100
So I put in /etc/named.caching-nameserver.conf.
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
// Those options should be used carefully because they disable
port
// randomization
// query-sourceport 53;
// query-source-v6 port 53;
allow-query { localhost; };
allow-query-cache { localhost; };
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
view localhost_resolver {
match-clients { localhost; };
match-destinations { localhost; };
recursion yes;
include /etc/named.rfc1912.zones;
};
view redefariat {
match-clients {192.168.1.0/24;};
recursion yes;
zone redefariat.com {
type master;
file /var/named/redefariat.com;
allow-transfer { none; };
};
};
The logs :
root@centos named]# tail -f /var/log/messages
Jun 12 16:54:35 centos named[3343]: listening on IPv4 interface lo,
127.0.0.1#53
Jun 12 16:54:35 centos named[3343]: command channel listening on
127.0.0.1#953
Jun 12 16:54:35 centos named[3343]: zone
0.in-addr.arpa/IN/localhost_resolver: loaded serial 42
Jun 12 16:54:35 centos named[3343]: zone
0.0.127.in-addr.arpa/IN/localhost_resolver: loaded serial 1997022700
Jun 12 16:54:35 centos named[3343]: zone
255.in-addr.arpa/IN/localhost_resolver: loaded serial 42
Jun 12 16:54:35 centos named[3343]: zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN/localhost_resolver:
loaded serial 1997022700
Jun 12 16:54:35 centos named[3343]: zone
localdomain/IN/localhost_resolver: loaded serial 42
Jun 12 16:54:35 centos named[3343]: zone
localhost/IN/localhost_resolver: loaded serial 42
Jun 12 16:54:35 centos named[3343]: zone redefariat.com/IN/redefariat:
loaded serial 2011061214
Jun 12 16:54:35 centos named[3343]: running
I try use ping www.redefariat.com
root@centos named]# ping www.redefariat.com
ping: unknown host www.redefariat.com
What is wrong
Re: bind 9 performance
On 6/15/2011 4:06 PM, abushla...@ies.etisalat.ae wrote: What about zone configuration in BIND 8 and BIND 9? Is there any difference between the two ? Thanks Regards -Original Message- From: Eivind Olseneiv...@aminor.no Sender: bind-users-bounces+abushlaibi=ies.etisalat...@lists.isc.org Date: Wed, 15 Jun 2011 20:30:58 To:bind-users@lists.isc.org Subject: Re: bind 9 performance hugo hugoo wrote: - Has anyone faced a performance problem due to an upgrade bind8/bind9? I didn't notice anything like that when I last upgraded from BIND8 (back in 2001 or so). When that is said: what kind of hardware are you running it on? Single CPU? Multiple cores? I've seen some fairly ancient performance comparisons between BIND8 and BIND9 that claimed BIND8 performed best on a single-core CPU only. And if I'm not mistaken, BIND9 had some less-than-optimal threading back in those days, and performs much better now. Is pure performance important to you? Will you be likely to even notice? Also, BIND8 has been deprecated for almost 4 years now. See doc/misc/migration. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: link-local glue AAAA
On 6/5/2011 9:07 AM, Peter Andreev wrote: Hi I'm puzzled a little - i see in my zone glue records with link-local addresses. I think it is not good, but no rfc mentions about link-local in glue. Could someone tell me best practices for link-local in glue? Well, some things are so obvious we don't state them explicitly. If an address is local *only* to a particular link, then it's not going to be useful for anyone else who doesn't happen to be on that link. Right? So why publish something that's useless to the vast majority of DNS consumers? There is an *Informational* RFC (4472) which outlaws link-local addresses in DNS (Section 2.1), but you probably won't find anything in Standards Track due to the obviousness factor. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Compromised BIND?
On 5/31/2011 2:38 PM, Supersonic wrote: I have a BIND 9.8.0-P2 server instance running on a production server. Doing what, exactly? Resolving internal names only? Resolving Internet names? Acting as an authoritative server for internal clients? Internet clients? Some combination of the above? My firewall is showing repeated attempts by named.exe to connect to IP addresses in foreign countries on ports , 6667 and 6669 - common IRC ports used by worms/trojans/zombies. Checking my named.exe file, it shows that it is unchanged from the installation source. Is this connection normal? Should I be allowing it? TCP connections or UDP packets? If you're serving authoritative data to Internet clients, then my guess is your firewall simply isn't stateful enough to realize that these are responses to DNS queries that originally came in from Internet clients using those port numbers. Just because they are common IRC ports used by worms/trojans/zombies doesn't preclude them from also being chosen at random as the source ports of incoming queries to your nameserver. Responses go back to the same port from which the query was received. If they're outgoing TCP connections, I'd be worried. Offhand, I can't think of any legitimate reason why named would be trying to TCP-connect to any port other than 53. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
Normally I'd defer to your vastly greater knowledge and experience in DNSSEC, but here in the U.S. we have a saying I'm from Missouri, which is a roundabout way of expressing show me (Show Me being the unofficial slogan of the state of Missouri). Maybe it *should* work, but when it comes to nifty technical hacks, until co-existence is actually demonstrated, I still think there might be a gotcha somewhere... - Kevin P.S. Don't even get me started on car commercials. I've seen a few that never even made it to the public eye :-) On 5/30/2011 8:18 PM, Mark Andrews wrote: In message4de42bef.3050...@chrysler.com, Kevin Darcy writes: Get back to us when you prove that this co-exists with DNSSEC; otherwise it's a non-starter. While you're at it, some data proving that this actually enhances performance or availability would be nice too. On further examination it will work w/ DNSSEC. As for availability it will decrease it as there is no way the client can do the failover for itself as it no longer has the necessary data. As for performance, your milage may vary, as they say in car commercials. Mark ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive server querying authoritative - timeout before trying next server?
On 5/26/2011 2:51 PM, Dan Pritts wrote: Hi, A question regarding BIND defaults. I'd love the same answer for other nameserver software if anyone cares to share. I am a recursive nameserver. I am looking for foo.bar.com. i've learned from bar.com that foo.bar.com has four NS records. I've never tried to talk to these servers before. I send a query to the address listed in the first NS record. I never get an answer? How long do I wait before trying the next one? I looked through several RFCs but couldn't find anything specific in the spec. RFC1035 mentions that choosing this timeout would be up to nameserver implementors and suggests 5-10 seconds as a reasonable default. my google-fu is failing me on this one. I found something at Microsoft that suggests that their DNS server waits 3 seconds although i may have interpreted that wrong. I found a reference to a nameserver called deadwood that defaults to 2 seconds. But, I couldn't find anything on BIND. Dan, I don't know the exact timing, but with BIND it's on the order of tenths of a seconds (or 100s of milliseconds, if you prefer). 2 seconds would be way too slow. It shouldn't be hard to set up a test delegation with one dead nameserver and restart/query named a few times to see how long the failover takes... - Kevin P.S. You guys are practically next door to where I live (Pitt Twp), let me know if you need any help with this :-) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deny MX query
On 5/25/2011 9:21 AM, Niobos wrote: On 2011-05-24 21:58, Warren Kumari wrote: On May 24, 2011, at 1:55 PM, Igor da Silva Cagnin wrote: I have a doubt about querys, as fact I’d like to deny just querys type MX. Other querys types must be available. Is it possible? Yes. 1: Don't list the MX record in your zone. or 2: Have multiple views, one with MX records, one without No, that would return NODATA. The original poster was looking for a deny, which I interpret as REFUSED. I think that's a pretty narrow interpretation of deny. Definition #2 of deny from dictionary.com reads to refuse to agree or accede to: to deny a petition, but definition #3 reads to withhold thepossession, use, or enjoyment of: to deny access to secret information. I think returning NODATA falls under definition #3. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: norecursion on external zone, but how do I allow CNAMEs to be fully resolved?
This is why people run separate views, separate instances, or separate devices for DNS resolution (= recursive, by necessity) versus DNS hosting (= non-recursive, best practice). If you run both hosting and resolution on the same nameserver instance but different views, you may need to be a little careful about how you resolve names in your own zones (don't recurse to the same view otherwise you may end up in an infinite loop situation!), and especially if you're publishing a NAT'ed address for your nameserver(s). Within named.conf, you can limit recursive resolution by client address or by view. You can't limit it by zone, because, on deeper analysis, that actually doesn't make any sense anyway -- either you are authoritative for a given zone, in which case no recursion is necessary, or you're not authoritative, in which case recursive resolution is *always* necessary. - Kevin On 5/20/2011 2:16 AM, Tory M Blue wrote: So I'm been having dns issues for a while, differing issues that pop up and I knock them down , but another just came to my attention which has me stumped. My external zone config has allow-recursion ( none; ); However I have some 3rd party sites that I CNAME too. Akamai for example, yes CNAME to CNAME , i know I know :).. Well my primary NS servers will only provide the CNAME record: ;; QUESTION SECTION: ;cdn.domain.net.IN A ;; ANSWER SECTION: cdn.domain.net. 300 IN CNAME cdn.domain.net.edgesuite.net. This causes all types of failures if just using dig, or Linux built in lookup mechanism, or heck Perl or PHP methods as well. None of the stated methods, know that they should now query cdn.domain.net.edgesuite.net, so they provide the CNAME and SERVFAIL or whatever. Is there a way to allow any host to actually do a recursive lookup if the request starts out on my domain, in order to receive the A record? Or do I just have to enable recursion on my external zone? The problem there obviously, is now joe and frank can use my dns servers because it performs a bit better than their ISP's. I don't want that, but I do want to provide the extended information for that CNAME record. Oh ya still on bind-9.7.2-P3 , fedora based system I'm missing something, but since it's gosh knows who that will be querying for cdn.domain.net there really is no ACL I can use, it has to be all. And based on some failures, I have to do the leg work for each client, i have to provide them the necessary information in that one request. Thanks again Tory ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Primary Server Name Change
On 5/12/2011 3:21 PM, Michelle Konzack wrote: Hello CT, Am 2011-05-12 13:09:35, hacktest Du folgendes herunter: Primary Name server bind- 9.7.3 OS- CentOS 5.6 Authoritative for 2 zones using DNSSEC This may be an obvious question but I will ask anyway.. :) I want to change the name of the server from old.zone1.com to new.zone2.com IP Address - no change - change soa in master zone files - work with slaves to make sure named.conf are correct Other than that are there any gotchas.. ?? I am wondering if I will have to unsign my zones and the upload new keysets to the registrar. What does this havve to do with my Test-Message? Threading on mailing lists has been broken since approximately forever. The CT poster no doubt hit respond to your post and then changed the Subject: and body of their message, rather than creating a new message to the list. It's a newbie mistake, to be sure, but a fairly common one. This is the risk one always runs when posting to the list. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forward first: iterative or recursive query
On 5/6/2011 6:40 AM, iharrathi@orange-ftgroup.com wrote:
Thanks for the answer but:
*
In the example i post yesterday: on my server1 the recursion is
enabled (recursion yes), but the server1 can't recurse because i
stop it on firewall and it can't contact the outside.
*
You say Don't use forwarding from a recursive server to a
non-recursive server but when my server1 is recursive (and the
firewall allow it to contact the outside), and server2 don't
recurse because in it's conf recursion is set to no, when i ask
my server1 about ftp.example.com ftp://ftp.example.com (dig @0
ftp.example.com ftp://ftp.example.com) , server1 forward the
query to server2 which answer by the CNAME www.abc.com
http://www.abc.com and then server1 recurse to find the IP of
www.abc.com http://www.abc.com. and everything works fine.
*
you say If server 2 is auth-only or otherwise can't resolve the
address of www.abc.com http://www.abc.com/, then forwarding a
query to it is not going to work. No as i say when server1
really recurse ( recursion yes, and the firewall allow the
server1 to contact outside) and server2 don't recurse (recursion
no) all is ok: server1 forward the query to server2 which answer
by the CNAME www.abc.com http://www.abc.com/ and then server1
recurse to find the IP of www.abc.com http://www.abc.com/. and
everything works fine.
*
You say then using a stub zone for example.com
http://example.com/will work, why i will use a stub zone
since a forward do the same thing expected.
And my question is always this:
forward only; as i read means a recursive query, in other term a query
with the RD bit is enabled. which means that when my server1 (which
has recursion yes but can't recurse because the firewall don't
allow it to contact the outside, which finally means server1 can't
recuse) ask server2 about ftp.example.com ftp://ftp.example.com,
server2 will normally make all the work means he read on it's zone,
then find the CNAME, then make a recursion to resolve the CNAME and
finally send the IP to server1.
why server2 don't recurse to find the IP of www.abc.com?
According to your own words: server2 don't [sic] recurse because in
it's [sic] conf recursion is set to no. There's your answer.
Why are you dealing with such screwy configs anyway? If you need to
resolve things from the Internet, then you need to have a resolution
path to the Internet (either directly talking to Internet nameservers,
or some forwarding chain -- hopefully as short as possible, preferably
0-length -- to something that can query Internet nameservers directly).
If, on the other hand, you need to resolve something internal, then you
only need to have an authoritative source of that information
internally. Why are you complicating things more than they need to be?
Setting recursion and then blocking it via a firewall? What purpose does
that serve?
- Kevin
thanks for your help.
*De :* Chris Buxton [mailto:chris.p.bux...@gmail.com]
*Envoyé :* jeudi 5 mai 2011 19:47
*À :* HARRATHI Issam Ext OLNC/DPS
*Cc :* bind-users@lists.isc.org
*Objet :* Re: forward first: iterative or recursive query
If recursion is disabled, forwarding doesn't happen. I think
you've confused some terms and configurations.
Don't use forwarding from a recursive server to a non-recursive
server. Use a stub zone instead, if you can't rely on the
recursion process to find the correct server to query.
If server 2 is auth-only or otherwise can't resolve the address of
www.abc.com http://www.abc.com, then forwarding a query to it is
not going to work. However, if server 1 is a caching server and is
able to resolve www.abc.com http://www.abc.com, then using a
stub zone for example.com http://example.com will work; server 2
will send the CNAME record to server 1, and then server 1 will
resolve the final address record on its own.
Chris Buxton
BlueCat Networks
On May 5, 2011, at 2:15 AM, iharrathi@orange-ftgroup.com
mailto:iharrathi@orange-ftgroup.com
iharrathi@orange-ftgroup.com
mailto:iharrathi@orange-ftgroup.com wrote:
Hi,
i have a server called server1 that is acting as a cache server(
recursion none). And i forward the zone example.com
http://example.com to server2 which has recursion enabled and
master on some zone like example.com http://example.com.
this is the forwarding zone on server1:
zone example.com http://example.com {
type forward;
forward only;
forwarders { IP_of server2;
Re: does authority named require the external name servers?
On 5/2/2011 9:50 PM, Jeff Pang wrote: 2011/5/3 Jeff Pangjeffrp...@gmail.com: 2011/5/3 Chris Thompsonc...@cam.ac.uk: It will need to know the addresses of ns1.def.com ns2.def.com to send them NOTIFY packets when the zone is updated (unless that has been suppressed). But it gets those by (if necessary) recursive lookups based on its root hints (compiled in or otherwise), not by using the OS resolver. Hi Chris, That's what the real question I want to know. For example, my DNS Servers have lots of domains hosting, all the zones have the same NS RRs: ns1.dnsbed.com ns2.dnsbed.com But dnsbed.com is not authority resolved by my own nameservers. So, I was asking when there is not correct entries in /etc/resolv.conf if named will find the ns1 and ns2.dnsbed.com correctly from the root hint. And why I want to make sure it get the results from root hint, because when I update my NS record's values, I want to let BIND know it quickly, not effected by the old TTL. If you want *everyone* to switch over to the new NS records quickly, at the expense of some query churn, you need to lower the TTLs on the NS records prior to the change. If you want just *your* BIND-based resolver(s) to switch over to the new NS records quickly, without all of the churn that's caused by lowering TTLs on NS records, then use rndc flushname right after the NS records have been updated on the authoritative nameservers. Neither of these options have anything whatsoever to do with /etc/resolv.conf or hints files. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamic update to the wrong DNS zone file - Bind View - dhcp-client-identifier - multiple network cards with multiple differents subnets
On 4/21/2011 10:17 AM, Flex Banana wrote:
hello list,
I use dhcpd-4.2.1 with bind-9.7.3 on a SuSE system.
I have 3 network cards with under 700 differents subnets declared in the
dhcpd.conf.
eth0 = 10.1.1.50
eth1 = 172.16.1.50
eth2 = 192.168.1.50
We use Dynamic DNS update with the dhcp-client-identifier option to set
settings to my different clients.
We also use Bind View to differentiate all differents zones with differents
subnets (we have almost 90 zones)
This is a part of our dhcpd.conf file:
if substring (lcase (option dhcp-client-identifier), 1, 9) = marketing
{
option domain-name marketing.example.com;
option domain-search marketing.example.com;
zone marketing.example.com. { primary 10.1.1.50; key
OUR_KEY; }
}
elsif substring (lcase (option dhcp-client-identifier), 1, 6) = design
{
option domain-name design.example.com;
option domain-search design.example.com;
zone design.example.com. { primary 10.1.1.50; key
OUR_KEY; }
}
else
{
option domain-search publisher.example.com;
}
Another part of dhcpd.conf with subnet declarations:
subnet 10.1.1.0 netmask 255.255.255.0
{
option routers 10.1.1.1;
range 10.1.1.20 10.1.1.199;
option subnet-mask 255.255.255.0;
option domain-name-servers 10.1.1.50;
zone 1.1.10.in-addr.arpa. { primary 10.1.1.50; key
OUR_KEY; }
}
subnet 172.16.1.0 netmask 255.255.255.0
{
option routers 172.16.1.1;
range 172.16.1.20 172.16.1.199;
option subnet-mask 255.255.255.0;
option domain-name-servers 172.16.1.50;
zone 1.16.172.in-addr.arpa. { primary 172.16.1.50; key
OUR_KEY; }
}
subnet 192.168.1.0 netmask 255.255.255.0
{
option routers 192.168.1.1;
range 192.168.1.20 192.168.1.199;
option subnet-mask 255.255.255.0;
option domain-name-servers 192.168.1.50;
zone 1.168.192.in-addr.arpa. { primary 192.168.1.50;
key OUR_KEY; }
}
This is a part of the named.conf file:
view 10.1 {
match-destinations { 10.1.1.50; };
match-clients { 10.1.1.0/24; };
zone marketing.example.com in {
allow-update { key OUR_KEY; };
allow-transfer { none; };
file dyn/marketing.exemple.com_10.1;
type master;
};
zone design.example.com in {
allow-update { key OUR_KEY; };
allow-transfer { none; };
file dyn/design.example.com_10.1;
type master;
};
view 172.16 {
match-destinations { 172.16.1.50; };
match-clients { 172.16.1.0/24; };
zone marketing.example.com in {
allow-update { key OUR_KEY; };
allow-transfer { none; };
file dyn/marketing.exemple.com_172.16;
type master;
};
zone design.example.com in {
allow-update { key OUR_KEY; };
allow-transfer { none; };
file dyn/design.example.com_172.16;
type master;
};
view 192.168 {
match-destinations { 192.168.1.50; };
match-clients { 192.168.1.0/24; };
zone marketing.example.com in {
allow-update { key OUR_KEY; };
allow-transfer { none; };
file dyn/marketing.exemple.com_192.168;
type master;
};
zone design.example.com in {
allow-update { key OUR_KEY; };
allow-transfer { none; };
file dyn/design.example.com_192.168;
type master;
};
The problem is that when i use a client in the others subnets than 10.1.1.0/24, all
dynamics updates harent writed to the zone (marketing.example.com or design.example.com)
with the primary address of 10.1.1.50 and a message of Forward map from
FAILED: Has an address record but no DHCID, not mine.
And when you read the forward zone (e. g with nano or cat) the A adress is
entered but from the wrong subnet.
Example for the file desing.example.com_10.1 (zone dedicated
laptop A 172.16.1.17 //
updated dynamically
The solution, i think, is to test the
Re: Forwarding a subzone of a master zone
I'd like to reinforce what Chris said, and recommend the use of an internal root zone for networks/enterprises which have no public Internet connectivity, or whose connectivity to the Internet is exclusively through application-level proxies. Don't make Internet names resolvable on your internal network if that resolution isn't necessary -- this provides a level of security in addition to your other levels (see Defense in Depth), since many worms and malware can't recover from DNS resolution failure of whatever Internet name they're trying to resolve. It also allows you to better control your own DNS destiny, including blackholing of various domains, if that should become necessary in an emergency. Another optional benefit is it allows you to centrally control your mail routing, if you have MTAs that use the standard MX-record method of routing SMTP mail. A lot of people seem to be scared by the prospect of setting up their own root zone. It's really not much different than any other zone, except that -- there is no delegation from any parent zone (obviously), and -- all of your other nameservers need to slave, stub, forward or have hints files referring to your own internal root-zone infrastructure, rather than the Internet root-zone infrastructure. This means you can't use the compiled-in defaults for the root zone, but those are useless to you anyway if you don't have direct connectivity to those nameservers. - Kevin On 4/19/2011 4:37 AM, Chris Buxton wrote: You're getting a bit confused, because your configuration is complex. Some of your observations are in contradiction with your disabling of recursion, so I believe you are partially mistaken. - You're mixing authoritative and recursive service in one config. This often leads to confusion. - Your recursion algorithm must be able to track down a particular domain while not being able to resolve from the Internet root. Rather than turning off recursion, why not just set up your own root zone (type master)? That way, your server can recurse to sub.example.com based on the delegation, while returning immediate negative answers for anything unknown. Just make sure you delegate example.com (and all other zones) from your private root zone. A forwarders list in example.com or a zone of type forward named sub.example.com will not have any effect so long as recursion is disabled. Forwarding is a configuration aspect of the recursion algorithm. Regards, Chris Buxton BlueCat Networks On Apr 18, 2011, at 11:57 PM, Olivier Cherrier wrote: Hi, I am experiencing problems to get a working forwarding configuration. I am using BIND 9.3.6-P1 and the server has the global recursion parameter on. The server is not on a public network (not on Internet -- no access to root servers). I have a zone called example.com for which the server is master. A delegation called sub.example.com is in place and is working well. I want to change the recursion parameter from 'yes' to 'no' in order to get rid of the timeouts we get when we query something that is not defined in our DNS server (like www.google.com). Doing this breaks the delegation sub.example.com, meaning the server doesn't do the research anymore for the subzone. So I deleted the delegation and configured a forward zone to the right IP addresses. The problem is named doesn't even try to query those forwarders and directly reply: No answer While it works for some other forwarded zones (reverse and non-reverse), I fail to understand why it doesn't work for that particular zone. The only difference I see is that this forwarded zone is a subzone of example.com for which the server is master. So my question: Is there any limitation to forward a subzone while we are master for the parent zone? Thanks a lot! Best regards. -- Olivier Cherrier - Symacx.com mailto:o...@symacx.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multiple IP address in Address Record in BIND
On 4/17/2011 2:49 PM, Ben Croswell wrote: In the bind 8 days people would put the same address multiple times and then other addresses as well to weight the responses. -Ben Croswell On Apr 17, 2011 2:45 PM, Eivind Olsen eiv...@aminor.no mailto:eiv...@aminor.no wrote: Hi, we have internal domain called sva.com http://sva.com and address record for this sva.com http://sva.com is pointed to many IP addresses. When i do nslookup, i am getting below output. I would like to enable the same configuration in bind. Let us know how this can be acheived. #nslookup sva.com http://sva.com Name: sva.com http://sva.com Addresses: 10.10.10.10, 10.10.10.10, 10.10.10.10, 10.10.10.10,10.10.10.10 You would like it to point to the same IP-address many times? Why? No longer legal: It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered (RFC 2181, Section 5). - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 fails resolving after connecting to VPN
On 4/12/2011 4:33 AM, kapetr wrote: Hello, Kevin Darcyk...@chrysler.com WROTE: Do You thing, that this VPN provider - blocks direct (not recursive) DNS questions and - manipulates recursive queries ? [catch them, make query itself and answers with manipulated server IP] ??? None of your queries were non-recursive (you'd need +norec on your dig command line for that), so I wouldn't jump to the conclusion that non-recursive queries are being blocked. I did mean queries from my local BIND, not from dig command. What's more likely happening is that *all* of your queries are being transparently redirected to a recursive resolver. Although, I'd be curious to see what responses you get if you actually generate non-recursive queries (with the +norec). I have try it. Unfortunately ... I have get normal answers (from DNS server in Internet, which was accessed over the new default route == over VPN) even with +norecurse or +trace. These non-recurse queries have go over the VPN and I have get normal answers. :-( How normal are they? BIND is likely to reject them if they purport to be from authoritative data, but the AA flag isn't set... - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: priority with A record?
On 4/8/2011 2:42 PM, John Wobus wrote: All the previously-mentioned issues apply, but (obviously) round robin could be made to offer a select server twice as often by giving that server an additional address and A record. Something similar for nameservers could be devised. Mostly unnecessary for nameservers, since as previously mentioned RTT (round-trip time) values are used for nameserver selection, if available, and is tracked by IP address, not by nameserver name. I had a vague recollection that one could simply duplicate an A record in the zone file, but perhaps my memory is playing tricks on me. That may have worked at one time, but not for anything that conforms to RFC 2181 (published July 1997), Section 5 (It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered). - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 fails resolving after connecting to VPN
On 4/11/2011 7:18 AM, kapetr wrote: Hello, interesting ... - PŮVODNÍ ZPRÁVA - Od: Stacey Marshallstacey.marsh...@gmail.com Komu: kapetrkap...@mizera.cz Předmět: Re: BIND9 fails resolving after connecting to VPN Datum: 9.4.2011 - 22:50:44 I' wondering if the network your attaching to via VPN allows direct DNS lookups? I know of networks where the provided servers have firewall rules that allow them to make queries but other servers are not. You could test this theory by trying to connect to a root server with dig when connected to VPN. For example: $ dig @h.root-servers.net. www.seznam.cz Regards, Stace Why should VPN provider filter (disable) direct queries and allow only recursive queries ? The results are (for me) surprising: 1. before VPN: my (127.0.0.1) and ISPs servers work OK and: hugo@duron650:~$ dig @h.root-servers.net. www.seznam.cz ; DiG 9.7.1-P2 @h.root-servers.net. www.seznam.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20035 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 10 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.seznam.cz. IN A ;; AUTHORITY SECTION: cz. 172800 IN NS a.ns.nic.cz. cz. 172800 IN NS b.ns.nic.cz. cz. 172800 IN NS c.ns.nic.cz. cz. 172800 IN NS d.ns.nic.cz. cz. 172800 IN NS f.ns.nic.cz. ;; ADDITIONAL SECTION: a.ns.nic.cz.172800 IN A 194.0.12.1 b.ns.nic.cz.172800 IN A 194.0.13.1 c.ns.nic.cz.172800 IN A 194.0.14.1 d.ns.nic.cz.172800 IN A 193.29.206.1 f.ns.nic.cz.172800 IN A 193.171.255.48 a.ns.nic.cz.172800 IN 2001:678:f::1 b.ns.nic.cz.172800 IN 2001:678:10::1 c.ns.nic.cz.172800 IN 2001:678:11::1 d.ns.nic.cz.172800 IN 2001:678:1::1 f.ns.nic.cz.172800 IN 2001:628:453:420::48 ;; Query time: 144 msec ;; SERVER: 128.63.2.53#53(128.63.2.53) ;; WHEN: Mon Apr 11 12:56:18 2011 ;; MSG SIZE rcvd: 338 hugo@duron650:~$ 2. after VPN up: - my (127.0.0.1) fails again - connection timed out; no servers could be reached - ISPs server OK again - I get normal A answer - DNS root server - by name (IP get from ISPs server) or by IP gives: hugo@duron650:~$ dig @h.root-servers.net. www.seznam.cz ; DiG 9.7.1-P2 @h.root-servers.net. www.seznam.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2758 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.seznam.cz. IN A ;; ANSWER SECTION: www.seznam.cz. 203 IN A 77.75.72.3 ;; Query time: 67 msec ;; SERVER: 128.63.2.53#53(128.63.2.53) ;; WHEN: Mon Apr 11 12:58:52 2011 ;; MSG SIZE rcvd: 47 hugo@duron650:~$ * So why the h.root-servers.net == 128.63.2.53 in case 2 (over VPN) gives the recursive answer ? Do You thing, that this VPN provider - blocks direct (not recursive) DNS questions and - manipulates recursive queries ? [catch them, make query itself and answers with manipulated server IP] ??? None of your queries were non-recursive (you'd need +norec on your dig command line for that), so I wouldn't jump to the conclusion that non-recursive queries are being blocked. What's more likely happening is that *all* of your queries are being transparently redirected to a recursive resolver. Although, I'd be curious to see what responses you get if you actually generate non-recursive queries (with the +norec). If it's redirecting non-recursive queries to some caching nameserver, then that probably explains why named goes stupid when the VPN is up, since it won't be able to use the non-authoritative answers it sees. One thing that will break horribly with this transparent query redirection is any form of shared-key authentication (e.g. TSIG). DNSSEC, on the other hand, is end-to-end, so offhand I think it'll be unaffected. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: programmatically determining whether any zones frozen?
On 4/8/2011 10:56 AM, jeffreyp wrote: greetings, is there a way to programmatically determine if there are any zones frozen? if so, any way to determine the specific zone(s)? what i'm wanting to do is write a monitoring script to sound an alert if there are any zones that have been frozen for more then x minutes. rndc doesn't provide that info and i haven't found anything else to accomplish the task. Try a dummy Dynamic Update and see if it gets REFUSED (???) Generally speaking, it would be the Dynamic Update clients that alert if they can't get their updates done, not something you'd monitor directly on the server itself. I think a better question to ask is: why are zones being frozen in the first place? We never freeze our zones. All updates are done through Dynamic Update, even the specials or break/fix stuff. At the risk of sounding like a Dynamic Update snob, I consider the freeze/thaw stuff just an awkward transition mechanism on the way to a pure Dynamic Update environment. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: priority with A record?
On 4/5/2011 8:23 AM, iharrathi@orange-ftgroup.com wrote: Hi, can i make priority on a A or NS record? Since with round robin if i put the same record record 2 or 3 time, Bind ignore the duplicates Records, means this: wikipediaNSns2.wikimedia.org. wikipediaNSns0.wikimedia.org. is the same like this: wikipediaNSns2.wikimedia.org. wikipediaNSns0.wikimedia.org. wikipediaNSns0.wikimedia.org. In this 2 case it will send 50% of traffic to ns2 and 50% to ns0; Is there anyway to enable priority on A or NS record? Thanks. For NS records, there is no way to do this in BIND, and it's completely unnecessary anyway, since every major DNS full-resolver implementation will keep track of how fast nameservers respond -- based on round-trip times, known as RTTs -- and prefer faster-responding nameservers over slower-responding ones. So the load spreads itself automatically, and failures -- which are assessed as really bad performance -- are routed around. For A/ records, there are mechanisms to control the order in which the records are presented. See sortlist and rrset-order (not sure that rrset-order even exists in later versions of BIND, since I've never used it in production). However, these are only practical on tightly-controlled intranets, where all of the BIND-instance configurations can be kept in sync with each other, otherwise one BIND instance may undo the careful address-record ordering that another performs. rrset-order and sortlist are pretty much useless for Internet names, since the vast majority Internet users get their DNS through intermediate resolvers, which will usually randomize or round-robin the responses whenever they are answering from their caches. As another poster pointed out, SRV records provide the capability for the domain owner to implement per-name failover and weighting of targets, in the DNS data itself. But, thusfar the DNS community hasn't had much success getting client-software developers (e.g. browser developers) to adopt SRV record support. Meanwhile, certain network-hardware companies (including among others a certain huge router vendor) rake in big money with their sledgehammer load-balancer device approach to the problem. There are software approaches to network load-balancing as well, but I have no direct experience with those. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.4.3-P2 doesn't delegate zone!
A. Stop using nslookup. It's a really horrible DNS troubleshooting tool. Learn to use dig. B. Do a zone transfer (via dig) of the united-networks.ru zone from the primary master, to verify that the correct delegation record, and associated glue, are contained within named's in-core database of the zone C. The domain.united-networks.ru A record (between the delegation NS record and the srvmain glue record) in the parent zone is completely useless, since it's not required glue and would be covered up by any A record -- or even the absence of an A record -- at the apex of the child zone. I would delete that A record from the parent zone -- its only function is to use up space and engender confusion. D. Your SOA query of the child zone from its master returned no NS records in the Authority Section, which is rather odd. How are the NS records configured in the child zone? Do they match the delegation record from the parent zone? - Kevin On 4/2/2011 1:05 PM, Яцко Эллад Геннадьевич wrote: Dear Phil! What did you mean saying: Are you sure you've reloaded the zone? Did you mean do I rndc reload united-networks.ru in internal - Yes! I don't remember, did I change serial every time I changed zone-file. But now I did all the things required. I changed serial, I reloaded zone, I even restarted named its own! :-) There is the following effect (from viewpoint of 172.16.77.11): C:\Program Files\Far2nslookup srvmain.domain.united-networks.ru. 172.16.77.1 ╤хЁтхЁ: srvgate-msk.runoguy.ru Address: 172.16.77.1 ╚ь : srvmain.domain.united-networks.ru Address: 172.16.77.2 C:\Program Files\Far2 NAMED knows its address itself: 19611.924018 172.16.77.11 - 172.16.77.1 DNS Standard query PTR 1.77.16.172.in-addr.arpa 19611.924375 172.16.77.1 - 172.16.77.11 DNS Standard query response PTR srvgate-msk.runoguy.ru 19611.926342 172.16.77.11 - 172.16.77.1 DNS Standard query A srvmain.domain.united-networks.ru 19611.926516 172.16.77.1 - 172.16.77.11 DNS Standard query response A 172.16.77.2 19611.927755 172.16.77.11 - 172.16.77.1 DNS Standard query srvmain.domain.united-networks.ru 19611.927895 172.16.77.1 - 172.16.77.11 DNS Standard query response But the next is courious: C:\Program Files\Far2nslookup domain.united-networks.ru. 172.16.77.1 ╤хЁтхЁ: srvgate-msk.runoguy.ru Address: 172.16.77.1 ╚ь : domain.united-networks.ru C:\Program Files\Far2 And: 19664.732793 172.16.77.11 - 172.16.77.1 DNS Standard query PTR 1.77.16.172.in-addr.arpa 19664.733079 172.16.77.1 - 172.16.77.11 DNS Standard query response PTR srvgate-msk.runoguy.ru 19664.739041 172.16.77.11 - 172.16.77.1 DNS Standard query A domain.united-networks.ru 19664.739441 172.16.77.1 - 172.16.77.11 DNS Standard query response 19664.741088 172.16.77.11 - 172.16.77.1 DNS Standard query domain.united-networks.ru 19664.741265 172.16.77.1 - 172.16.77.11 DNS Standard query response Andwhen I tried to look up existing hostname from domain.united-networks.ru: C:\Program Files\Far2nslookup main.domain.united-networks.ru. 172.16.77.1 ╤хЁтхЁ: srvgate-msk.runoguy.ru Address: 172.16.77.1 *** srvgate-msk.runoguy.ru cannot find main.domain.united-networks.ru.: Non-existent domain C:\Program Files\Far2 ↑ I see in thsark's output the following: 19167.908192 172.16.77.11 - 172.16.77.1 DNS Standard query PTR 1.77.16.172.in-addr.arpa 19167.908505 172.16.77.1 - 172.16.77.11 DNS Standard query response PTR srvgate-msk.runoguy.ru 19167.910291 172.16.77.11 - 172.16.77.1 DNS Standard query A main.domain.united-networks.ru 19167.910439 172.16.77.1 - 172.16.77.11 DNS Standard query response, No such name 19167.911593 172.16.77.11 - 172.16.77.1 DNS Standard query main.domain.united-networks.ru 19167.911837 172.16.77.1 - 172.16.77.11 DNS Standard query response, No such name I couldn't see that 172.16.77.1 (srvgate-msk) asks for main 172.16.77.2 (srvmain - recursion allowed) Here is output of command that you requested: /etc/namedb dig +norec @localhost domain.united-networks.ru. soa ; DiG 9.4.3-P2 +norec @localhost domain.united-networks.ru. soa ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 7449 ;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;domain.united-networks.ru. IN SOA ;; AUTHORITY SECTION: united-networks.ru. 3600IN SOAns1.united-networks.ru. root.united-networks.ru. 2011040213 900 600 86400 3600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Apr 2 20:32:49 2011 ;; MSG SIZE rcvd: 88 /etc/namedb At the same time: /etc/namedb dig +norec @172.16.77.2
Re: Zone File IP address/Hostname
Mistake #1: looking up something using a shortname. Apparently rac2.local is not in your stub resolver's local search list. Always use fully-qualified domain names (FQDNs) for client lookups, and educate your users to do so also. Using FQDNs is the most efficient, least ambiguous, and easiest-to-troubleshoot form of resource lookup from DNS. Mistake #2: trying to troubleshoot DNS using nslookup. With its default output format, nslookup is hiding all of its disgusting suffixing behavior from your eyes, thus leaving you in the dark as to what the problem is. Consider using a real DNS troubleshooting tool like dig, which doesn't do suffixing garbage (it looks up exactly what you ask it to look up, nothing more, nothing less), and with its default output format, shows you the full DNS response from the nameserver Mistake #3: the connection timed out error from nslookup implies that one of the names it tried to look up (either rac2-scan appended with some arbitrary suffix from your searchlist, or rac2-scan as a *root* name), ended up in a part of the namespace that your DNS infrastructure can't resolve at all. Most likely you have no direct connectivity to the Internet, yet you have neglected to set up your own internal root zone. So, your DNS infrastructure tries to go out and talk to the Internet root nameservers, and beats its head bloody on your firewalls and/or your routers and/or whatever, futilely trying to get response. Hence the timeout. I'm surprised your firewall guys haven't complained to you yet about all of the log noise you've been generating. Mistake #4: from the logs below, it appears that you have no A or records associated with the targets of certain NS records -- with a first label of apple -- in each of several zones. Either change the targets of those NS records to a fully-qualified name (instead of just apple), or supply the A/ records of apple.zone in each of those zone files so that they are internally complete. This appears to be another symptom of shortname-itis. Please learn the contexts in which shortnames work, and the contexts in which they do not, or where extra work is required to make them work. The safest thing is to always use FQDNs, as suggested above. - Kevin On 4/1/2011 9:09 AM, Tony MacDoodle wrote: I think it's something with one of the zone files, here is what I get nslookup rac-scan Server: xxx.xxx.xxx.xxx Address:xxx.xxx.xxx.xxx#53 Name: rac-scan.rac.local Address: xxx.xxx.xxx.xxx Name: rac-scan.rac.local Address: xxx.xxx.xxx.xxx Name: rac-scan.rac.local Address: xxx.xxx.xxx.xxx root:jabba:~# nslookup rac2-scan ;; connection timed out; no servers could be reached /var/adm/messages Apr 1 09:05:16 apple named[1695]: [ID 873579 daemon.info http://daemon.info] shutting down Apr 1 09:05:16 apple named[1695]: [ID 873579 daemon.notice] stopping command channel on 127.0.0.1#953 Apr 1 09:05:16 apple named[1695]: [ID 873579 daemon.info http://daemon.info] no longer listening on 127.0.0.1#53 Apr 1 09:05:16 apple named[1695]: [ID 873579 daemon.info http://daemon.info] no longer listening on xxx.xxx.xxx.24#53 Apr 1 09:05:16 apple named[1695]: [ID 873579 daemon.notice] exiting Apr 1 09:05:16 apple named[1715]: [ID 873579 daemon.notice] starting BIND 9.6.1-P3 -4 Apr 1 09:05:16 apple named[1715]: [ID 873579 daemon.notice] built with --prefix=/usr --with-libtool --bindir=/usr/sbin --sbindir=/usr/sbin --libdir=/usr/lib/dns --sysconfdir=/etc --localstatedir=/var --with-openssl=/usr/sfw --enable-threads=yes --enable-devpoll=yes --enable-fixed-rrset --disable-openssl-version-check -DNS_RUN_PID_DIR=0 Apr 1 09:05:16 apple named[1715]: [ID 873579 daemon.info http://daemon.info] found 8 CPUs, using 8 worker threads Apr 1 09:05:16 apple named[1715]: [ID 873579 daemon.info http://daemon.info] using up to 4096 sockets Apr 1 09:05:16 apple named[1715]: [ID 873579 daemon.info http://daemon.info] loading configuration from '/etc/named.conf' Apr 1 09:05:16 apple named[1715]: [ID 873579 daemon.info http://daemon.info] using default UDP/IPv4 port range: [1024, 65535] Apr 1 09:05:16 apple named[1715]: [ID 873579 daemon.info http://daemon.info] using default UDP/IPv6 port range: [1024, 65535] Apr 1 09:05:17 apple named[1715]: [ID 873579 daemon.info http://daemon.info] no IPv6 interfaces found Apr 1 09:05:17 apple named[1715]: [ID 873579 daemon.info http://daemon.info] listening on IPv4 interface lo0, 127.0.0.1#53 Apr 1 09:05:17 apple named[1715]: [ID 873579 daemon.info http://daemon.info] listening on IPv4 interface vnet0:1, xxx.xxx.xxx.24#53 Apr 1 09:05:17 apple named[1715]: [ID 873579 daemon.info http://daemon.info] automatic empty zone: 0.IN-ADDR.ARPA Apr 1 09:05:17 apple named[1715]: [ID 873579 daemon.info
Re: Root Hints Data File for a .local Domain
On 3/9/2011 8:32 AM, Tony MacDoodle wrote: Hello, I am currently running BIND 9.6.1-P3 and it works fine. My question is regarding the db.cache file. I am only running a local domain (apps.local) that does not access the internet for resolution. My current root hints file is from Internic. 1) Can I use a stripped version of the named.root file 2) Do I need it at all for a local domain If you're on a completely isolated network, with a DNS-consumer population of any significant size, you should set up your own root zone, along with defining slaves, setting up master/slave replication, and publishing all available nameservers in the NS records of the root zone. If, after you've built up that core authoritative infrastructure, you want any of your edge resolvers to be caching-only, i.e. with a minimal config, then you'd configure them with a root hints file, but it wouldn't contain the same contents as the one from Internic -- it would contain references to your own internal root nameservers, along with their internal addresses. Someone suggested that .local might be problematic, but we've been using various .local domains in our internal DNS for years -- not my choice, this is from the Active Directory team of one of our business partners -- and not run into any problems so far. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
On 3/9/2011 1:09 PM, Matt Rae wrote: Hi, I'm working on setting up a slave dns server. Dots have historically been used in the hostnames here. What does the term hostname mean to you? If hostname is defined as the contents of the first label of a dot-delimited DNS name, then dot in hostname does not and cannot exist. Or, perhaps you have a different definition? The dots cause the resulting zone file from a zone transfer to have $ORIGIN automatically set assuming the dots are indicating a subdomain. Here's an example of what's happening: master zone file: $ORIGIN example.com. host1.set1Ax.x.x.x host2.set1Ax.x.x.x host3.set1Ax.x.x.x slave's zone file after axfr: $ORIGIN set1.example.com. host1 Ax.x.x.x host2 Ax.x.x.x host3 Ax.x.x.x Is there a way to have it not change the ORIGIN and assume the dots are a subdomain? Well, technically, that is not just an assumption. set1.example.com is, in reality, a subdomain of example.com. $ORIGIN statements are just a convenience for named's zone-parsing routine. If you intend to parse zone contents yourself, you should look at the actual data rather than literally the zone file, which is only one way among many to express that data. Dealing with the actual data can be accomplished either through the DNS protocol itself (e.g. zone transfer), or via a script that parses the $ORIGIN statements, etc. and renders the data into a more digestible form. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: different behavior: A Records in DNS answer, when query of type any (existing CNAME)
On 3/7/2011 6:36 AM, Diezig Adrian wrote: Hi, I have a question concerning answers from DNS servers, when I query a name with type any and the name is a CNAME. I have the following example (works also in Internet) with an ISC BIND server (BIND 9.7.0-P1): ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 @newton.genesiscom.ch dns.ipam.ch ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25078 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dns.ipam.ch. IN A ;; ANSWER SECTION: dns.ipam.ch.600 IN CNAME www.ipam.ch. www.ipam.ch.600 IN A 81.18.25.238 ;; Query time: 1 msec ;; SERVER: 10.10.3.13#53(10.10.3.13) ;; WHEN: Mon Mar 7 11:52:38 2011 ;; MSG SIZE rcvd: 63 As you can see, we have a CNAME dns.ipam.ch that points to www.ipam.ch. www.ipam.ch is an A-Record to 81.18.25.238. When I do the following query (type=any to dns.ipam.ch), only the CNAME itself will be in the answer section (the A-Record not): ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 @newton.genesiscom.ch dns.ipam.ch any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46532 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dns.ipam.ch. IN ANY ;; ANSWER SECTION: dns.ipam.ch.600 IN CNAME www.ipam.ch. ;; Query time: 1 msec ;; SERVER: 10.10.3.13#53(10.10.3.13) ;; WHEN: Mon Mar 7 11:53:21 2011 ;; MSG SIZE rcvd: 47 That's valid response, albeit a little stingy. You asked about all records matching the name dns.ipam.ch, and it gave you all records. Note that RFC 1034's nameserver algorithm (section 4.3.2) specifies that a query should be restarted if QNAME owns a CNAME RR and QTYPE doesn't match CNAME. In a normal case, e.g. QTYPE=A, this means that the CNAME gets added to the Answer Section and then the query is restarted, as if the target of the alias were QNAME. It either produces A records or it doesn't. But in this *special* case, QTYPE=* does in fact match the CNAME record found by the nameserver, therefore the query is not restarted. The nameserver just returns what is has -- i.e. the CNAME record -- and its job is done. It jumps to Step 6 of the algorithm: return the records along with any Additional Records that it deems helpful, and exit. When I do a comparable query (also with type=any) to another DNS Server (eg. google.com) ; DiG 9.3.2 @ns1.google.com. www.google.com. any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1636 ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com.IN ANY ;; ANSWER SECTION: www.google.com. 604800 IN CNAME www.l.google.com. www.l.google.com. 300 IN A 74.125.232.114 www.l.google.com. 300 IN A 74.125.232.115 www.l.google.com. 300 IN A 74.125.232.116 www.l.google.com. 300 IN A 74.125.232.113 www.l.google.com. 300 IN A 74.125.232.112 ;; Query time: 46 msec ;; SERVER: 216.239.32.10#53(216.239.32.10) ;; WHEN: Mon Mar 07 09:44:32 2011 ;; MSG SIZE rcvd: 132 ... I will get also the associated A Records. Well, ns1.google.com coincidentally *happens* to also be authoritative for l.google.com, so it was able to provide the A records. It's arguable, however, whether it should have restarted the query or not (in the sense described above). Does anybody have an idea, why the behavior is different? Can I configure this on my DNS Server (ISC BIND)? FYI: dig @ns1.hp.com. www.hp.com. any and dig @ns1.yahoo.com. www.yahoo.com any Understand that ns1.hp.com is *not* authoritative for any A records owned by www.hp.com (the name is an alias to www.hpgtm.nsatc.net so the authoritative A records would be given from something hosting some descendant of nsatc.net), and ns1.yahoo.com is *not* authoritative for any A records owned by www.yahoo.com (which is an alias to fp.wg1.b.yahoo.com, at least when I query it; the exact target of the alias might depend on who is querying it). will also answer without any A-Records (like me). I have the following questions: -which one is correct (RFC)? An ANY query should return A records if the nameserver being queried is actually authoritative for the name being queried and the name owns A records. But if -- as in your examples above -- the nameserver only holds an alias, it is under no obligation to go and fetch those A records on your behalf. -is it configurable in ISC BIND? Nope. -does the behavior depends on different BIND version? Nope. As far as I know, BIND has always been this way. I know that
Re: Help with unresolvable domain (subdomain, actually)
On 3/2/2011 10:34 AM, David Sparro wrote: On 3/1/2011 5:27 PM, Kevin Darcy wrote: See my other post. This is designed-in behavior for Cisco GSSes, since there is no service unavailable, try again later RCODE. When the question is what is the ip address of 'foo' an answer of the web server is down in nonsensical. Hmmm... matter of perspective I suppose. Load-balancer architecture sees DNS as just the externally-visible portion of a whole subsystem. The SERVFAIL, in their view, does not communicate a DNS problem _per_se_, but a problem with the whole subsystem. It's more of a what you're trying to get to is unavailable right now message, communicated, in their view, _through_ DNS (as a sort of conduit), not necessarily _about_ DNS. They don't see it as specifically meaning I've got a DNS problem. I'm not saying I agree with this perspective, only that I've dealt with load-balancer vendors enough (Cisco in particular) to understand that this is where they're coming from. Besides, what alternative is there? If the load-balancer returns an address that it knows to not be working, then it's purposely causing the client to go into a relatively-slow connection-timeout failure mode. Is that responsible behavior? If it gives a normal response that is lacking answer information (NODATA, NXDOMAIN), then this response gets negatively cached, and the negative cache entry may delay clients from re-trying the resource even after it recovers. So, what's left? NOTIMP? FORMERR? REFUSED? NOTAUTH? Those aren't any better than SERVFAIL from a strictly functional perspective, and are even more misleading and confusing with respect to the real source of the problem. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On 3/1/2011 6:30 PM, Mark Andrews wrote: In message4d6d7268.1080...@chrysler.com, Kevin Darcy writes: I got a trouble ticket on this too. From the looks of things, Cisco is using GSSes to load-balance this site. GSSes return SERVFAIL if all of the resources behind the load-balancer are down (which it determines via a heartbeat mechanism). So I think this is a simple case of a website (or cluster) going down. It was down earlier today, then up again, as of this writing, it is down again. DNS doesn't really have a response code of requested resource not available, so SERVFAIL is Cisco's closest approximation. It has the drawback, however, of often making other sorts of problems appear to be DNS problems. That's just a cross that we DNS admins have to bear... - Kevin Then the load balancer should return default records or 0.0.0.0/:: to indicate the name is good but doesn't currently have a address. I like that solution, actually. Even if the client doesn't recognize it as a special address, hopefully if it tries to connect to it, the packet won't make it past the first router or switch hop... Has anyone proposed this to the load-balancer vendors? - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
I got a trouble ticket on this too. From the looks of things, Cisco is using GSSes to load-balance this site. GSSes return SERVFAIL if all of the resources behind the load-balancer are down (which it determines via a heartbeat mechanism). So I think this is a simple case of a website (or cluster) going down. It was down earlier today, then up again, as of this writing, it is down again. DNS doesn't really have a response code of requested resource not available, so SERVFAIL is Cisco's closest approximation. It has the drawback, however, of often making other sorts of problems appear to be DNS problems. That's just a cross that we DNS admins have to bear... - Kevin On 3/1/2011 4:08 PM, Mike Bernhardt wrote: I should add that tools.cisco.com was resolvable at one time, so either Cisco's behavior has changed, or our firewall's behavior has changed. We obviously haven't upgraded our BIND version in a while (9.4.3P3), so I don't think the problem is BIND. -Original Message- From: Mike Bernhardt [mailto:bernha...@bart.gov] Sent: Tuesday, March 01, 2011 12:40 PM To: bind-users@lists.isc.org Subject: Help with unresolvable domain (subdomain, actually) For some reason, we can no longer resolve tools.cisco.com. there are several clues to the problem but I can't put them together. Here is some dig output. I know that the time stamps don't all match up below, but the results are typical: [root@ns1 ~]# dig +trace -b 148.165.3.10 tools.cisco.com ; DiG 9.4.3-P3 +trace -b 148.165.3.10 tools.cisco.com ;; global options: printcmd . 90550 IN NS i.root-servers.net. . 90550 IN NS h.root-servers.net. . 90550 IN NS e.root-servers.net. . 90550 IN NS d.root-servers.net. . 90550 IN NS j.root-servers.net. . 90550 IN NS k.root-servers.net. . 90550 IN NS l.root-servers.net. . 90550 IN NS g.root-servers.net. . 90550 IN NS f.root-servers.net. . 90550 IN NS a.root-servers.net. . 90550 IN NS m.root-servers.net. . 90550 IN NS c.root-servers.net. . 90550 IN NS b.root-servers.net. ;; Received 512 bytes from 148.165.3.10#53(148.165.3.10) in 0 ms com.172800 IN NS l.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. ;; Received 505 bytes from 198.41.0.4#53(a.root-servers.net) in 13 ms cisco.com. 172800 IN NS ns1.cisco.com. cisco.com. 172800 IN NS ns2.cisco.com. ;; Received 101 bytes from 192.54.112.30#53(h.gtld-servers.net) in 154 ms tools.cisco.com.86400 IN NS rcdn9-14p-dcz05n-gss1.cisco.com. tools.cisco.com.86400 IN NS rtp5-dmz-gss1.cisco.com. tools.cisco.com.86400 IN NS sjck-dmz-gss1.cisco.com. tools.cisco.com.86400 IN NS cax01-bb14-dcz01n-gss1.cisco.com. ;; Received 226 bytes from 64.102.255.44#53(ns2.cisco.com) in 75 ms ;; Received 33 bytes from 72.163.4.28#53(rcdn9-14p-dcz05n-gss1.cisco.com) in 47 ms Now, focusing in on rtp5-dmz-gss1.cisco.com for further analysis (just picked it out of the group): [root@ns1 ~]# dig -b 148.165.3.10 @rtp5-dmz-gss1.cisco.com tools.cisco.com ; DiG 9.4.3-P3 -b 148.165.3.10 @rtp5-dmz-gss1.cisco.com tools.cisco.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 5165 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 75 msec ;; SERVER: 64.102.246.5#53(64.102.246.5) ;; WHEN: Tue Mar 1 12:22:57 2011 ;; MSG SIZE rcvd: 33 Here is
Re: Help with unresolvable domain (subdomain, actually)
See my other post. This is designed-in behavior for Cisco GSSes, since there is no service unavailable, try again later RCODE. - Kevin On 3/1/2011 4:25 PM, Mark Andrews wrote: Ring Cisco and complain that their nameservers are broken for the zone. ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 13389 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 204 msec ;; SERVER: 72.163.4.28#53(rcdn9-14p-dcz05n-gss1.cisco.com) ;; WHEN: Wed Mar 2 08:23:59 2011 ;; MSG SIZE rcvd: 33 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
On 2/23/2011 4:08 AM, babu dheen wrote: Hi, Our setup is; We have internal DNS server wherein BIND is configured in RHEL 5 and many internal zones are configured. if Internet connection is down, our Internal DNS severs are not able to get the DNS query from ISP DNS server. Because of this, all users are not able to access many critical application hosted in internet. Now we would like to add those critical applicaton DNS entries in our internal DNS server HOST file. So that if internet link is down, users will be able to get the IP address of the URL through host file. If the names of these critical applications reside in zones that you own, you should probably set yourself up as a stealth slave for those zones. If they're in someone else's zones, and being a stealth slave is impractical, then you could play a dangerous game by maintaining a fake version of the zone yourself (defined as master). Dangerous because the IPs could change without any notice and then your data is instantly invalid. But, I suppose that isn't any worse than hosts-file entries, right? is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? Nope, BIND doesn't control whether a process looks in the hosts file or not. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
On 2/23/2011 4:57 AM, Eivind Olsen wrote: is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? No. BIND doesn't read/use the hosts file. What you _can_ do is configure BIND to believe it's authoritative for those zones, but I'd not recommend doing this unless you have a very good reason. And if your Internet connection goes down, does it really matter whether you can do lookups, if you can't make the connections anyway? I hear that reasoning a lot, but it's actually a fallacy. Some applications/subsystems differentiate between host not found errors (considered permanent) and cannot connect errors (considered temporary and retryable). In fact, those might be very different code paths, and the app/subsystem behavior might differ wildly. Unless one intimately knows the failure behavior of *every*single*app*and*subsystem* in one's environment (which in a large/complex environment is a constantly moving target, since new apps and subsystems are being implemented all the time), one should err on the side of safety and ensure that DNS resolution still works even if the resources that the address (A/) records point to is unavailable. One should also bear in mind that DNS isn't only used for obtaining address records for purposes of immediate client/server connection. Data mining, resource location, and general information retrieval functions are often implemented in DNS, and the availability of these functions shouldn't necessarily be made dependent on the up/down status of some arbitrary network link. It's also possible that an app could make a lookup, and as long as the TTL on the records hasn't expired, legitimately attempt a connection at some _later_ time. Not everything is on-demand. To answer the original poster's question: BIND doesn't control whether a process uses the hosts file for its lookup or not, that's usually an OS-configuration thing (see, e.g. http://en.wikipedia.org/wiki/Name_Service_Switch, http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/netsvc.conf.htm, etc.) - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help on recursive set up
There are multiple ways to interpret that question. Normally, a resolver either uses recursion (with a preconfigured set of forwarders) at a given point in resolving a particular name, or it follows the NS records in a delegation chain, non-recursively, in order to find the answer. It wouldn't do *both*. A given query can't be recursive and non-recursive at the same time. Possibly you are asking if it's possible for a nameserver which is delegated for a particular zone, to forward all queries for names in that zone to some other (private/internal) nameserver for resolution. The answer to that is no, since the queries being received by that visible nameserver are expected to be *non-recursive*, and non-recursive queries are never supposed to be forwarded anywhere. You might, however, look into some sort of DNS proxy solution, if this is what you're trying to accomplish. - Kevin On 2/23/2011 7:29 AM, rams wrote: Hi, Could you please tell me how to set up for recursive server for NS delegation records. It would be great if you give named.conf Thanks Regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the file command
On 2/8/2011 9:15 AM, Terry. wrote:
2011/2/8 Matus UHLAR - fantomasuh...@fantomas.sk:
On 08.02.11 17:40, Terry. wrote:
Can BIND's file command referer to more than one zone file?
For example,
zone test.nsbeta.info {
type master;
file a.db;
file b.db;
};
When a record doesn't exist in a.db, BIND will continue to look for it in
b.db.
Afaik, no. Why would you want that?
For views catchall.
for example, named.conf has three views enabled by default, some users
have three veiws setup, but some have only two views setup, so I want
the catchall solution for the the lack of a view.
There is no default named.conf. Are you referring to some named.conf
that was provided in an OS distribution? As part of a third-party DNS
management tool? Perhaps you need to provide some specifics about your
particular environment.
The general approach used with views is to include the entries that
*every* view should see, into each version of the zone(s) in their
respective views. Yes, this duplicates data and occupies more memory
than is strictly necessary. If capacity is a problem, you always have
the option of running separate nameserver instances on separate hardware
or virtualized OS instances. Views are only a convenience for those who
have the capacity and the desire to run multiple logical nameserver
instances inside of a single process running in a single OS image.
This cross-view record-level or RRset-level inclusion can be done either
through $INCLUDE-file chicanery, or by designing/modifying/configuring
your DNS maintenance system to make and maintain the relevant entries in
parallel.
As for selection of views, these are matched in order, so if your last
view has match-clients { any; }; (or, if you prefer,
match-destinations { any; };, this gives you the not otherwise
matched behavior you seem to be seeking.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dotted hostname is bad IMO
So, let me see if I have this correctly: you think that DNS architects and/or planners should constrain their choices with respect to namespace layout and/or delegation hierarchy, because of some minor performance considerations, based on your _speculations_ (without any hard evidence) about how certain cache-fetching algorithms are coded? - Kevin On 1/31/2011 10:11 PM, p...@mail.nsbeta.info wrote: given the domain name of 126.com, and given an A RR in its zone is: s1.s2.s3 IN A 11.22.33.44 OK when a dns cache query for s1.s2.s3.126.com the first time, it will follow the logic: #1, s1.s2.s3.126.com has NS RR in cache? (no) #2, s2.s3.126.com has NS RR in cache? (no) #3, s3.126.com has NS RR in cache? (no) #4, 126.com has NS RR in cache? (yes most time, since 126.com is a famous domain). #5, Goto 126.com's NS fetch the result. The process is complicated. But if the hostname is s1-s2-s3.126.com, what will the dns cache do by the first query? it will just do: #1, 126.com has NS RR in cache? (yes) #2, go there fetching the reqult. It's much simple and fast. So I dont think dotted hostname is good pratical. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive DNS problem
On 1/28/2011 5:11 AM, Torinthiel wrote: Dnia 2011-01-28 10:52 bangla desh napisał(a): I believed so that com.bd is broken. It only has 1 ns server and hsbc.com.bd, whois.com.bd and even google.com.bd they are all delegate directly from bd and not from com.bd. I am wondering, is there a dns rule/standard (or RFC) that explains about delegation? For the fact that com.bd is broken - that's just how DNS works. Zone cuts are there for purpose. Most of this can be read from RFC 1034 and 1035, which form the grounds for DNS standards. Also RFC 2181 clarifies: quote A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone. /quote And a mere presence of NS records indicates a zone cut (again, RFC 2181): quote The existence of a zone cut is indicated in the parent zone by the existence of NS records specifying the origin of the child zone. /quote As for number of authorative servers per domain, I don't remember where, but at leas one RFC stated that there should be at least two, and preferably 3-7 nameservers per domain. It's quite possible that one of those I've already pointed to contains this information, but also that a different one states this information. But it was RFC for certain. RFC 1034, Section 4.1: A given zone will be available from several name servers to insure its availability in spite of host or communication link failure. By administrative fiat, we require every zone to be available on at least two servers, and many zones have more redundancy than that. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: what's a valid domain name?
Vyto, Dotted hostnames is a term coined by certain limited DNS-management tools that strive to split up fully-qualified DNS names into a hostname part and a zone (sometimes referred to as domain) part. If one chooses to extend a given name for 2 or more labels below the closest-enclosing zone cut, then in the standard representation used by those tools, the hostname portion of the name will have a dot in it, hence dotted hostnames, which are treated by such limited tools as somehow weird and special. At least one tool I'm familiar with, requires a special non-default option setting to even allow dotted hostnames to exist at all in its database. DNS itself has never had a problem with multiple labels beneath a zone cut. Better tools recognize the inherent flexibility of DNS naming and don't try to deprecate or otherwise discourage so-called dotted hostnames. - Kevin On 1/31/2011 10:50 AM, Vyto Grigaliunas wrote: Although we're moving away from it, we found it useful for naming router interfaces, i.e. te1-2.routername.company.com, without having to create a separate sub-domain for each router. I thought at some point periods were allowed in hostnames, and they do work without escaping them. Thanks... Vyto -Original Message- From: bind-users-bounces+vyto=fnal@lists.isc.org [mailto:bind- users-bounces+vyto=fnal@lists.isc.org] On Behalf Of Barry Margolin Sent: Sunday, January 30, 2011 4:14 PM To: comp-protocols-dns-b...@isc.org Subject: Re: what's a valid domain name? In articlemailman.1586.1296424051.555.bind-us...@lists.isc.org, Vytautas Grigaliunasv...@fnal.gov wrote: What is the status of dotted hostnames - i.e. a period in the hostname portion of a domain name ? At one point they were allowed, I believe ? What is the latest official RFC ? I don't think they've every been allowed. Why would you need to do this, instead of just using another level of subdomain? To get a literal period into a label, you need to escape it, e.g. foo\.bar.company.com instead of foo.bar.company.com. The latter is allowed, always has been, and is quite common. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NS Cache
On 1/25/2011 9:40 PM, p...@mail.nsbeta.info wrote: I'm reading the document Secure DNS Deployment Guide got from the URL a poster gave in the list. The document said: When a user types the URL www.example.com into a Web browser, the browser program contacts a type of resolver called a stub resolver that then contacts a local name server (called a recursive name server or resolving name server). The resolving name server will check its cache to determine whether it has valid information (the information is determined to be valid on the basis of criteria described later in this document) to provide IP address for the accessed Internet resource (i.e.,www.marketing.example.com). If not, the resolving name server checks the cache to determine whether it has the information regarding the name server for the zone marketing.example.com (since this is the zone that is expected to contain the resource www.marketing.example.com). If the name server!ˉs IP address is in the cache, the resolver!ˉs ne query will be directed against that name server. If the IP address of the name server of marketing.example.com is not available in the cache, the resolver determines whether it has the name server information for a zone that is one level higher than marketing.example.com (i.e., example.com). If the name server information for example.com is not available, the next search will be for the name server of the .com zone in the cache. I think the statement below is wrong? If not, the resolving name server checks the cache to determine whether it has the information regarding the name server for the zone marketing.example.com (since this is the zone that is expected to contain the resource www.marketing.example.com). How does the resolver know www.marketing.example.com is a domain name or a zone? www.marketing.example.com can also be a zone which has valid NS records. So I was thinking the resolver shall check the cache firstly to see whether it has the NS records for the zone www.marketing.example.com, if not, then to check the NS for marketing.example.com. Am I right? Yeah, it's wrong. A resolver that followed the algorithm described in that paper might operate slightly less efficiently than one which follows the standard resolver algorithm. But, hey, it's close enough for government work... - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dns best practices
The document is a little sloppy. In addition to the mis-description of the DNS resolver algorithm, already noted in a previous post, the part in Section 8.1.2 about restricting zone transfers -- These restrictions address [...] potential exploits from unrestricted dissemination of information about internal resources -- makes up a dissemination threat out of thin air, which was not mentioned in the previous, supposedly-exhaustive enumeration of zone-transfer-related threats in Section 6.2 -- a) denial-of-service, and b) message tampering. - Kevin On 1/25/2011 12:22 PM, Casey Deccio wrote: On Sun, Jan 23, 2011 at 10:30 PM,p...@mail.nsbeta.info wrote: Is there a document for dns bind best practices? I googled but found nothing valueable. NIST SP 800-81 Rev. 1: http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: only the response has aa flag can be cached?
The answers will be cached regardless of the setting of the AA flag. I would suspect that most -- or at least a large percentage -- of DNS queries made by endpoint clients are to upstream resolvers which don't happen to be authoritative for the zone(s) in question, so AA=0 is very common in practice and lookup caching wouldn't work very well if it were limited to only AA=1 responses. Note that if a full resolver gets better data in a DNS response than what it has already cached, it may overwrite the existing cache data with the new data. The determination of what is better is spelled out in the data ranking rules in RFC 2181 and isn't directly related to the setting of the AA flag. Among other things, this means that when following a delegation chain, the NS records directly from the authoritative nameservers for a zone, if available, will overwrite the delegating NS records encountered earlier in the resolution process. - Kevin P.S. You did notice that you're performing recursive queries against nameservers which don't offer recursion, right? That might be a possible source of confusion. On 1/4/2011 10:28 PM, p...@mail.nsbeta.info wrote: Hello, I'm not sure about, is it true that only the response which has included the aa in flags can be cached by client DNS Cache? For example, for my domain, there are two queries below, the result for the first query won't be cached, but the second will be cached, am I right? $ dig mail.nsbeta.info ns @ns34.domaincontrol.com ; DiG 9.4.2-P2 mail.nsbeta.info ns @ns34.domaincontrol.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 12892 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mail.nsbeta.info. IN NS ;; ANSWER SECTION: mail.nsbeta.info. 1800IN NS dwdns2.nsbeta.info. mail.nsbeta.info. 1800IN NS dwdns1.nsbeta.info. ;; ADDITIONAL SECTION: dwdns2.nsbeta.info. 3600IN A 219.129.239.5 dwdns1.nsbeta.info. 3600IN A 120.132.133.48 -- $ dig mail.nsbeta.info ns @dwdns2.nsbeta.info ; DiG 9.4.2-P2 mail.nsbeta.info ns @dwdns2.nsbeta.info ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28561 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mail.nsbeta.info. IN NS ;; ANSWER SECTION: mail.nsbeta.info. 3600IN NS dwdns1.nsbeta.info. mail.nsbeta.info. 3600IN NS dwdns2.nsbeta.info. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best practize to store the ZONE files
It's really more of an OS tuning question, isn't it? The usage pattern of a BIND instance is: a) not much writing of master zone files or journal files unless Dynamic Update is enabled and the frequency of updates is relatively high, b) not much writing of slave/stub zone files or journal files, unless the zones have aggressive REFRESH settings and frequent updates c) not much reading of zone files except at startup or restart/reload, or possibly whenever writes occur, to read the zone data back into memory Now, given the usage pattern(s), how best to tune performance, based on the capabilities/limitations of the underlying OS and hardware? Same partition and/or filesystem versus separate partitions and/or filesystems? A different type of filesystem? Is the disk storage RAIDed? Striped? Mirrored? Is a journaling filesystem in use? Older filesystems used to run into performance problems when directories got really large, so some folks used to split up their zones by the initial letter of the zone name, e.g. zonefiles/a/aardvark.com, zonefiles/b/beetlebomb.com. I don't know if that's still an issue with modern filesystems though. We've never had more than a few thousand zones, with relatively rare restarts/reloads, and most of the zones not changing very frequently, so we haven't noticed any problems, and haven't resorted to any special setup for storing zone files. It occurs to me that the journal zone-level option in modern versions of BIND could theoretically be used to group all of the journal files into a separate filesystem/slice/partition, which might be better tuned for frequent updates, than the zone files themselves, which would change relatively infrequently. I haven't tested this theory though... - Kevin On 12/31/2010 12:24 AM, Michelle Konzack wrote: Hello *, I am hosting on my 6 NameServers 200.000 Domains and now in the meantime it becomes complicate because they are arround 230.000 files now including sub domains. There are currrently 18 TLs. My Question is: How do you handel such amount of files and where is the best place to store them on a Debian System (Lenny/Squeeze). Do you recommend to store it on a seperated partition, even if they have currently only arround 87 MByte? Thanks, Greetings and nice Day/Evening Michelle Konzack ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Silently drop queries for AAAA records
On 12/7/2010 5:31 PM, David A. Evans wrote: I'm in the mood to prove a point. I have a very poorly written application that is generating a few hundred queries per second of completely bogus records before attempting a lookup of the correct A records. This is because the application was compiled with a IPv6 interface enabled on the severs so it assumes that v6 is available. It is not. The application owner does not see an issue as they get the handful NXDOMAIN responses back in ~2 ms for each valid response and don't see any performance hit. I would like to silently drop the record lookups instead of responding back with NXDOMAIN. NXDOMAIN? Is the application looking up a different *name* for its queries than for its A queries? If a single name owned A records but no records then the correct response from an -capable resolver to an query of the name, would be the so-called NODATA response (NOERROR with 0 answers and an SOA RR in Authority Section for negative caching purposes, see RFC 2308 for details). NXDOMAIN, as another poster pointed out, could inhibit even A-record queries of the name, and would be the wrong response in that situation. Thusly generating a performance hit as the application waits 2 seconds for the reply. I have found the filter--on-v4 but it doesn't quiet do what I want. From the description and my testing it appears to still reply with NXDOMAIN to these queries, it simply filters out the 'valid' records from IPV4 based replies. (which is a really cool solution to other issues, but not what I need.) How nasty do you want to be? You could always add an record for that name. Point it anywhere you want evil laugh If you point it to something simply non-existent, this solution seems to me only slightly ruder than silently dropping the queries. Besides spinning up a bind 4.x box which google tells me did this by default, is there any way of doing this? I think it would be a really *bad* idea to spin up a BIND 4.x instance. Do you really want a big ugly security hole on your network? What about the person that inherits this setup from you? Would they be conversant in BIND 4.x setup and maintenance? I wouldn't wish BIND 4.x on anyone... If you really want to go in the direction of dropping packets, I'd look at some sort of software-firewall intervention (iptables or whatever) to do the packet-dropping. On the other hand, if the app really is looking up a different name for than for A (see above), that opens up all sorts of options for you. You could set up that name as a zone by itself and simply return REFUSED for all of those queries (the response packet count, and potentially the application delay, would be the same, but the response packets would be smaller and your intent crystal clear). Or set up a forwarder and play some games that way. - Kevin *David A. Evans* *Enterprise IP/DNS Management* *Network Infrastructure Tools and Services* *_evans_davi...@cat.com_* mailto:evans_davi...@cat.com ** /Eschew Obfuscation/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamic DNS with secondary nameserver?
You should have been able to use nsupdate or some other DDNS client tool
to add that NS record less disruptively than you did.
Understand that rndc freeze doesn't cause updates received in the
interim to be queued in some private area and applied later -- it causes
them to be *refused* and thus, for most DDNS clients, dropped. So it's
not something you want to do unless either a) you're sure there is no
Dynamic Update activity, b) you don't care about the updates being
dropped, c) you're sure your DDNS clients will recognize the REFUSED
condition and retry later, and/or d) it's an absolute emergency situation.
- Kevin
On 12/1/2010 3:42 PM, Sean Thomas Caron wrote:
Hi Sten,
Thanks for the response; you made me re-think the issue in such a way
that I ended up solving the problem (I think).
I was going to copy and paste the NS definitions in the main zone file
to show how I had defined the two nameservers for the subdomain and
found that I had missed a period in there.
ddns.sph.umich.edu.INNSns2.sph.umich.edu.
^ forgot this!
I also had to rndc freeze the dynamic subdomain, go back into the zone
file for the subdomain, and add the slave nameserver in there as well:
ddns.sph.umich.eduIN SOAdns.sph.umich.edu.
hostmaster.sph.umich.edu. (
2007024415 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 minutes)
2419200; expire (4 weeks)
86400 ; minimum (1 day)
)
NSdns.sph.umich.edu.
NSns2.sph.umich.edu.
^ added this line.
I was a little confused because the dynamic subdomain has been split
off into a different file from the main zone file and I erroneously
assumed that the DDNS subdomain would inherit the NS records defined
for the parent zone. Limited experience with DDNS so I wasn't sure how
much of that ddns.sph.umich.edu.hosts file was actually being used and
how much of the magic was in the journal file.
So I will continue to monitor this but I think I am all set now; sorry
to trouble everyone with this query. Indeed it works with slaves, as
one would expect, as long as you watch the typos and keep your files
straight!
Best,
-Sean
Quoting Sten Carlsen st...@s-carlsen.dk:
How did you tell the primary server who to notify?
It should be listed in a NS RR. You can also look at the also-notify
option.
Is the slave allowed to transfer the zone, if not even a notify will not
work.
On 01/12/10 21:09, Sean Thomas Caron wrote:
Hi folks,
We have an ISC DHCP server here feeding dynamic DNS updates to a BIND
9 machine and it has generally been working fine.
Now I am trying to add a slave nameserver to the zone and it works
fine for the static hosts but none of the dynamic DNS updates seem to
propagate to the slave.
On the master, I have the dynamic sub-domain configured as follows:
zone ddns.sph.umich.edu in {
type master;
file /etc/bind/ddns.sph.umich.edu.hosts;
notify yes;
allow-update { key dhcpupdate; };
};
This works great; the DHCP server feeds updates to the primary DNS
server, no problem.
On the slave, I set it up as so:
zone ddns.sph.umich.edu in {
type slave;
masters { 141.211.51.166; };
notify no;
file /etc/bind/ddns.sph.umich.edu.hosts;
};
When a host comes up on DHCP, the primary server picks it up fine:
server 141.211.51.166
Default server: 141.211.51.166
Address: 141.211.51.166#53
sph-2006-0090-test.ddns.sph.umich.edu
Server:141.211.51.166
Address:141.211.51.166#53
Name:sph-2006-0090-test.ddns.sph.umich.edu
Address: 141.211.11.190
sph-2006-0090-test.ddns.sph.umich.edutext =
31ce446f626045a4f8fe4933f448b613c6
But it never seems to propagate over to the slave:
server 141.211.51.66
Default server: 141.211.51.66
Address: 141.211.51.66#53
sph-2006-0090-test.ddns.sph.umich.edu
Server:141.211.51.66
Address:141.211.51.66#53
** server can't find
sph-2006-0090-test.ddns.sph.umich.edu.sph.umich.edu: SERVFAIL
I used 'rndc freeze' on the DDNS sub-domain then edited the zone file
to have a really short refresh interval:
ddns.sph.umich.eduIN SOAdns.sph.umich.edu.
hostmaster.sph.umich.edu. (
2007024409 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 minutes)
2419200; expire (4 weeks)
86400 ; minimum (1 day)
)
Then re-enabled it with 'rndc unfreeze' but it still doesn't seem to
have made a difference. Even after waiting an hour, the additions to
the dynamic DNS zone never propagate to the slave. I'm not even sure
if those values are honored
Re: catchall, if domain doesn't exist?
On 11/21/2010 3:57 PM, Tomasz Chmielewski wrote: I was wondering if it's possible to return a catchall A record for domains which bind can't resolve? I'm able to configure a catchall bind configuration where bind would return the same A record for all queries; but I'd rather it returns it for domains it can't resolve. It's evil, don't do it: http://www.google.com/search?q=nxdomain+redirection - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best Practices Query Logging, On or Off ?
On 11/18/2010 4:10 PM, Russell Jackson wrote:
On 11/18/2010 12:19 PM, Kevin Darcy wrote:
On 11/18/2010 1:36 PM, CT wrote:
I am looking for a best practices for dns query logging
Versions in use on Linux...
- BIND 9.7.1-P2
- BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2
The minimum logging statement in my test named.conf (bind 9.7.1-P2)
logging
{
category lame-servers { null; };
category resolver { null; };
};
which I have tested still allows the dns (default)
to log to /var/log/messages
--
default The default category defines the logging options for
those categories where no specific configuration has
been defined.
--
I have also been made aware that query logging can give a machine up
to a 30% performance hit but also with today's machines it is mostly
negligible..
My question is :
Do folks normally use query logging as a forensic tool or are most
Bind installations done without logging any queries ?
The powers that be seem to think the performance hit outweighs any
forensic benefit...
That's pretty short-sighted, IMO. Query logging allows one to find
misbehaving or misconfigured apps/servers/clients, active worms, etc. By
identifying those bad actors and correcting them, you reduce your query
volumes, usually much more than 30%. So, at the end of the day, what
benefit is there, really, in flying blind about one's query traffic?
Needless to say, we log all queries here. We even have a subsystem that
collects summaries of those query statistics from all of our remote
nameserver into a central repository for further mining/analysis.
Query logging also undermines the privacy of your users. There may
even be applicable state and federal laws regulating the storage of
information that can link users to site's they've visited.
There is no such linkage, when all users are forced to go through a web
proxy to access Internet sites, so that it is in fact the web proxy
which is making the DNS lookups without any distinction between one user
and another.
Whether the web proxy logs themselves violate state and/or federal laws
is an interesting question, but not really relevant to this thread or list.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
On 11/11/2010 7:55 AM, J. Thomsen wrote: If your main concern is resource consumption, maybe you should focus on developing some clever algorithm by which named could keep track of multiple references to the same data, without actually having to make separate copies of the data. Kind of a specialized compression algorithm. But, all of that could be done behind the scenes without introducing a new layer of configuration complexity. Well, there is a simple wellknown solution without thinking in duplicates. That solution is called searching for the data. It is even already partly implemented as views are searched for, so that concept is known within bind except that currently the search stops at the first matching view. From a nameserver implementation and maintenance perspective, it's even simpler for the data to already be present in the first view that matches. Why complicate things more than that? Different people have different definitions of what not found means, so you're never going to get a solid consensus on when searches should stop, and when they should keep on going to the next view. If by not found you mean anything and/or everything that a stub resolver would pass back to its invoker without an answer, then that includes not only NXDOMAIN, but also NODATA, referrals, CNAME-only responses, etc. Should *all* of those results cause this searching algorithm to continue to the next view? You're opening up a huge can of worms there. You're going to have to carefully consider each one of the cases to see if it does or does not qualify as a _bona_fide_ not found. There might be DNSSEC-validation repercussions too, but I'll let others who are more versed in such things speak to those. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
On 11/11/2010 1:22 PM, J. Thomsen wrote: From a nameserver implementation and maintenance perspective, it's even simpler for the data to already be present in the first view that matches. Why complicate things more than that? Because there is a need for it especially in large installations with a large number of zones. Different people have different definitions of what not found means, so you're never going to get a solid consensus on when searches should stop, and when they should keep on going to the next view. At the zone level, which is what we need, there cannot be any doubt. Yes, but the fallacy there is that records and zones are somehow inseparable. You can't know what the closest-enclosing-zone for a given QNAME is, until you search for that particular RRset within the namespace hierarchy. And in the course of that search, one may encounter CNAMEs, DNAMEs, wildcards, referrals, etc. before you can even determine what zone is ultimately involved. Just because you can't see the can of worms doesn't mean it isn't there. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
On 11/10/2010 3:17 PM, J. Thomsen wrote: Is there a way or option to configure bind to do the following logic: If the bind didn’t find a entry in a view 1 (internal view) it will search this entry on the view 2 (external view) ? Not to my knowledge. We had the same problem and ended up with using the hosts file for the special IP addresses. Hosts file? Special IP addresses? I don't quite understand your solution. The typical way to deal with these situations is to have two different views, internal and external, with the differentiated entries existing separately in their respective versions of the zone, and the entries which are common to both, shared via an $INCLUDE file. Not sure why you felt it necessary to resort to hosts files. The $INCLUDE-file trick is incompatible with Dynamic Update, of course, but if you already -- as we do -- have Dynamic Update and some sort of programmatic front-end on it, why not add just add the logic in the front-end for the updates to go to whichever view(s) in which they need to be visible? What am I missing here? It would have been nice to have been able to use BIND for everything. This just illustrates that the simple view concept in BIND really needs an overhaul as I have been advocating lately about groups of zones where the extended search is just done on zones not on individual resource records. Views in BIND was never meant to provide a general search function. It's an alternative to running -- multiple nameserver instances, listening on different interfaces, or -- completely separate nameserver devices. If you want fancy extended search capabilities, look elsewhere or, perhaps, figure out a way to implement this as a database backend to BIND. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forward after option
What you're suggesting is not really the inverse of forward first. Forward first is basically: (try forwarding) - [TIMEOUT FROM ALL FORWARDERS] - (try iterative resolution) The inverse would be: (try iterative resolution) - [TIMEOUT FROM ALL AUTHORITATIVE NAMESERVERS] - (try forwarding) But you're not talking about timeouts, right? You're talking about perfectly-valid responses that you don't like. This is not found forwarding and in all the years people have been asking for it, it has not been implemented in BIND because (at a minimum) a) there are ambiguities with respect to what constitutes not found (NXDOMAIN only? NODATA? REFUSED? SERVFAIL? DNSSEC validation failure?), and b) it complicates and confuses resolution, and maintenance/troubleshooting of same. In your case, what you might end up having to do is either a) start duplicating all of your external records in the internal version(s) of your zone(s), and have your business partner use that, or b) have your business partner look generally at the external version(s) of your zone(s), and then have them create a zone, with just a single leaf-node entry in it, for each name that they need to access, which does not exist in the external version of the zone, e.g. foo.bar.example.com. This could potentially add up to a lot of zone definitions. c) the inverse of the above: have your business partner look generally at the internal version(s) of your zone(s), and then create individual zones for each external name that they need to access. Note that for browser-based traffic *only*, a slightly-less ugly solution than (b) or (c) above is for your business partner to use a proxy auto-config (PAC) file with their clients (or modify their existing PAC). Then you can selectively control whether the client looks up the DNS itself (DIRECT), or uses a particular proxy, and then co-ordinate that with whether the clients or the proxy/proxies see the internal or external version(s) of the zone(s), respectively. E.g. internal sites go DIRECT and clients resolve the internal version of the zone, while external sites are proxied and the proxy sees the external version of the zone, or external sites go DIRECT and clients resolve the external version of the zone, while internal sites are proxied and the proxy sees the internal version of the zone, or internal sites go to proxyA and proxyA resolves the internal DNS, external sites go to proxyB and proxyB resolves the external DNS - Kevin P.S. If your internal and external DNS are completely distinct from each other, how do your own internal users get to your own external websites? If you're already solved that problem for your own clients, why not just use the same solution with your business partner, if possible? On 11/10/2010 3:08 PM, Stéphanas Schaden wrote: Hi all, we have a situation on our company today that is: We have a external authoritative zone in our public DNS. Have have a partner company that connect to our network and need to use a internal IP address of our company but using the internal link and the name of the FQDN of this access is configured on our external zone. We were looking about the forward configuration on BIND and we found that there is the forward only and forward first option. If our partner configure our external zone on their DNS and configured just this specific entry on the zone and configure the forward of the zone to our public DNS will not work because our public DNS have this entry and this entry is appointing to the public IP. So the entry on our customer DNS will be used just after it query our public DNS. So we were looking for if there is a option on BIND (we did not found anything yet) to do the inverse of the forward first. Something link forward after. So, if our customer DNS receive a query and it have that entry on the zone it will answer to the source. If it did not find this entry in the zone it will do the forward process to our public DNS. There is something that could do this using BIND ? Thank you very much. Stéphanas Schaden stephan...@ctbc.com.br Brazil ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: why one shouldn't use relative hostnames
On 11/10/2010 1:19 PM, Maria Iano wrote: We are working with a software vendor whose software only works with relative hostnames - they say it can't cope with a fully-qualified domain name. They want us to make sure the necessary domain is in all clients' search lists. Does anyone have any good references for me to explanations of why this is a very bad thing. I would find quick access to thoughtful well-phrased arguments very useful right now. I've looked for such a thing from time to time, with no success. Maybe I need to compose something like that. Main reasons for not using shortnames: a) Security. The problem cited way back in RFC 1535 still exists, in a slightly different form, with respect to shortnames, i.e. they're ambiguous and can cause names to resolve unexpectedly, thus causing connections to be made to unexpected hosts, which might not be trusted. E.g. we have multiple DNS names with the first label of mailroom, one could potentially connect to the wrong mailroom server, depending on the (somewhat arbitrary) ordering of one's searchlist. A less-trusted mailroom server could trojan the more-trusted one. b) Capacity and performance (specifically, query latency). Each searchlist element magnifies query volume, and increases query latency for all queries which don't happen to resolve with the first element in the searchlist. Names which don't resolve at all (typos, obsolete references, etc.) exhaust the *entire* searchlist, which has maximum latency to the invoking application, and uses maximum nameservice-infrastructure, network, logging and/or server resources. c) Undesired dependencies and co-ordination challenges. Shortname resolution depends on the precise configuration of searchlists, but in many organizations the DNS infrastructure experts are not in the same department as those who control the configuration of searchlists (which are often client OS experts rather than in the server or networking areas), so there can be co-ordination challenges between the departments. When using FQDNs, searchlists are unnecessary and therefore the dependencies and co-ordination challenges are minimized d) Inconsistency between internal and Internet environments; future-proofing. Shortnames are, by and large, not used on the Internet, because of the foregoing reasons, writ large because of the sheer scale and diversity of the Internet and its DNS namespace. If shortnames are used on an internal network, there is an inconsistency between the the two environments, internal and Internet, which may cause confusion and interoperability challenges, should a particular function or subsystem be out-hosted and/or attached to an Internet-accessible cloud at some point in the future. Under this heading, it should be noted that some Internet-oriented technologies absolutely require FQDNs as part of their formal specification. To my knowledge, no formal specifications (other than WINS/NETBIOS perhaps) require shortnames. Therefore, to be most flexible and accommodating to changing technologies and environments, it is best to use the naming format -- FQDNs -- which is most likely to be compatible and interoperable going forward. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
Alans, I think you're mixing up the resolver function with the hosting function. With some development and implementation, you can offer your customers the ability to set up and maintain their own domains on one nameserver instance, and then have another instance set up for them to resolve Internet DNS names. It is that resolving instance for which you may want to set up views, so that you can have per-customer blocking of domains (although in general this is better done in a web proxy than with Stupid DNS Tricks, IMO) but in that case the number of exception zones would presumably be much smaller than the thousands of domains you quoted, which would be in the hosting instance. How many domains would people want to block in this manner? As for per-customer blocking, I'd suggest having just one blocking view, with the specific domains that are to be blocked, as empty or wildcarded zones, running on a separate interface, and have your blocking-subscribed customers point to that. If that's not fine-grained enough, have a small number of blocking levels -- e.g. none, loose, medium, tight, supertight -- running on separate interfaces, and your customers can choose between them. If they want to pick and choose domain-blocks individually, then this doesn't scale (it's 2-to-the-power-of-n, where n is the number of domains blocked or not blocked), so, as another poster here suggested, for such special needs, make them run their own blocking nameserver config, either completely their own, or layered (through forwarding) on top of one of your loose/medium/tight/supertight offerings. You could offer them some sort of template for this local nameserver config, but ultimately it would be their responsibility to set up and run. Make clear to them that blocking domains was never a designed-in function of the DNS, that they're essentially abusing a name-to-address mapping service to enforce policy controls on their respective user communities, enforcement that oftentimes is easily circumvented by using other naming mechanisms (e.g. local hosts files) or IP-address literals. - Kevin On 11/8/2010 1:01 AM, Alans wrote: On 11/08/2010 12:52 AM, Doug Barton wrote: On 10/31/2010 9:41 AM, Alans wrote: On 10/31/2010 05:48 PM, Alan Clegg wrote: On 10/31/2010 4:48 AM, Alans wrote: Instead of saying how many views can I get, I think you would be much better off saying why am I trying to implement more views. I'm trying to implement something similar to OpenDNS in a smaller scale. i.e. letting each customer to create their own blacklist domains. So I was thinking if I can create a view for each customer and let them edit their zones in a web interface and here my concern is the number of views i can create and number of zones/view. I'm not sure you quite understand what zones and views are. Why would you not simply create a single zone per customer, and eliminate views altogether? Well, maybe I'm not, but how to create a zone per customer? Example, customer1 wants to block access to facebook.com while customer2 wants normal access to facebook.com, how a single view can do that? And we are talking about thousands of domains here. Alans ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
On 11/10/2010 7:23 PM, J. Thomsen wrote: Not sure why you felt it necessary to resort to hosts files. Well, I don't know how to configure ressource records in an include file and don't want to waste gigabytes of RAM duplicating zones. If your main concern is resource consumption, maybe you should focus on developing some clever algorithm by which named could keep track of multiple references to the same data, without actually having to make separate copies of the data. Kind of a specialized compression algorithm. But, all of that could be done behind the scenes without introducing a new layer of configuration complexity. What am I missing here? The idea of avoiding front ends ! What's a front end and what isn't, is largely in the eye of the beholder. I see views as a front end to multiple, disparate data sets within BIND. You want to put more smarts into that front end, whereas I think it's better to put the smarts into the stage of the pipeline just before BIND. Why is your approach inherently better than mine? Views in BIND was never meant to provide a general search function. Alas they should never be changed. If you want fancy extended search capabilities, look elsewhere or, perhaps, figure out a way to implement this as a database backend to BIND. Right, I understand the point. Let us stay in the good old days. No bright ideas here. They may disturb the peace. What I am missing on this list is people, which do not see their primary task as keeping everything as it is and taking an interest in discussing new ideas. To be honest, I don't really see anything new here. Similar ideas have been raised many times before. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to get easily (from a script) all CNAME of a A record?
PTR RRs benefit from label compression, whereas TXT records do not.
Therefore I prefer PTR records for any such metadata references within
DNS. There's no chance they'll be mistaken for, or conflict with reverse
DNS records if they're not in the in-addr.arpa branch of the namespace.
- Kevin
On 11/9/2010 4:16 PM, philippe.simo...@swisscom.com wrote:
Hi
If you have control over all zones, you could also pre-store the
results of
your search in DNS J
For all CNAME records, make e.g. a TXT record with the reverse result :
(TXT is maybe not the better record type...which ones (for specialists))
For each :
a-name IN A 1.2.3.4
an-alias IN CNAME a-name
Just add :
a-name IN TXT an-alias
and make more than one TXT records for each cname pointing to the same
record ...
a-name IN TXT another-alias
best regards
Philippe
*From:*bind-users-bounces+philippe.simonet=swisscom@lists.isc.org
[mailto:bind-users-bounces+philippe.simonet=swisscom@lists.isc.org] *On
Behalf Of *Stacey Jonathan Marshall
*Sent:* mardi 9 novembre 2010 16:53
*To:* bind-users@lists.isc.org
*Subject:* Re: How to get easily (from a script) all CNAME of a A record?
On 09/11/2010 14:14, Michelle Konzack wrote:
Hello Matus UHLAR - fantomas,
Am 2010-11-09 14:13:47, hacktest Du folgendes herunter:
I am not sure whether dnswalk over whole internet can do that, but on your
I will try it...
server you can either run recursive grep over named data directory, or dump
the named dsatabase and grep it...
This is what I currently do...
[ '/usr/sbin/get_hosts_in cname' ]--
#!/bin/sh
QUERY=$1
for FILE in $(cd /etc/bind ls *.signed)
do
grep --regexp= IN CNAME .*${QUERY} /etc/bind/${FILE} 2/dev/null |cut -d '
' -f1 |sed 's|.$||'
done
...and it is to slow do to more then 80.000 Zones (they have to be
greped all) number of VHosts.
Oh, it is now time to use xargs, because I saw today, that I hit the
limits for ls. :-D
Following is working:
cd /etc/bind ls
but not:
cd /etc/bind ls *
or
cd /etc/bind ls *.signed
and the OSes are called Linux and BSD... WTF?
It seems that a commandline can not have more then 31.000 characters.
(no not options but total lenght)
Thanks, Greetings and nice Day/Evening
Michelle Konzack
The asterisk causes the shell to expand the names and run ls with them
as a single command, so in effect you have ls file1 file2 file3
Try the following instead:
cd /etc/bind
for FILE in *.signed
do
grep --regexp= IN CNAME .*${QUERY} ${FILE} 2/dev/null |cut -d ' ' -f1
|sed 's|.$||'
done
It might still have the same issue, but worth a go.
I assume the command length is also why your not simply running grep
-h expression *.signed?
Stace
___
bind-users mailing list
bind-users@lists.isc.org mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind and blacklist IP file
On 10/11/2010 2:44 PM, Nuno Paquete wrote: Ok, but you can always browse by IP address and in this case there is no DNS server than can stop you from browsing what you want. If you want to block IP address access you have to use firewall, or if you are talking about http traffic and have a proxy, maybe you have to block there. That's why I completly agree this should not be blocked at DNS level. To nitpick: address-block-based filtering*could* be implemented in DNS. The same mechanisms that are used to prevent rebinding attacks -- e.g. BIND's *deny-answer-addresses* -- could theoretically be repurposed to strip addresses in certain banned ranges from DNS responses. Arguably this is a misuse/abuse of the feature. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 10/5/2010 3:49 PM, Dotan Cohen wrote: On Tue, Oct 5, 2010 at 20:30, Eivind Olseneiv...@aminor.no wrote: However, another site that _does_ work (with both nameservers on this host, not just ns1) shows the same thing: # nslookup ns1.sharingserver.eu 178.63.65.136 Server: 178.63.65.136 Address:178.63.65.136#53 ** server can't find ns1.sharingserver.eu: NXDOMAIN How do you mean this one is working? It's working just as badly as your first example. Yes, but typing the domain into Firefox brings up the webpage that I've put on that server! You're introducing a bunch of other variables when you use a browser to troubleshoot a DNS resolution problem: 1) The browser might have cached the DNS response 2) The browser might have cached the web content itself and not be performing DNS lookups 3) The browser might be using a PAC (proxy auto-config) file which shuffles the request off to some proxy I would suggest sticking to DNS troubleshooting tools to troubleshoot DNS. And dig/host is to be greatly preferred for that purpose over nslookup, which sucks in more ways than I care to list here. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 10/6/2010 11:44 AM, Ben McGinnes wrote: On 7/10/10 2:09 AM, Kevin Oberman wrote: I can find nothing in the documentation that states such. If I missed it, I'd appreciate someone pointing me at it. I have some vague memory of seeing messages to that effect when using it on a Solaris system in around 1999. I stopped using it around then and switched to host and dig. I can't point you to specific documentation (I stopped caring when I started using dig), but I did find these: http://cr.yp.to/djbdns/nslookup.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html As far as I'm aware it only hung around because it was available on Windows NT/2K/etc., while host and dig were not. ISC has tried to kill it, but the beast is resilient and won't die. Invocations of nslookup are embedded in thousands of legacy scripts and some folks are unable or unwilling to change them. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
Per-zone recursion control doesn't exist in BIND, because frankly it
doesn't make sense.
Either a zone type is meaningless *without* recursion (type forward,
type stub), or recursion is *unnecessary* because the nameserver answers
from authoritative data (type master, type slave).
Put another way, have you thought through exactly what you want to
happen if a client queries something not specifically carved out for
recursion, e.g. isc.org?
The response from a BIND instance, when recursion is denied or not
requested, is always either (as per Section 4.3.1 of RFC 1034):
a) an answer from authoritative data,
b) an answer from cache
c) a negative-caching response,
d) a (0 answers) referral, or
e) some sort of non-response, like an error (SERVFAIL) or an
administrative rejection of the query (REFUSED)
If (a) doesn't apply (because not authoritative) and neither does (b)
(because how can answers be cached in the first place if recursion is
being denied?), that leaves (c) through (e), none of which are
particularly useful to the client. So you might as well REFUSE queries
outside of zones for which recursion is not explicitly enabled.
Configure allow-query { none; }; as the default followed by specific
exceptions for the zones you want to open up, e.g., dynsup.example.net.
- Kevin
On 9/30/2010 5:09 AM, Joerg Dorchain wrote:
Hello,
I am puzzled with a bind config for a kind of dns-reverse-proxy situation.
I have a server with only one public IP addresse, bind running on
port 53 of it.
This bind serves examples.net. A subdomain dynsub.example.net
should be served on some other software answering DNS request
with dynamically generated answers.
I can create a forward zone like this
zone dynsup.example.net {
type forward;
forward only;
forwarders { 127.0.0.1 port 5353; };
};
which works fine in the way that it forwards all queries to and
all answers from the other DNS software running on port 5353, but
- this is problem - only if the view with the statement allows
recursion.
For several reasons I do not want to answer all queries for all
domains recursivly, just those for that one zone.
When I turn recursion off, bind answers with a referal to itself
(glue records work ;-), which in this case is not helpful.
Does anybody have an idea on how I can persuade bind to answer
only this zone recusivly?
TIA,
Joerg
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Round robin DNS query response
On 9/29/2010 12:37 AM, SW wrote: Hi everyone... I am rather new to the world of DNS so I'm hoping to get some of your expertise... Is there a way to make BIND respond DNS query in sequence? For example, if I assign 2 IP addresses to an A record, is it possible to have it respond like... Client 1 for www.example.com - 192.168.1.1 Client 2 for www.example.com - 192.168.1.2 Client 3 for www.example.com - 192.168.1.3 ...and so on. I know companies use load balancer for this function, but my customer in this case don't really want to make additional investment :P Option A: round-robin+sortlist Option B: views Appropriate caveats for each approach. Note that if these are Windows clients on the same subnets as the www.example.com addresses, you could probably just get away with a plain old round-robin and rely on the built-in Windows subnet prioritization, see http://www.windowsitpro.com/article/dns/what-is-dns-round-robin-and-subnet-prioritization-.aspx - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND on CentOS: Nameservers for two domains
This is more of a registry/registrar question than a BIND/DNS question.
About the only _generic_ advice I can give you -- since you obscured the
domain names and the relevant addresses, so I can't actually check
anything on my own -- is to query the .eu servers directly for the
delegation records. It's possible that what you see in their control
panel doesn't match what's in the actual DNS, and what's in the actual
DNS *matters*, as opposed to whatever crap displays or doesn't display
in their control panel. I've seen a lot of breakage in registrar
control panels over the years, so this wouldn't surprise me in the least.
- Kevin
On 9/27/2010 4:42 AM, Dotan Cohen wrote:
Hello, I am trying to configure a single CentOS 5 machine as a server
for two unrelated websites:
example.eu
example.de
The server has four IP addresses assigned to it:
1.1.1.136
1.1.1.171
1.1.1.172
1.1.1.188
I plan on hosting example.eu on this server with these two IP
addresses for its name servers:
1.1.1.136 - ns1.example.eu
1.1.1.188 - ns2.example.eu
Likewise, I plan on hosting example.de on this server with these two
IP addresses for its name servers:
1.1.1.171 - ns1.example.de
1.1.1.172 - ns2.example.de
These are my relevant configuration files:
[r...@centos-55-32-minimal ~]# cat /etc/named.conf
options {
directory /etc;
pid-file /var/run/named/named.pid;
listen-on {
any;
};
};
zone . {
type hint;
file /etc/db.cache;
};
zone example.de {
type master;
file /var/named/example.de.hosts;
};
zone example.eu {
type master;
file /var/named/example.eu.hosts;
};
[r...@centos-55-32-minimal ~]# cat /var/named/example.eu.hosts
$ORIGIN example.eu.
$TTL 86400
example.eu. IN SOA ns1.example.eu. ns2.example.eu. (
5; Serial - increment me
10800
3600
604800
38400 )
IN NSns1.example.eu.
IN NSns2.example.eu.
IN A 1.1.1.136
IN A 1.1.1.188
wwwIN A 1.1.1.136
wwwIN A 1.1.1.188
ns1IN A 1.1.1.136
ns2IN A 1.1.1.188
[r...@centos-55-32-minimal ~]# cat /var/named/example.de.hosts
$ORIGIN example.de.
$TTL 86400
example.de. IN SOA ns1.example.de. ns2.example.de. (
5; Serial - increment me
10800
3600
604800
38400 )
IN NSns1.example.de.
IN NSns2.example.de.
IN A 1.1.1.171
IN A 1.1.1.172
wwwIN A 1.1.1.171
wwwIN A 1.1.1.172
ns1IN A 1.1.1.171
ns2IN A 1.1.1.172
In BIND and in the registrar control panel for example.eu I had set
the IP addresses originally to 1.1.1.171 and to 1.1.1.172, however due
to a technical problem with the .de domain I later changed the
configuration to 1.1.1.136 and 1.1.1.188 (because it turns out that
.de domains cannot have the two nameservers on the same C block, and
only the 171 and 172 addresses I can swap for another address).
However, even though the registrar control panel is set to
ns1.example.eu as 1.1.1.136 and ns2.example.eu as 1.1.1.188, I still
see this in whois:
[r...@centos-55-32-minimal ~]# whois example.eu
// snip irrelevant lines
Nameservers:
ns1.example.eu (1.1.1.171)
ns2.example.eu (1.1.1.172)
I last made changes to the BIND configuration and to the registrar
control panel on Friday, 2010-9-24 which was three days ago. Therefore
I do not suspect that DNS propagation time is the issue here. Of
course, I also increased the serial line in the zone files when those
files changed. What am I missing, or what might I have done wrong?
Thank you in advance.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Is 10.in-addr.arpa not recommended?
On 9/27/2010 8:48 PM, donovan jeffrey j wrote: I run a number of internal clients on 10 address space. what i did was break up each Zone into Class B's 10.1.x.x , 10.2.x.x then my forward and reverse files into class C's. Each record 10.1.1.x . 10.1.2.x, 10.1.3.x, . then scale ass needed. providing the means to add forward and reverse to any address within that address space. Ugh, pet peeve. 10/8 is, if one uses obsolete classful terminology instead of CIDR, a Class A, which covers the whole range. Nothing sliced out of 10/8 can be a Class B or a Class C. Correct terminology for what you described would be /16 or /24, respectively. In the old scheme, Class Bs start(ed) at 128.*.*.* and Class Cs start(ed) at 192.*.*.*. Google classful if you don't believe me. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query cache denied in vew statement
Hopefully you understand that when you turn recursion off, that means you can only answer from zones that you actually *host* (i.e. for which you are master or slave). But you have no master or slave zones defined in the mynetwork view. Therefore it is not possible for that view to do anything useful, the way that it is currently configured. - Kevin On 9/27/2010 4:45 AM, David S. wrote: Hi Pil, In that case, don't you want recursion on in view mynetwork? I won't recursion in my network, so recursion is no. - -- Best regards, David http://blog.pnyet.web.id On 09/27/2010 03:32 PM, Phil Mayers wrote: In that case, don't you want recursion on in view mynetwork? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS resolution based on source network
Under certain limited circumstances, it might make more sense to put both/all addresses under the same name, and then use the sortlist mechanism to present those addresses in an order which is suitable for particular clients. Among other things, this requires that all resolver/nameserver configs be configured with the same sortlist configs, that there is no local randomization or re-sorting of the address list, and that there are no negative consequences for the client or the client software to connect to the wrong address if the preferred one happens to be unavailable. Views are fine, but historically they're a fairly heavyweight solution for this class of requirement, because all relevant zones need to be defined multiply and this is difficult to maintain and consumes extra memory/CPU resources. The new (9.7.x?) attach-cache feature addresses the resource issue somewhat, but still doesn't obviate parallel/overlapping zone definitions and associated setup/maintenance. With sortlisting, all your zone definitions stay the same, you just need to create the round-robin entries and define the appropriate address ranges in your sortlist and/or acls clauses. - Kevin On 9/27/2010 9:00 AM, Thomas Elsgaard wrote: Hello Is it possible with BIND, to resolve the same name (like test.gl) to different IP's based on the source network of the request? Here is an example A machine in network 10.3.0.0/16 is contacting DNS to lookup test.gl, DNS returns - 10.0.0.2 A machine in network 10.5.0.0/16 is contacting DNS to lookup test.gl, DNS returns - 10.0.0.5 Thomas ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS issue
On 8/29/2010 5:22 AM, Agarwal Vivek-RNGB36 wrote: Hi All I am using ISC-BIND 9.3.4 as a DNS Server. Im facing an issue that Im getting lot of Queries as likeRoot: type NS, class IN. This is leading to high CPU Utilization of my system. Can anyone help me that how can I solve this issue and why these requests will be coming Are those queries literally the word Root (6 characters), or are you attempting to represent in your post the root node . (0 characters, since there is an implied dot at the end of every DNS name), which is the top of the DNS namespace hierarchy? If it's NS queries of the root node, then those are natural and normal, if anyone has your nameserver set as a global forwarder in their config, or a source of root hints. If you don't wish to be used as a forwarder or hints source then, as another poster suggested, you could implement some access controls. But, I would add the caveat: if you have several nameservers that are being used in this way, turning off one of them may simply shift the traffic to one or more of the others, and this could make your CPU-utilization situation even *worse*. If you intend on instituting access controls, you might want to consider implementing the same controls on *all* of the nameservers in the same set *simultaneously*, in order to head off such problems. Depending on your setup and organization, this may be logistically difficult to pull off. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification on bind response
On 8/24/2010 2:25 AM, rams wrote: Hi, I have set up data as follows in bind. Zone: rameshops5526old.com http://rameshops5526old.com maint.rameshops5526old.com http://maint.rameshops5526old.com. 300 IN CNAME maint.global.rameshops5526old.com http://maint.global.rameshops5526old.com. rameshops5526old.com http://rameshops5526old.com. 21600 IN NS dns5.rameshops5526old.com http://dns5.rameshops5526old.com. rameshops5526old.com http://rameshops5526old.com. 21600 IN NS dns2.rameshops5526old.com http://dns2.rameshops5526old.com. rameshops5526old.com http://rameshops5526old.com. 21600 IN NS dns1.rameshops5526old.com http://dns1.rameshops5526old.com. rameshops5526old.com http://rameshops5526old.com. 21600 IN NS dns6.rameshops5526old.com http://dns6.rameshops5526old.com. rameshops5526old.com http://rameshops5526old.com. 21600 IN NS dns4.rameshops5526old.com http://dns4.rameshops5526old.com. rameshops5526old.com http://rameshops5526old.com. 21600 IN NS dns3.rameshops5526old.com http://dns3.rameshops5526old.com. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS j.ns.nsatc.net http://j.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS a.ns.nsatc.net http://a.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS l.ns.nsatc.net http://l.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS d.ns.nsatc.net http://d.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS b.ns.nsatc.net http://b.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS e.ns.nsatc.net http://e.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS c.ns.nsatc.net http://c.ns.nsatc.net. Queried against bind and get the reposne as follows [r...@stulcqacustbind2 recursive_enabled]# dig @10.31.145.194 http://10.31.145.194 maint.rameshops5526old.com http://maint.rameshops5526old.com. ; DiG 9.6.1-P3 @10.31.145.194 http://10.31.145.194 maint.rameshops5526old.com http://maint.rameshops5526old.com. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 16855 ;; flags: qr *aa* rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;maint.rameshops5526old.com http://maint.rameshops5526old.com. IN A ;; ANSWER SECTION: maint.rameshops5526old.com http://maint.rameshops5526old.com. 300 IN CNAME maint.global.rameshops5526old.com http://maint.global.rameshops5526old.com. ;; AUTHORITY SECTION: global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS e.ns.nsatc.net http://e.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS l.ns.nsatc.net http://l.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS a.ns.nsatc.net http://a.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS j.ns.nsatc.net http://j.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS c.ns.nsatc.net http://c.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS d.ns.nsatc.net http://d.ns.nsatc.net. global.rameshops5526old.com http://global.rameshops5526old.com. 300 IN NS b.ns.nsatc.net http://b.ns.nsatc.net. ;; Query time: 2 msec ;; SERVER: 10.31.145.194#53(10.31.145.194) ;; WHEN: Tue Aug 24 06:26:31 2010 ;; MSG SIZE rcvd: 195 Here AA flag is returning is it correct? because domain global.rameshops5526old.com http://global.rameshops5526old.com. delegated so we should not return AA flag right? Please clarify me. You're authoritative for the CNAME record that is contained in the Answer Section. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification on bind response
On 8/24/2010 8:18 AM, rams wrote: Hi When we have data as follows queried domain maint.rameshops5526old.com http://maint.rameshops5526old.com/. against bind and my own resolver. Bind and my resolver response are same but only mismatching with flags. bind is returning AA flag but my resolver is not returning AA flag. in this case wihcih is correct bind or my resolver? Zone: rameshops5526old.com http://rameshops5526old.com/ maint.rameshops5526old.com http://maint.rameshops5526old.com/. 300 IN CNAME maint.global.rameshops5526old.com http://maint.global.rameshops5526old.com/. rameshops5526old.com http://rameshops5526old.com/. 21600 IN NS dns5.rameshops5526old.com http://dns5.rameshops5526old.com/. rameshops5526old.com http://rameshops5526old.com/. 21600 IN NS dns2.rameshops5526old.com http://dns2.rameshops5526old.com/. rameshops5526old.com http://rameshops5526old.com/. 21600 IN NS dns1.rameshops5526old.com http://dns1.rameshops5526old.com/. rameshops5526old.com http://rameshops5526old.com/. 21600 IN NS dns6.rameshops5526old.com http://dns6.rameshops5526old.com/. rameshops5526old.com http://rameshops5526old.com/. 21600 IN NS dns4.rameshops5526old.com http://dns4.rameshops5526old.com/. rameshops5526old.com http://rameshops5526old.com/. 21600 IN NS dns3.rameshops5526old.com http://dns3.rameshops5526old.com/. global.rameshops5526old.com http://global.rameshops5526old.com/. 300 IN NS j.ns.nsatc.net http://j.ns.nsatc.net/. global.rameshops5526old.com http://global.rameshops5526old.com/. 300 IN NS a.ns.nsatc.net http://a.ns.nsatc.net/. global.rameshops5526old.com http://global.rameshops5526old.com/. 300 IN NS l.ns.nsatc.net http://l.ns.nsatc.net/. global.rameshops5526old.com http://global.rameshops5526old.com/. 300 IN NS d.ns.nsatc.net http://d.ns.nsatc.net/. global.rameshops5526old.com http://global.rameshops5526old.com/. 300 IN NS b.ns.nsatc.net http://b.ns.nsatc.net/. global.rameshops5526old.com http://global.rameshops5526old.com/. 300 IN NS e.ns.nsatc.net http://e.ns.nsatc.net/. global.rameshops5526old.com http://global.rameshops5526old.com/. 300 IN NS c.ns.nsatc.net http://c.ns.nsatc.net/. AA is set on BIND's response because the CNAME is coming directly from authoritative data. AA is not set on your resolver's response because the answer *isn't* coming directly from authoritative data. Why is this an issue? A stub resolver or an application generally doesn't -- and shouldn't -- care -- or usually doesn't even *know* -- about the setting of the AA flag. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple CNAME alternantive?
On 8/19/2010 10:52 AM, Steve Arntzen wrote: I would like to resolve dns.ourdomain.com to a list of our DNS server names and possibly their IPs. As we use many DNS servers (and or views) for our different development environments, it would be very helpful for the developers to easily find the name and IP of the proper name server to use. EXAMPLE: A lookup for dns.ourdomain.com would result in: nsdev1.ourdomain.com192.168.100.10 nsdev2.ourdomain.com192.168.100.11 nstest1.ourdomain.com 192.168.100.12 nstest2.ourdomain.com 192.168.100.13 nsprod1.ourdomain.com 192.168.100.14 nsprod2.ourdomain.com 192.168.100.15 etc. I want to avoid using configuration exceptions and multiple CNAMEs. Does anyone have a clean alternative? If you really want a list of *names*, then you have a number of record types you could use, which have names in the RDATA part of the record, e.g. PTR, MX, SRV. PTR is probably the purest way to catalog a list of names, since it doesn't have any extraneous RDATA fields that you'd need to fill with dummy info, and also it benefits from label compression in responses. I am *not* a fan of representing hostnames in TXT records, since those don't benefit from label compression, and also, they don't prevent the accidental inclusion of extraneous characters (although those validations can be performed by whatever tool(s) maintain the data in those records). Resolver configs use IP addresses, not names. If you just want a list of *addresses*, then these can be enumerated in a round-robin A record. You can even apply sortlisting to that, if you want. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple CNAME alternantive?
On 8/19/2010 1:27 PM, Dave Sparro wrote: On 8/19/2010 10:52 AM, Steve Arntzen wrote: I would like to resolve dns.ourdomain.com to a list of our DNS server names and possibly their IPs. As we use many DNS servers (and or views) for our different development environments, it would be very helpful for the developers to easily find the name and IP of the proper name server to use. EXAMPLE: A lookup for dns.ourdomain.com would result in: nsdev1.ourdomain.com192.168.100.10 nsdev2.ourdomain.com192.168.100.11 nstest1.ourdomain.com 192.168.100.12 nstest2.ourdomain.com 192.168.100.13 nsprod1.ourdomain.com 192.168.100.14 nsprod2.ourdomain.com 192.168.100.15 etc. I don't think I'd do that in DNS. I'd point an A record for that name to a server that was running a simple web server that would spit out the list for any HTTP request, and maybe even a modified telnet daemon that would spit out the list upon a connection as well. That way your users would have a simple, relatively universal command line entry like telnet dns.example.com to use. It's a matter of personal preference, of course, but Ill point out that DNS is more lightweight than HTTP or telnet, easier to script (using the Net::DNS Perl module or gethostbyname()), and the sortlist mechanism allows for sorting a round-robin list of addresses optimally according to the source IP of the client. It's not clear to me, however, whether the OP really has a requirement to retrieve the *names* of the nameservers, or whether he just wants to fetch an optimized list of addresses to use for building a resolver config dynamically. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Rebinding Prevention for the Weak Host Model Attacks
deny-answer-addresses { %source%; };
deny-answer-aliases { %source%; };
Maybe?
- Kevin
On 8/17/2010 12:22 AM, Bradley Falzon wrote:
bind-users,
In light of Craig Heffner's recent Black Hat talk (here:
https://media.blackhat.com/bh-us-10/whitepapers/Heffner/BlackHat-USA-2010-Heffner-How-to-Hack-Millions-of-Routers-wp.pdf
and here: http://rebind.googlecode.com) I would like to propose a
possible solution in line with the 'DNS rebinding attack prevention'
provided in version 9.7.
Craig Heffner's version of the DNS Rebinding attack, similar to all
DNS Rebinding attacks, requires the DNS Servers to respond with an
Attackers IP Address as well as the Victims IP Address, in a typical
Round Robin fashion. Previous attacks would normally have the Victims
IP Address to be their Private IP.
BIND, in version 9.7, developed two new options: deny-answer-addresses
and deny-answer-aliases. Within these ranges an ISP or Corporation
could put in the list of RFC1918 Addresses or other address clients
should never be resolving to. However, Craig's attack would bypass
these rules: the Victims IP is actually the Victims WAN IP - not their
internal address. An ISP would be unable to place their entire IP pool
into the 'deny-answer-*' options, allocated to customers, because this
would break many legitimate uses.
I would like to know though, what if bind was given the option that
allowed an ISP to block and/or log DNS requests (again with a
SERVFAIL), based on if the query-source was in the response along with
at least one other address.
Basically:
if ( query.source = query.result[0] count(query.result) 1 ) {
return (servfail)
}
If the Source IP of the client was also at least one of the results,
log and return a SERVFAIL. The rule would permit queries with a single
response.
Craig Heffner's method is serious for ISP's that supply their
customers modems that are vulnerable. The proper protections on the
customers modems would be a logistical nightmare.
Placing these protections, along with the current DNS Rebinding
protections already in 9.7 would be a great step forward in
realistically protecting these types of attacks.
I would propose three parameters for this. The first mode being
completely off (and I assume the default); the second, Permissive,
would only log the attacks; the third, Enforcing, would log and block
the attacks.
This would allow ISPs to upgrade to these specific versions of bind,
turn on Permissive parameter first and Enforcing if the attacks become
well known or impact is minimal.
What are your thoughts on this ? What could these protection break the
legitimate use for ?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: filter packets bound for company proxy server?
On 8/16/2010 8:10 AM, Greg Hauptmann wrote: Hi, Can I ask if anyone has a good idea for how I could identify (filter packets) that are transiting via a company proxy server [e.g. proxy.mycompany.com]. The challenge here is that the DNS server will issue any one of a number of IP addresses back to the browser to use, associated with the range of physical separate proxy servers that you might end up on. I've tried using the filter hostproxy dns address however this doesn't seem to work. In fact some testing I did with wireshark to provide an example of what I'm seeing is: ASSUMPTIONS: First in terms of some assumptions for the sake of this example: nslookup proxy.mycompany.com Name:proxy.xxx..yyy.mycompany.com Address: 10.10.1.10 Aliases: proxy.mycompany.com nslookup 10.1.1.10 Name:proxy3.zzz.aaa.mycompany.com Address: 10.10.1.10 WIRESHARK RESULTS FOR GIVEN CAPTURE FILTER: a) host proxy.mycompany.com = Does not pickup the browser traffic I created that transits the proxy. Again my goal is to find a way to filter on this. b) host proxy3.zzz.aaa.mycompany.com = Does pick up the traffic BUT of course I've had to manually type in the actual proxy server. I tested with the same browser straight after putting in the capture filter so the proxy I was handed back obviously didn't change in that small time (i.e. at other time I would be handed off to proxy5.zzz.aaa.mycompany.com say for example) So I'm running out of ideas re how I could identify whether, for a given packet, whether it is one that has transited via the proxy serverany ideas? Would dig be a reliable way to get a list of all IP's associated with the main proxy DNS name? Would this be a possible solution re identifying them all perhaps? No it would not be a reliable way, because it's likely to be a load-balancer that's actually responding to the query for proxy.mycompany.com, and it'll return whatever it considers to be the best proxy at any given point in time. You'd have to look at the load-balancer config to know for sure all of the *possible* answers it could give to that question. An imperfect approach would be to query that name repeatedly over time and collect all of the IPs that you get in response, but with this approach you can't really know for sure that you got *all* of them. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
