private tld
My company uses a private tld. We are working on fixing that but the fix is going to take a while, especially if our solution ends up being trying to register it with icann. Our resolvers that all internet queries go through have a forward zone statement for that tld to some internal name servers. Unfortunately, when I turn on dnssec validation our resolvers go check out the root zone, see our private zone doesn't exist, and refuse to resolve records in the zone. Is there a solution I can put in place so we can do dnssec validation in the meantime while we work on ceasing to use the private tld? Thanks, Maria ___ 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: private tld
Thank you for all of the responses, I really appreciate it. Clearly the best approach is to sign the internal tld, but at the moment I can't do that because I would need new internal servers, ours don't support dnssec. I configured it as a slave and it's working. Thanks! Maria On Tue, Aug 20, 2013 at 08:17:03PM -0500, Timothy Morizot wrote: > DNSSEC sign the private TLD and configure its KSK as a trust anchor on the > recursive resolvers. > > Alternatively, you can configure all your recursive resolvers as slaves for > the private zone. Authoritative responses aren't validated on a mixed > authoritative/recursive nameserver. > > Those are the only two options that immediately spring to my mind. > > Scott > On Aug 20, 2013 5:16 PM, "Maria" wrote: > > > My company uses a private tld. We are working on fixing that but the fix > > is going to take a while, especially if our solution ends up being trying > > to register it with icann. > > > > Our resolvers that all internet queries go through have a forward zone > > statement for that tld to some internal name servers. Unfortunately, when I > > turn on dnssec validation our resolvers go check out the root zone, see our > > private zone doesn't exist, and refuse to resolve records in the zone. Is > > there a solution I can put in place so we can do dnssec validation in the > > meantime while we work on ceasing to use the private tld? > > > > Thanks, > > Maria > > ___ 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: Reinstall after modifying
On Wed, Aug 21, 2013 at 08:18:36PM +0200, Jan-Piet Mens wrote: > > how can I install bind as a named server after I have made my > > modification to it's source code without using "yum" > > First you ./configure, specifying the options you want to use; pay > particular attention to installation paths. (The best way to determine > how your existing BIND was configured is to locate a SRC RPM file and > look at its .spec file and patches.) > > Then you `make'. If all goes well, you either `make install', in which > case the files and programs are copied to the paths you specified in the > first step, or if you just want to test `named', you can run > `bin/named/named' from the top-level directory of the source > distribution. > > -JP Don't forget to exclude the bind packages in yum.conf or it will be overwritten in an update. If you do this for the same reason as I do, to get the pre-made /var/named/chroot directory, then you might like this. After the server is first built, I move /var/named/chroot out of harms way and remove all the bind packages. Then I put it back and can make my own bind installation with whatever paths I like. Maria ___ 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
packet size
What does it mean when the edns0 response to a dig says the overall packet size will be one value but the message size reported is different. For example in this reponse the OPT PSEUDOSECTION says udp: 4096 but at the end it says MSG SIZE rcvd: 275. $ dig www.google.com ; <<>> DiG 9.9.3-P2-gci-9.9.3-P2-1.P2.gci.el6 <<>> www.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18023 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.com.IN A ;; ANSWER SECTION: www.google.com. 113 IN A 74.125.131.147 www.google.com. 113 IN A 74.125.131.103 www.google.com. 113 IN A 74.125.131.99 www.google.com. 113 IN A 74.125.131.105 www.google.com. 113 IN A 74.125.131.104 www.google.com. 113 IN A 74.125.131.106 ;; AUTHORITY SECTION: google.com. 95419 IN NS ns4.google.com. google.com. 95419 IN NS ns3.google.com. google.com. 95419 IN NS ns2.google.com. google.com. 95419 IN NS ns1.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 95419 IN A 216.239.32.10 ns2.google.com. 95419 IN A 216.239.34.10 ns3.google.com. 95419 IN A 216.239.36.10 ns4.google.com. 95419 IN A 216.239.38.10 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Sep 11 11:56:32 EDT 2013 ;; MSG SIZE rcvd: 275 I want to know because I have been asked what the impact to DNS in our environment would be if they dropped udp fragments at the border. It seems to me I would have to configure our name servers to drop back to tcp when a packet is over 1500. I'm trying to understand just how much that would impact the servers. Thanks, Maria ___ 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
make test fails without Net::DNS::Nameserver
I don't see this mentioned anywhere else, although I'm suprised by that so maybe I'm missing something. When I build bind-9.10.2-P2 I find that "make test" fails for reclimit with "Couldn't start server ans2" if I don't have Net::DNS::Nameserver installed. After I install it the testing is successful. Maria ___ 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
REQUIRE(rdataset->rdclass == db->rdclass) failed
We have a private internal TLD which I have our resolver pull as a slave zone to prevent it failing dnssec. It has subdomains and normally our resolver follows the delegations and resolves those correctly without needing to pull slave copies. If I use the option: attach-cache "globalcache"; and query a subdomain then named dies with the error: general: critical: db.c:767: REQUIRE(rdataset->rdclass == db->rdclass) failed general: critical: exiting (due to assertion failure) So far my server is running fine once I remove 'attach-cache "globalcache";'. Is this a known issue with internal private TLDs and I should just give up on using a shared cache? Getting rid of our internal domain is a huge undertaking which won't be completed any time soon. Thanks, Maria ? ___ 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: REQUIRE(rdataset->rdclass == db->rdclass) failed
On Thu, Jul 30, 2015 at 05:56:31PM +, Evan Hunt wrote: > > On the one hand: No, this is a bug, and I'd appreciate it if you'd > bundle up your named.conf (with key secrets stripped out; you can use > named-checkconf -px to do this automatically) and the details of the query > you sent to bind9-b...@isc.org. > > On the other hand: I don't see why you'd want to share a cache between two > views if only one of them has access to the internal TLD. > I submitted the bug report and it's ISC-Bugs #40205. I only have one view for "in"; the reason I am using views is to make chaos bind queries work for specific client IPs only. I don't want to waste a bunch of memory doing that if I don't have to - so I put in the shared cache option. Taking it out means I have to go back and do my sums again to work out what max cache sizes and number of clients to specify. Thanks, Maria ___ 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
why one shouldn't use relative hostnames
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. Thanks! Maria ___ 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
Thank you both and Kevin I for one would really appreciate if you would compose that web page and put it out there! On Nov 11, 2010, at 8:40 AM, Stacey Jonathan Marshall wrote: Additionally a wildcard record in one of the the searched domains would cause a false positive to be returned causing an outage to the service/services. And if your not in control of the zone or the search order it could be difficult to rectify. -Stacey On 11/11/2010 00:30, Kevin Darcy wrote: 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 ___ 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
looking for reference to correct behavior
My apologies if this is considered to be too off-topic. I have a situation where my company uses a number of servers with a commercial DNS implementation (in addition to our BIND servers). The other implementation is Windows DNS, and there is some behavior that I do not think is acceptable, but which the vendor claims is acceptable behavior. I really want them to fix this bug (as I consider it), but first I need to get general agreement that it is a bug. I will be looking through the RFCs as much as I can time for, but haven't found what I need yet. Since my next meeting with the vendor is tomorrow, I thought I would also ask if anyone can already point me to a relevant RFC or other reference. Here is the behavior that I think is not acceptable. We have configured a zone on the windows server - dmz.example.com. This zone contains an A record for foo.dmz.example.com with IP address 10.240.240.240. The zone example.com is hosted elsewhere and contains a CNAME record foo.example.com pointing to foo.dmz.example.com. If the cache has just been cleared, and a client asks the WIndows DNS server for foo.example.com, it has a forwarding server to which it forwards the request. The forwarding server hands it back the CNAME record but it also hands back an A record for foo.dmz.example.com pointing to an incorrect IP address 192.168.240.240. The Windows DNS server accepts this A record for foo.dmz.example.com with an incorrect IP address into its cache, and hands out that incorrect information to the client. Even though it concurrently has dmz.gannett.com configured on it as a primary zone with a record for that same owner name pointing to a different IP address. I believe it shouldn't do that. Since it hosts dmz.example.com as a primary zone, I think it should discard that bad A record and hand back its own. The vendor's argument is that it should blindly trust the forwarding resolver. Can anyone point me to an RFC or reference about this? Thanks, Maria ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: looking for reference to correct behavior
By saying things like "We load the authoritative data into memory so that is also cached data" and other nonsense the vendor is stating that this behavior is in compliance with the RFCs and refusing to fix their code. Very frustrating, as I believe this behavior is clearly wrong and also seems to me to be a security issue. Thanks for your help anyway! Maria On May 11, 2009, at 2:33 PM, Kevin Darcy wrote: The "resolver algorithm" in RFC 1034, Section 5.3.3, states 1. See if the answer is in local information, and if so return it to the client. and is further detailed as 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. 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. If the resolver has direct access to a name server's zones, it should check to see if the desired data is present in authoritative form, and if so, use the authoritative data in preference to cached data. This would be a case where the resolver "has direct access to the name server's zones", so there is no debate, in my opinion, that the resolver in question is doing The Wrong Thing. RFC 2181 also makes it clear that authoritative data ranks higher than cached data, so that could also be used as a relevant normative reference. - Kevin Maria Iano wrote: My apologies if this is considered to be too off-topic. I have a situation where my company uses a number of servers with a commercial DNS implementation (in addition to our BIND servers). The other implementation is Windows DNS, and there is some behavior that I do not think is acceptable, but which the vendor claims is acceptable behavior. I really want them to fix this bug (as I consider it), but first I need to get general agreement that it is a bug. I will be looking through the RFCs as much as I can time for, but haven't found what I need yet. Since my next meeting with the vendor is tomorrow, I thought I would also ask if anyone can already point me to a relevant RFC or other reference. Here is the behavior that I think is not acceptable. We have configured a zone on the windows server - dmz.example.com. This zone contains an A record for foo.dmz.example.com with IP address 10.240.240.240. The zone example.com is hosted elsewhere and contains a CNAME record foo.example.com pointing to foo.dmz.example.com. If the cache has just been cleared, and a client asks the WIndows DNS server for foo.example.com, it has a forwarding server to which it forwards the request. The forwarding server hands it back the CNAME record but it also hands back an A record for foo.dmz.example.com pointing to an incorrect IP address 192.168.240.240. The Windows DNS server accepts this A record for foo.dmz.example.com with an incorrect IP address into its cache, and hands out that incorrect information to the client. Even though it concurrently has dmz.gannett.com configured on it as a primary zone with a record for that same owner name pointing to a different IP address. I believe it shouldn't do that. Since it hosts dmz.example.com as a primary zone, I think it should discard that bad A record and hand back its own. The vendor's argument is that it should blindly trust the forwarding resolver. Can anyone point me to an RFC or reference about this? Thanks, Maria ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
do I have this wrong?
If I should not be sending this to this list please let me know. Please let me know if you think I have this wrong: Bare Minimum to be considered a usable DNS server (under limited conditions): When a zone is configured locally as a master or slave zone, only hand out data from the local configuration. Do not accept records in that zone into the cache that come from another server. Never hand out data in that zone received from another server. Desired Behavior to be considered a good working DNS server: In addition to the above: When a zone is configured locally as a stub zone, only accept into cache records in that zone from the zone's name servers as configured in the stub zone. Never hand out data from that zone unless it was received from one of the zone's name servers. When a zone is configured locally as a forward zone, only accept records in that zone into the cache that come from the servers to which the zone was specified to be forwarded. Never hand out data from that zone unless it was received from one of the forwarders. Thanks, Maria ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
wildcard not working after record deleted
We have a group of users that need to use a wildcard record in their zone. Their wildcard works in general, but they have a situation where it isn't working. They had some records that they deleted, and expected the wildcard to take over, but it hasn't. If we query a record that doesn't exist and never has in the zone, then we get the answer from the wildcard. If we query a record that used to exist but was deleted and now doesn't exist, then we get no answer. We don't get NXDOMAIN, we get status: NOERROR and no answer. Has anyone else come across this? Thanks, Maria ___ 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: wildcard not working after record deleted
On Mon, Jun 19, 2017 at 09:08:33PM -0500, /dev/rob0 wrote: > On Mon, Jun 19, 2017 at 06:19:31PM -0400, Maria Iano wrote: > > We have a group of users that need to use a wildcard record in > > their zone. Their wildcard works in general, but they have a > > situation where it isn't working. They had some records that they > > deleted, and expected the wildcard to take over, but it hasn't. If > > we query a record that doesn't exist and never has in the zone, > > then we get the answer from the wildcard. If we query a record that > > used to exist but was deleted and now doesn't exist, then we get no > > answer. We don't get NXDOMAIN, we get > > NXDOMAIN means there is no data of any type for the queried owner > name. > > > status: NOERROR > > > > and no answer. > > NOERROR means the query completed successfully, with no error. It > might mean in your case that there is other data with that owner > name, but no RRset of the requested type. > > IOW, when you have a TXT and A record with the same owner: > > sample7200IN A 192.0.2.53 > sample7200IN TXT "This is a sample." > * 7200IN A 192.0.2.101 > > If you delete the A record, the TXT is still there, and your wildcard > A record in the zone would not be used for that name. > > > Has anyone else come across this? > > That's the best guess I can come up with without seeing the query and > the zone data. If you need more help you will have to share that > information. Thanks for your answer. There are no other records with that name in the zone, and an ANY query comes back empty but still with status of NOERROR. Unfortunately, I can't provide the query and zone data, and I do understand that prevents you from helping. I was hoping someone else had come across this at some point. Thanks again, Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 10:02:04AM -0400, wbr...@e1b.org wrote: > > Thanks for your answer. There are no other records with that name in the > > zone, and an ANY query comes back empty but still with status of > > NOERROR. Unfortunately, I can't provide the query and zone data, and I > > do understand that prevents you from helping. > > Not even an SOA record? > There is an SOA record under the AUTHORITY SECTION. There is no ANSWER SECTION. Here is what comes back from a dig command, and I apologize for having to remove the names: ; <<>> DiG 9.10.2-P3 <<>> @ any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19780 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ; IN ANY ;; AUTHORITY SECTION: 300 IN SOA 2017062002 1200 600 604800 300 ;; Query time: 59 msec ;; SERVER: ;; WHEN: Tue Jun 20 10:14:58 EDT 2017 ;; MSG SIZE rcvd: 108 That is the entire output from the dig command! Thanks, Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:29:59AM -0500, /dev/rob0 wrote: > On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > > Thanks for your answer. There are no other records with that name > > in the zone, and an ANY query comes back empty but still with > > status of NOERROR. Unfortunately, I can't provide the query and > > zone data, and I do understand that prevents you from helping. > > > > I was hoping someone else had come across this at some point. > > I can continue to waste our time with guesses, however. :) > I really appreciate that! :) > Have you tried directed queries to an authoritative nameserver? > Today's guess is that you might be seeing some kind of caching issue. > A directed query like this: > > $ dig sample.example.com. any @ > > should return the wildcard if all records at "sample.example.com" > have been removed. The queries are being directed at an authoritative server, exactly as you describe above. This issue applies to some records that were deleted on June 18th. I can't recreate it. I have deleted other records and found that the wildcard immediately takes over. As far as I can tell this only applies to the particular set of records deleted on the 18th. I'm told they were deleted in the same way we always do. We also pay for a secondary dns provider who pulls our zones from the same authoritative servers of ours which have this issue. The wildcard works when we send the query to one of our secondary provider's name servers. Here is the answer from one of the secondary provider's servers: ; <<>> DiG 9.10.2-P3 <<>> @ any ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13930 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ; IN ANY ;; ANSWER SECTION: 300 IN CNAME ;; Query time: 29 msec ;; SERVER: ;; WHEN: Tue Jun 20 10:40:18 EDT 2017 ;; MSG SIZE rcvd: 82 > > If in fact you were querying a caching resolver, is that BIND? Is > the authoritative nameserver BIND? Our servers are running bind. Thanks, Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:37:04AM -0500, /dev/rob0 wrote: > On Tue, Jun 20, 2017 at 09:29:59AM -0500, /dev/rob0 wrote: > > On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > > > Thanks for your answer. There are no other records with that name > > > in the zone, and an ANY query comes back empty but still with > > > status of NOERROR. Unfortunately, I can't provide the query and > > > zone data, and I do understand that prevents you from helping. > > > > > > I was hoping someone else had come across this at some point. > > > > I can continue to waste our time with guesses, however. :) > > > > Have you tried directed queries to an authoritative nameserver? > > Today's guess is that you might be seeing some kind of caching > > issue. > > Today's guess retracted, I just saw your followup. :) > > > Is the authoritative nameserver BIND? > > If so, what version? You might need to file a bug report (and as of > now the bug database is entirely private; that will be changing soon, > but if you ask them, ISC will keep your bug report private.) > Good to know, we may go ahead and file a report if we can't figure this out. Thanks! Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 10:08:44AM -0500, Bryan Bradsby wrote: > On Tue, 2017-06-20 at 10:51 -0400, Maria Iano wrote: > > > > The queries are being directed at an authoritative server, exactly as > > you describe above. > > > > We also pay for a secondary dns provider who pulls our zones from the > > same authoritative servers of ours which have this issue. > > The wildcard works when we send the query to one of our secondary > > provider's name servers. > > > > Here is the answer from one of the secondary provider's servers: > > > > ; <<>> DiG 9.10.2-P3 <<>> @ any > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ; IN ANY > > > > ;; ANSWER SECTION: > > 300 IN CNAME > > BIND does not allow a CNAME at the apex of the zone, some other flavors > of DNS servers allow this. At first I was really hopeful that we had our explanation, but then I realized you are talking about a CNAME for the zone itself, which we don't have. I think this was a misunderstanding because of my sloppy editing of the dig results. Replacing our zone name with example.com, our wildcard record looks like this: *.example.com. 300 IN CNAME name.cname.points.to. Here are the results of a dig query for a record that was deleted, and a dig query for a record that never existed, this time with the names again replaced (sorry) with something more helpful. $ dig @ns1.domain.com. deletedname.example.com. any ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.12 <<>> @ns1.domain.com. deletedname.example.com. any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4107 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;deletedname.example.com. IN ANY ;; AUTHORITY SECTION: example.com.300 IN SOA ns1.domain.com. dnsadmin.example.com. 2017062002 1200 600 604800 300 ;; Query time: 6 msec ;; SERVER: IPofns1#53(IPofns1) ;; WHEN: Tue Jun 20 11:27:17 2017 ;; MSG SIZE rcvd: 96 $ dig @ns1.domain.com. nonexistentname.example.com. any ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.12 <<>> @ns1.domain.com. nonexistentname.example.com. any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8568 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 16, ADDITIONAL: 4 ;; QUESTION SECTION: ;nonexistentname.example.com. IN ANY ;; ANSWER SECTION: nonexistentname.example.com.300 IN CNAME name.cname.points.to. ;; AUTHORITY SECTION: list of all of our NS records ;; ADDITIONAL SECTION: list of IPs of our name servers ;; Query time: 1 msec ;; SERVER: IPofns1#53(IPofns1) ;; WHEN: Tue Jun 20 11:27:26 2017 ;; MSG SIZE rcvd: 462 > > Was the wildcard changed to a CNAME in the last edit? > I just checked, and the wildcard record hasn't been changed since 2015. Thanks, Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 05:39:46PM +0200, Matus UHLAR - fantomas wrote: > > note that existande of "something.sample" subdomain also means that > "sample" exists and is empty. > That's it! They have www.deletedrecord in the zone! I missed it because I was searching for deletedrecord* and not *.deletedrecord*. It didn't help that both of our secondary dns providers do hand back the wildcard answer to the query. I take it that means they are not using bind, and their implementations follow different rules for wildcards. Thank you all for your time! Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 12:22:42PM -0400, wbr...@e1b.org wrote: > Can you post a copy of the zone file, changing any server names that > absolutely must be obscure? > Thank you for your help with this, and you are right, if I had sent you the edited zone file that would have revealed the cause - i.e. the subdomain records of the deleted records. I had searched for records beginning with the deleted names, and not records that were subdomains of the deleted names. Also, our secondary DNS providers hand out the wildcard record even though the subdomain records exist. Thanks! Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 11:29:27PM +0100, Cathy Almond wrote: > On 20/06/2017 14:17, Maria Iano wrote: > > As has been explained already, no answer, no error means that the name > exists, but not an RRset of the type you queried for. > > Since the ANY query also comes back empty, you've probably got a > situation something like this in the zone: > > sample7200IN A 192.0.2.53 > child.sample 7200IN A 192.0.2.54 > * 7200IN A 192.0.2.101 > > If you delete the 'sample' RR, the wildcard will still not match any > queries for sample. This is because the existence of 'child.sample' > means that 'sample' also exists, even though it has no RRsets of any type. > > 'sample' in this case is what's called an 'Empty Non-Terminal'. > > Does this scenario explain what you are seeing? > > Cathy Yes it does, that is exactly what was happening and we are in good shape now. I was able to explain to the users and they plan to delete the child records. I did recommend to them that they not use wildcard records, but they continue to need them. Thank you for the detailed explanation! Maria ___ 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
Bind-9.5.0-P2
Hello Y have a problem with bind, part of file mesagges is: Jun 25 12:50:25 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:26 amon last message repeated 112 times Jun 25 12:50:26 amon named[13443]: client 200.72.65.45#40268: recursive-clients soft limit exceeded, aborting oldest query Jun 25 12:50:26 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:27 amon last message repeated 61 times Jun 25 12:50:27 amon named[13443]: client 206.127.153.68#32705: query (cache) './A/IN' denied Jun 25 12:50:28 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:33 amon last message repeated 357 times Jun 25 12:50:33 amon named[13443]: client 206.127.153.68#34224: query (cache) './A/IN' denied Jun 25 12:50:33 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:36 amon last message repeated 347 times Jun 25 12:50:36 amon named[13443]: client 200.72.45.107#10504: recursive-clients soft limit exceeded, aborting oldest query Jun 25 12:50:36 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:36 amon last message repeated 75 times Jun 25 12:50:37 amon named[13443]: client 200.111.174.66#63637: recursive-clients soft limit exceeded, aborting oldest query Jun 25 12:50:37 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:37 amon last message repeated 16 times Jun 25 12:50:38 amon named[13443]: client 74.220.97.130#39006: query (cache) './NS/IN' denied Jun 25 12:50:38 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:38 amon last message repeated 82 times Jun 25 12:50:38 amon named[13443]: client 74.220.97.130#39006: query (cache) './NS/IN' denied Jun 25 12:50:38 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:39 amon last message repeated 95 times Jun 25 12:50:39 amon named[13443]: client 164.77.239.164#57193: recursive-clients soft limit exceeded, aborting oldest query Jun 25 12:50:39 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:39 amon last message repeated 5 times Jun 25 12:50:39 amon named[13443]: client 206.127.153.68#35730: query (cache) './A/IN' denied Jun 25 12:50:39 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:39 amon last message repeated 20 times Jun 25 12:50:39 amon named[13443]: client 74.220.97.130#39006: query (cache) './NS/IN' denied Jun 25 12:50:39 amon named[13443]: socket: too many open file descriptors Jun 25 12:50:41 amon last message repeated 179 times Jun 25 12:50:43 amon named[13443]: client 200.111.12.170#63932: recursive-clients soft limit exceeded, aborting oldest query Jun 25 12:50:43 amon named[13443]: socket: too many open file descriptors -- Rndc status version: 9.5.0-P2 (entel DNS) number of zones: 20 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 1800/1900/2000 tcp clients: 2/100 server is up and running - [r...@amon sbin]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice(-e) 0 file size (blocks, -f) unlimited pending signals (-i) 128363 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 4096 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 max rt priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 128363 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Every day, to the same hour Please, help me Bye Se despide cordialmente Mª Cristina Del Solar N. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Bind-9.5.0-P2
Hi I have Red Hat Enterprise Linux Server release 5 (Tikanga) Se despide cordialmente Mª Cristina Del Solar N. Administración de Servicios Subgerencia de Adm. de Sistemas Gerencia Operaciones TI ENTEL S.A. Teléfono: 3606309 E-mail: mdelso...@entel.cl -Original Message- From: JINMEI Tatuya / [mailto:jin...@isc.org] Sent: Jueves, 25 de Junio de 2009 18:27 To: Del Solar Navarrete Maria Cristina Cc: bind-users@lists.isc.org Subject: Re: Bind-9.5.0-P2 At Thu, 25 Jun 2009 13:05:27 -0400, Del Solar Navarrete Maria Cristina wrote: > Y have a problem with bind, part of file mesagges is: Please use 9.5.1. 9.5.0-P2 is an emergency security fix version with limitation on performance/scalability. It should still work (or have worked) for most people, but cannot work in a highly busy environment. The log and status output seem to indicate your operational environment is such a busy one. (BTW: how 9.5.1 is effective also depends on your OS. Which OS are you using?) --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
