Re: has no address records (A or AAAA)
Of course... Error code 18!!! Damn! On Thu, Jan 28, 2016 at 9:14 AM, Matus UHLAR - fantomas wrote: > On 28.01.16 08:58, Bernard Fay wrote: > >> When checking my reverse zone, I have the following error: >> >> named-checkzone cts.org 192.168.99.zone >> zone cts.org/IN: NS 'ns1.cts.org' has no address records (A or ) >> zone cts.org/IN: not loaded due to errors. >> > > you are trying to check zone "cts.org" in file "192.168.99.zone" that > contains the reverse zone, not zone cts.org. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Emacs is a complicated operating system without good text editor. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dns search list
Suffix searching is a client function, there is no explicit support for it in BIND or any nameserver implementation. The only incredibly ugly thing you could do in DNS to support shortname resolution is set up a "fake" root zone containing the names you need to resolve. But, you really don't want to go down that path. I consider it a responsibility of DNS admins to push back on any unreasonable shortname-resolution requests from their customers/end-users. There are *very* few things left in today's technology ecosystem that *require* shortname resolution. If it's just for _convenience_, then a management/political decision needs to be made, weighing the efficiency/scaling needs of the infrastructure, and the security/reliability risks of unexpected suffix matching, against the "convenience" arguments of those asking for shortname resolution. DHCP supplies a single domain suffix (option 15) which Windows clients can use for suffixing (but understand first the interactions between Connection-specific Suffix, Primary Domain Suffix and Suffix Search List). That should be sufficient for any residual shortname-resolution needs. Note that you don't *have* to give the same option 15 value to everything in the same DHCP scope. If you have a sufficiently-advanced DHCP server, you could tailor that value according to, say, the "user class" set by the client and reported via DHCP (see RFC 3004). It might be possible to tailor it based on other parameters too (e.g. vendor class, RFC 3925), or combinations of parameters. - Kevin From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Julie Xu Sent: Thursday, January 28, 2016 6:47 PM To: bind-users@lists.isc.org Subject: RE: dns search list Hi As I understand that dns search option 119 is not work with MS client. But, I do need make a dns search list to ask MS client search a dns list. Could anyone advice me except group policy, do I have anyway to achive this point by change something in bind? Any comments will be appreciated Thanks in advance Julie ___ 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: separation of authoritative and recursive functions on internal networks
Howdy Mark, Can you please clarify the best practice for this? > Recursive servers (honouring RD=1) however can be authoritative for zones. In this context of "authoritative", do you mean that they can be fully functional slaves and have a complete copy of the zone information? I would imagine you would still not want such recursive servers to be truly authoritative (e.g. listed in the NS records for the zones), correct? Thanks in advance, Mathew Eis Northern Arizona University Information Technology Services mathew@nau.edu (928) 523-2960 -Original Message- From: on behalf of Mark Andrews Date: Monday, August 10, 2015 at 11:12 AM To: Gary Carr Cc: "bind-us...@isc.org" Subject: Re: separation of authoritative and recursive functions on internal networks > >Authoritative servers (listed in NS records) shouldn't be recursive. >This prevents leakage of cache data. This provide consistent >answers. The server also doesn't have to decide what type of answer >to give (recursive vs authoritative). Glue doesn't get overridden >by answers, etc. > >Recurive servers (honouring RD=1) however can be authoritative for >zones. This proves robustness in the presence of link failures. >Faster than ttl expiry of local zone changes (provided that notify >messages are sent). > >Unfortunately this has become strict seperation lore which really >wasn't ever the intent. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >___ >Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >from this list > >bind-users mailing list >bind-users@lists.isc.org >https://lists.isc.org/mailman/listinfo/bind-users ___ 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: separation of authoritative and recursive functions on internal networks
Why not? Data obtained from the recursive function will never outrank authoritative data of a master or a slave. See the "Data Ranking" section of RFC 2181. AFAICT, it's been a *very* long time since BIND, or any other DNS implementation, has accidentally got those ranking rules wrong and given preference to cached data. The main theoretical concern about mixing recursive and published-authoritative functions on the same nameserver instance, would be that the recursive functions -- which tend to be rather variable and unpredictable -- might take up too much resources and thus interfere with the published-authoritative functions of the same instance. But that's actually a reason to have *more* NS records (to spread out the load, and to provide sufficient failover capability in case one node gets overloaded, at any particular time), not an argument to leave nodes *out* of the NS records. Diversity is a good thing, and nameserver-selection failover tends to be very quick. A better reason to limit the number of NS records is that, at a certain point, your Authoritative Section on DNS responses may -- if EDNS0 is not ubiquitous -- grow packet sizes to the point that they cause TCP retries. This is especially likely when slaving Active Directory zones, since AD's recommended practice is for *every* domain controller to run DNS, and the default behavior, at DC promotion time, is to register the DC in the NS records of the domain, if it's running DNS. A much less likely reason for limiting the NS records of a zone is if one wants to "shape" the traffic flows of queries and (potentially) Dynamic Updates, because, say, some links are a lot more expensive than others (by "expensive" I mean in an economic sense, not in terms of latency, since the nameserver-selection algorithm already takes latency into account). But, given that DNS traffic tends to be a small fraction of overall traffic, this concern is not likely to be a factor. RFC 2182 recommends 3 NSes per zone, but that RFC was written in 1997, and oriented towards Internet-facing nameservers, at a time when the Internet wasn't nearly as geographically-diverse as it is today. Around here, as a somewhat-large, geographically-diverse enterprise, we tend to have 8-ish NSes for our internal zones, plus or minus a few, depending on how "localized" the zone is. For the Internet-facing stuff, we have less NSes, but they're all VIPs of some kind, backed by multiple devices each. By implementing load-balancing, Anycast, or some combination of the two, it's possible to make a zone highly available without exploding the number of NS records published for it. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mathew Ian Eis Sent: Friday, January 29, 2016 5:56 PM To: Mark Andrews Cc: bind-us...@isc.org Subject: Re: separation of authoritative and recursive functions on internal networks Howdy Mark, Can you please clarify the best practice for this? > Recursive servers (honouring RD=1) however can be authoritative for zones. In this context of "authoritative", do you mean that they can be fully functional slaves and have a complete copy of the zone information? I would imagine you would still not want such recursive servers to be truly authoritative (e.g. listed in the NS records for the zones), correct? Thanks in advance, Mathew Eis Northern Arizona University Information Technology Services mathew@nau.edu (928) 523-2960 -Original Message- From: on behalf of Mark Andrews Date: Monday, August 10, 2015 at 11:12 AM To: Gary Carr Cc: "bind-us...@isc.org" Subject: Re: separation of authoritative and recursive functions on internal networks > >Authoritative servers (listed in NS records) shouldn't be recursive. >This prevents leakage of cache data. This provide consistent answers. >The server also doesn't have to decide what type of answer to give >(recursive vs authoritative). Glue doesn't get overridden by answers, >etc. > >Recurive servers (honouring RD=1) however can be authoritative for >zones. This proves robustness in the presence of link failures. >Faster than ttl expiry of local zone changes (provided that notify >messages are sent). > >Unfortunately this has become strict seperation lore which really >wasn't ever the intent. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >___ >Please visit https://lists.isc.org/mailman/listinfo/bind-users to >unsubscribe from this list > >bind-users mailing list >bind-users@lists.isc.org >https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-user
Re: Overriding a single record with dynamic-dns
On 01/21/2016 09:27 AM, gnafou wrote: I have a zone myzone.com where dynamic dns is active ( dhcp updates continuously the dns ) I need to respond differently for MX requests such as : MX for "internal" queries ismxinternal.myzone.com MX for "internet" queries is mxexternal.myzone.com I cannot find out how to setup bind to achieve this while keeping the dynamic dns in operation I would be tempted to try to have the authoritative server respond with external views and then conditionally alter the response with Response Policy Zone for internal clients. Depending on your configuration, this may work. -- Grant. . . . unix || die ___ 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: Overriding a single record with dynamic-dns
On 01/22/2016 01:03 AM, gnafou wrote: but, indeed i do need some of the dynamic dns data in the external view and yes, the mx is it the apex .. How dynamic? Are we talking DHCP for a LAN w/ AD joined clients? Or are we talking occasional updates for an external IP of a cable modem? Your answer makes me wonder if i should be playing with cname aliases and build a separate 'static' zone with two views As others pointed out, I don't think CNAMEs will work well. Does your MX record(s) need to point to a different name(s)? Or could you use one name and then just change where the name resolves to internally vs externally? -- Grant. . . . unix || die ___ 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: Using bind and ad blocking
On 01/23/2016 01:47 PM, Olliver Schinagl wrote: recently I updated to bind-9.10 and noticed that an illegal setup was finally disallowed. Good things, but I (and others I'm sure) kind of miss-used this ability. With the change however, I am now looking for help on restoring similar behavior. Let me explain. I'm doing something similar with static zones on recent versions of Bind. What specific error(s) are you getting? I would also suggest you take a look at Response Policy Zone, as I think it would be more efficient (less memory and faster) than loading potentially thousands of zones almost empty zones. As a bonus, you could dynamically add / update / remove records from the RPZ zone without needing to restart Bind. -- Grant. . . . unix || die ___ 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: frequent queries to root servers
On 01/26/2016 04:46 PM, Reindl Harald wrote: violating what? Chaining CNAMEs is a violation according to RFCs. It works, but it is unsupported, and you can only blame yourself when it doesn't. -- Grant. . . . unix || die ___ 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: Name resolution failure on a caching server -- many '; pending-answer' records in the cache
Thanks for the followup. > > NXDOMAIN is not a "failure" response. Are you *sure* you're getting NXDOMAIN? Yes. Pretty sure. With hindsight I should have run the tests inside a 'script' session. > If you're using nslookup to test, be aware that it will do suffix searching > by default, so if the original query, e.g. www.bbc.co.uk fails, it'll > quietly (unless debug-mode is in effect) start appending suffixes. Looking up > those suffixed names, e.g. www.bbc.co.uk.example.com, mostly likely gets an > NXDOMAIN, so nslookup reports NXDOMAIN as the overall result of the query. > So, it's basically a misreporting of the error by nslookup. Yes. I was mostly using nslookup. I'll try dig too next time this occurs. > > Note that only 1 of the records in your cache dump is actually relevant -- > the CNAME from www.bbc.co.uk to www.bbc.net.uk -- and the others are for a > different part of the namespaces (thdow.bbc.co.uk). I'll contact you privately with a link to the whole cache. Every entry tagged 'pending-*' in the cache which I tried querying failed to resolve when queried, many hours after the network congestion had ended. > > If you do an explicit query of the CNAME, when the problem is occurring, does > it resolve? I would expect, even though the cache entry is marked > "pending-answer", it will still resolve. But, without the target of the CNAME > also resolving, the lookup as a whole cannot succeed. I'll try that next time. Regards Tom. > > > - Kevin > > -Original Message- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > tpcb...@mklab.ph.rhul.ac.uk > Sent: Tuesday, January 26, 2016 8:02 PM > To: bind-users@lists.isc.org > Subject: Name resolution failure on a caching server -- many '; > pending-answer' records in the cache > > Dear All, > I run a caching server on a section of the departmental LAN. > Occasionally network congestion results in timeouts & name resolution > failures. Lookups performed on name servers outside my LAN section fail with > NXDOMAIN. Querying my name server for items not in its cache gets the same > result. > > My problem is that long after the congestion has subsided, queries to my name > server still result in NXDOMAIN failure. AFAICT this situation remains > indefinitely, until the cache is flushed 'rndc flush' or the bind restarted. > When it is in this state dumping the cache with 'rndc dumpdb' shows numerous > entries like this, > > > ; pending-additional > thdow.bbc.co.uk.76632 NS ns3.bbc.net.uk. > 76632 NS ns4.bbc.co.uk. > 76632 NS ns4.bbc.net.uk. > 76632 NS ns3.bbc.co.uk. > ; pending-answer > ns0.thdow.bbc.co.uk.2082\- ;-$NXRRSET > ; thdow.bbc.co.uk. SOA ns.bbc.co.uk. hostmaster.bbc.co.uk. 2015122100 1800 > 600 864000 86400 ; pending-answer > 76632 A 212.58.240.162 > ; pending-answer > www.bbc.co.uk. 30 CNAME www.bbc.net.uk. > ; glue > > > and attempts to lookup eg. www.bbc.co.uk result in NXDOMAIN. > > Browsing the documentation I noticed the parameter 'max-ncache-ttl' > which is unset in my named.conf and apparently defaults to 3hours. > However the problem persists long after 3hours has elapsed following > incidents of network congestion. > > I could setup a cronjob to check name resolution on external domains and > flush the cache when it fails? I am assuming there must be better solution! > Should I set max-ncache-ttl to something fairly short in my named.conf and > hope that the default value is for some reason actually > >> 3hours? > > BTW I there a way to dump out all the parameters from a running named > -- just to see all their values ? > > > Any ideas on how to solve or further diagnose the problem? > > Many thanks > Tom Crane > > System details: > OS:Scientific Linux CERN SLC release 6.7 (Carbon) [NB: SLC is a > derivative of RHEL] > BIND: bind-9.8.2-0.37.rc1.el6_7.5.x86_64 > > Ps. I originally posted in Usenet NG comp.protocols.dns.bind but got no > followups and then noticed all messages in that NG had this ML's fields > 'NNTP-Posting-Host: lists.isc.org' and 'X-Original-To: > bind-users@lists.isc.org' etc. in their headers. Is c.p.d.b actually a > moderated group now or exclusively tied to this ML via a mail2news gateway? > > -- > Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill, > Egham, Surrey, TW20 0EX, England. > Email: T dot Crane at rhul dot ac dot uk > > ___ > Please visit https://lists.isc.or
Re: Overriding a single record with dynamic-dns
On 2016-01-21 08:27, gnafou wrote: Hello I have a zone myzone.com where dynamic dns is active ( dhcp updates continuously the dns ) I need to respond differently for MX requests such as : MX for "internal" queries ismxinternal.myzone.com MX for "internet" queries is mxexternal.myzone.com I cannot find out how to setup bind to achieve this while keeping the dynamic dns in operation Maybe I'm missing something, but for this specific example, wouldn't it be simpler to use an MX of "magicmx.myzone.com.", and have magicmx.myzone.com. in a separate zone entirely, allowing you to use views for that that one zone? -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ 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: frequent queries to root servers
On 2016-01-29 18:45, Grant Taylor wrote: On 01/26/2016 04:46 PM, Reindl Harald wrote: violating what? Chaining CNAMEs is a violation according to RFCs. It works, but it is unsupported, and you can only blame yourself when it doesn't. Maybe I'm misremembering RFC 1034, but a CNAME chain only violates a "should", and later in that RFC it says that software "should not" fail to handle chains, so even if you take a "should" as gospel, the "should not" should be equally gospel, making CNAME chains supported (although not advised.) -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ 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
