Re: Dig Hangs during axfr request when not on localhost.
On Fri, 2019-06-14 at 10:05 +, John Horne wrote: > On Fri, 2019-06-14 at 08:53 +0100, Pete Fry via bind-users wrote: > > Hi > > > > versions: > > BIND 9.9.4-RedHat-9.9.4-74.el7_6.1 (Extended Support Version) > > CentOS Linux release 7.6.1810 (Core) > > > > We are having a problem on our masters that have large zone files (around > > 5MB) are failing to be loaded on our slaves. > > > > after some investigation > > > > we can perform the following commands whilst local on the master > > > > dig @localhost ZONE axfr > > > > and the command performs and exits successfully > > > > however if you fun dig @IP.OF.MASTER ZONE axfr from a machine on the same > > subnet the zone starts to transfer and then hangs at certain points around > > 150k bytes give or take and fails to complete. > > > Hello, > > We have had the same problem on CentOS 7 servers after a recent bind yum > update. For the moment we have downgraded BIND back to > bind-9.9.4-73.el7_6.x86_64 and the zone transfers are working again. > Hi, Looking a bit further into this, as far as I can tell the only difference between version '9.9.4-73' and '9.9.4-74' is a fix for CVE-2018-5743 which relates to TCP clients. It's a bit confusing as we do set a limit for the TCP clients to 250. However, the server sending the zone and the client requesting it are both lightly loaded, and rndc shows that we are nowhere near the TCP limit on either server. Also confusing, for me at least, is that we do log zone transfers, but usually at a channel severity of 'info'. I changed this to dynamic, and controlled the debug level using rndc. If I set the debug level to 9 then the transfer works. Anything less than 9 and it fails. It seems that the TCP connection is being lost for some reason, as the log file (at a low debug level) shows the AXFR starting a few times. Each start corresponds to when the transfer seems to hang. On the client side it shows the connection as having timed out. John. -- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form. ___ 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 Hangs during axfr request when not on localhost.
On Fri, 2019-06-14 at 08:53 +0100, Pete Fry via bind-users wrote: > Hi > > versions: > BIND 9.9.4-RedHat-9.9.4-74.el7_6.1 (Extended Support Version) > CentOS Linux release 7.6.1810 (Core) > > We are having a problem on our masters that have large zone files (around > 5MB) are failing to be loaded on our slaves. > > after some investigation > > we can perform the following commands whilst local on the master > > dig @localhost ZONE axfr > > and the command performs and exits successfully > > however if you fun dig @IP.OF.MASTER ZONE axfr from a machine on the same > subnet the zone starts to transfer and then hangs at certain points around > 150k bytes give or take and fails to complete. > Hello, We have had the same problem on CentOS 7 servers after a recent bind yum update. For the moment we have downgraded BIND back to bind-9.9.4-73.el7_6.x86_64 and the zone transfers are working again. John. -- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form. ___ 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: How to get memory statistics?
On Thu, 2018-02-15 at 12:47 +, Tony Finch wrote: > John Horne wrote: > > > > Running BIND 9.9.4, we have set the 'memstatistics-file' option in our > > named config file. My understanding is that memory stats will be dumped to > > this file when named exits. However, no such file is created (having > > stopped and started named a few times). > > Did you also set `memstatistics yes` or start `named` with `-m record` ? > No I did not. I have to admit that during my 'googling' I didn't come across this option. I have now set the option, and the memory stats file is produced when named exits. Thanks for the reply, John. -- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, Plymouth University accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. Plymouth University does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form. ___ 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
How to get memory statistics?
Hello, Running BIND 9.9.4, we have set the 'memstatistics-file' option in our named config file. My understanding is that memory stats will be dumped to this file when named exits. However, no such file is created (having stopped and started named a few times). I have checked other named log files and the general server logs, and can find no error message or the like. So, my question is how do we get memory stats from named? Thanks, John. -- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, Plymouth University accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. Plymouth University does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form. ___ 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: Rate-limiting - working? How to test?
On 17/01/14 14:22, Rich Goodson wrote: > You need a rate-limit log stanza to see rate limiting information (rate limiting from IP address, no longer > limiting from IP address, etc), and the individual queries that are not responded to are logged either in > your querylog or query-errors (can’t remember which off the top of my head). > Yup, that was it :-) I had no 'query-errors' logging set up. I now see the queries being rate-limited (or they would be if I removed/changed the 'log-only' option.) Thanks, John. ___ 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
Rate-limiting - working? How to test?
Hello,
I have BIND 9.9.4 installed on a server, and have included in the global
options:
rate-limit { responses-per-second 5;
log-only yes;
};
However, if I run from a client:
for n in `seq 1 10`; do dig +short jhorne.csd.plymouth.ac.uk a
@141.163.66.138; done
I get 10 correct responses. The query log file on the server shows that
10 queries were received:
17-Jan-2014 13:20:43.662 client 141.163.66.139#55184
(jhorne.csd.plymouth.ac.uk): view plymouth-only: query:
jhorne.csd.plymouth.ac.uk IN A + (141.163.66.138)
(The other 9 log entries are the same, except for the milliseconds
increasing slightly.)
It's Friday afternoon, so I'm probably missing something obvious :-) I
cannot see why all the queries were responded to, I expected some
queries to timeout and something to be logged (none of the other bind
logs contain anything about rate limiting).
Thanks,
John.
___
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: Reverse address entries
On Tue, 2013-07-02 at 12:02 -0700, Eduardo Bonsi wrote: > On 7/2/13 9:35 AM, John Horne wrote: > > > > We were alerted to the problem because we got long delays (around 20 > > seconds) when accessing a site doing a reverse lookup. That service > > then, no doubt the same as with SMTP, then proceeded but without the > > reverse lookup answer. > > > > > I do occasionally have a very short delay between > the main "www.mydomain" and "mydomain" but the same delay never happened > with the other domains/websites I am running under the same ip address. > I guess I could reverse my main domain to my one and only static ip > address and my question would be: - Does that would affect the other > websites I am serving using the same ip address? Thanks everyone for > this wealth discussion! > If you are referring to my comment above about a 20 second delay, then I should point out that the delay was caused because the reverse zone name servers were inaccessible - access to them is blocked by our firewall. So the client name server would try each listed name server and have to wait for a timeout. On average this gave a 20 second delay. It was not caused because there were no reverse zone entries to lookup. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: Reverse address entries
On Tue, 2013-07-02 at 14:42 +0100, Sam Wilson wrote: > Can anyone here give examples of the types of various software that will > not operate without a PTR record? > Nope, and our entire reverse zone was externally inaccessible for many months! (See previous posts on the bind9-users list from me about the problem.) As far as we could tell no services blocked us because of a failed reverse lookup. In fact it was one of the reasons we didn't immediately spot the problem. We were alerted to the problem because we got long delays (around 20 seconds) when accessing a site doing a reverse lookup. That service then, no doubt the same as with SMTP, then proceeded but without the reverse lookup answer. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: Answers from cache or authority section?
On Tue, 2013-06-25 at 17:20 +0100, Phil Mayers wrote: > On 25/06/13 16:53, John Horne wrote: > > > servers. However, there is a whole load of muttering that Microsoft and > > AD won't like that; it's all integrated with each other; running the DNS > > zone on Linux servers will be a problem with the MS servers etc etc. > > I'm sure you know this, but just in case - that is FUD. > Yes, so I gather. Unfortunately because I deal with the Linux side of things, I don't carry much weight here at all when trying to point out that we can integrate the MS stuff with the Linux servers. > As long as you setup appropriate dynamic update ACLs, AD works fine with bind > DNS > servers. > That is my understanding, and I have been saying it for a very long time now. It may well be that our current problem, despite the fact it took someone external to point it out!, is enough to get our DNS correctly sorted out (with respect to visible/accessible name servers). > Happy to discuss this offline if it helps. > Okay, thanks. The guy who knows the most about our AD/Exchange setup is on hols for the week, but I'll let him know when he returns. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: Answers from cache or authority section?
On Tue, 2013-06-25 at 17:07 +0100, Steven Carr wrote: > On 25 June 2013 16:53, John Horne wrote: > > So what I now do not understand is why (at home) I can do several > > reverse lookups for different IP addresses, and they all give me an > > answer. Likewise if I do something like: > > > >dig -x 141.163.99.16 @8.8.8.8 > > > > I get a non-authoritative answer. If I repeat this for addresses > > 141.163.99.17, 18, 20 and so on I get answers. In all these cases > > shouldn't the first lookup work and subsequent ones fail? Using Google's > > name server, shouldn't it at some point have received the authoritative > > answer with the AUTHORITY section NS records and so be using those > > (internal) name servers for subsequent lookups? > > Using Google you will get unexpected results, not sure exactly what > caching engine they use but it doesn't work like most other caching > servers, they definitely do some jiggery pokery with the results > Ah, that is what I was wondering. Thanks. > I would suggest you install a local copy of BIND configured for > recursion and let it do the queries for you then you can also use rndc > to inspect the cache for yourself. > Yes, I did try that. Cleared the cache, then ran 'rndc dumpdb' after the first query, saved the file then ran it again after a second query. Unfortunately I couldn't see our internal servers being cached at all (which they should have been after the first query). At that point I thought I'd ask on the list. I'll repeat the testing to see if I can see what is going on. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: Answers from cache or authority section?
On Tue, 2013-06-25 at 10:46 -0400, Barry Margolin wrote: > > In addition, the authoritative answer may contain an Authority section. > These nameservers take precedence over the NS records from the > delegation -- the assumption is that the authoritative server knows its > domain's nameservers more reliably than the parent domain's servers. > Ah. This is the bit I did not know. Okay, so from a fresh cache the first reverse lookup will work its way down from the root and provide an authoritative answer. The AUTHORITY section NS records are cached. So for any subsequent reverse lookup (for a different IP address) the resolver will use the cached name servers. In our case these are internal and would give a timeout. So what I now do not understand is why (at home) I can do several reverse lookups for different IP addresses, and they all give me an answer. Likewise if I do something like: dig -x 141.163.99.16 @8.8.8.8 I get a non-authoritative answer. If I repeat this for addresses 141.163.99.17, 18, 20 and so on I get answers. In all these cases shouldn't the first lookup work and subsequent ones fail? Using Google's name server, shouldn't it at some point have received the authoritative answer with the AUTHORITY section NS records and so be using those (internal) name servers for subsequent lookups? > That seems to be where your problem is -- the NS records you're handing > out are not appropriate for public consumption. But they replace the NS > records coming from the delegation. You MUST fix this. Configuring views > would be a solution: > Unfortunately the internal servers are MS Windows name servers and they are the masters for our reverse zone. The two secondary servers 'dns0.plymouth.ac.uk' and 'dns1.plymouth.ac.uk' are Linux servers and are to be added to the list of authoritative NS records. This should be a short-term solution to our problem with the external company, but I have already stressed to management that this is not a long term solution and that the internal servers should be just that - internal. Ideal would be moving the reverse zone onto the Internet-facing Linux servers. However, there is a whole load of muttering that Microsoft and AD won't like that; it's all integrated with each other; running the DNS zone on Linux servers will be a problem with the MS servers etc etc. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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
Answers from cache or authority section?
Hello,
I am having a bit of trouble understanding what happens when, in this
instance, a DNS reverse lookup occurs. Our site has the class-C
141.163.0.0 address range. If I perform reverse lookups from inside or
outside our site, then they seem to work fine. However, we are currently
investigating a problem an external site has with reverse lookups of our
IP addresses.
If I run (externally):
dig 141.in-addr.arpa ns
then 6 NS records are returned. If I query any one of those using:
dig +norecurse 163.141.in-addr.arpa ns @tinnie.arin.net
(using 'tinnie' in this example) then I get our 4 NS records relating to
our local and remote name servers:
==
;; AUTHORITY SECTION:
163.141.in-addr.arpa. 172800 IN NS dns2.cis.strath.ac.uk.
163.141.in-addr.arpa. 172800 IN NS dns1.cis.strath.ac.uk.
163.141.in-addr.arpa. 172800 IN NS dns1.plymouth.ac.uk.
163.141.in-addr.arpa. 172800 IN NS dns0.plymouth.ac.uk.
==
There is no ANSWER section, but a referral to the servers listed in the
AUTHORITY section.
So, I assume that at this point the name server used by a resolver will
now cache those NS records. As such, any subsequent reverse lookup for a
141.163.x.x address should use one of the above cached name servers and
get an answer.
If, however, you run a general query for the NS records:
dig 163.141.in-addr.arpa ns
then you will get an ANSWER section which lists several of our 'ils'
servers:
==
;; ANSWER SECTION:
163.141.in-addr.arpa. 3600 IN NSils022.uopnet.plymouth.ac.uk.
163.141.in-addr.arpa. 3600 IN NSils001.uopnet.plymouth.ac.uk.
163.141.in-addr.arpa. 3600 IN NSils009.uopnet.plymouth.ac.uk.
(etc)
==
The problem is that all these servers are internal to our site. They
cannot be directly queried externally (you get a timeout).
The external site (after flushing the cache) performs a reverse lookup
and receives an answer. So working from the root down works. However,
any subsequent reverse lookup of our IP address range has their resolver
looking at the 'ils' servers mentioned above and not the local and
remote name servers (dns0, dns1 etc) seen in the reply from 'tinnie'.
So I think my question is what is the resolver doing? Does it use cached
NS records seen in the AUTHORITY section, or does it use NS records seen
in an ANSWER section? Or is it working its way down until it receives an
authoritative answer ('aa' flag set), and then query one of those name
servers? The 'aa' flag is only set if a query for the
163.141.in-addr.arpa NS records is directed to one of our local/remote
name servers listed in the AUTHORITY by 'trinnie'. It will list the
'ils' servers mentioned above. However, the question then is how come
our reverse lookups work at all - they do for me from home. If the
resolver was looking for an authoritative answer, and they are only
provided by our internal servers, then all the lookups should fail.
Comments? Corrections to where I have gone wrong?
I should point out that I have for a long time banged on at management
about the fact that our internal name servers are visible on the
Internet but cannot be accessed. This is bound to lead to problems. Does
anyone listen though...?
John.
--
John Horne, Plymouth University, UK
Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001
___
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: RPZ - how to modify NS records in answer?
On Fri, 2013-06-21 at 17:11 +0100, John Horne wrote: > > My understanding is that RPZ can do this, but I just cannot seem to > configure the RPZ zone file to enable this. The zone file contains: > = > $TTL 1H > @ SOA LOCALHOST. hostmaster.plymouth.ac.uk (1 1h > 15m 30d 2h) > NS LOCALHOST. > > dns1.plymouth.ac.uk.rpz-nsdomainCNAME *. > = > Hmm, I have just noticed that ARM says: == NSDNAME triggers match names of authoritative servers for the query name, a parent of the query name, a CNAME for query name, or a parent of a CNAME. They are encoded as subdomains of rpz-nsdomain relativized to the RPZ origin name. == But the example zone file further down the page has the example: ns.domain.com.rpz-nsdname CNAME . So is 'rpz-nsdomain' wrong then in the zone file and 'rpz-nsdname' should be used instead? If I modify my zone file above to use 'rpz-nsdname' then the 'dig' command gets a NXDOMAIN response. If I use '.' as the rdata I get a NOERROR response but no ANSWER section, just an AUTHORITY section with the RPZ zone SOA in it. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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
RPZ - how to modify NS records in answer?
Hello, Using BIND 9.9.3 I have been trying to do a little testing to see if we can modify the response for NS records. I have a test server which is a stealth secondary for our 'plymouth.ac.uk' zone. The name servers for the zone are 'dns0.plymouth.ac.uk' and 'dns1.plymouth.ac.uk'. So, 'dig plymouth.ac.uk ns' will show you the above two name servers in the answer section as NS records. (It will include our two remote secondaries as well.) What I wanted to try and do was cause the reply to not show 'dns1.plymouth.ac.uk' at all. So the reply to the above 'dig' command should answer with 'dns0.plymouth.ac.uk' and the two remote name servers. However, trying to get RPZ to do that is causing me a problem. My understanding is that RPZ can do this, but I just cannot seem to configure the RPZ zone file to enable this. The zone file contains: = $TTL 1H @ SOA LOCALHOST. hostmaster.plymouth.ac.uk (1 1h 15m 30d 2h) NS LOCALHOST. dns1.plymouth.ac.uk.rpz-nsdomainCNAME *. = However, the above seems to have no effect as the above 'dig' command still returns both 'dns0' and 'dns1'. Likewise using just '.' as the rdata made no difference. So, I'm wondering what the RPZ zone file should contain to enable an NS record to be omitted from the reply? Thanks, John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: 9.3.3 - SPF record checks
On Fri, 2013-05-31 at 06:53 +1000, Mark Andrews wrote: > In message <1369923655.1952.6.camel@jhorne.config>, John Horne writes: > > Hello, > > > > I noticed in the 9.3.3 announcement the following new SPF check: > > > >Adds a new configuration option, "check-spf"; valid values are > >"warn" (default) and "ignore". When set to "warn", checks SPF > >and TXT records in spf format, warning if either resource record > >type occurs without a corresponding record of the other resource > >record type. [RT #33355] > > > > I'm a bit curious about this because I thought that the SPF record type > > was being deprecated - section 3.1 of > > http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/?include_text=1 > > > > If it is being deprecated, then checking for an SPF record and finding > > no corresponding TXT record makes sense, but finding a TXT record and > > warning that there is no SPF record would seem a little pointless. > > The draft has *not* been ietf last called. > Yup, I realise that this is just a draft and that things may well change. > If the use of SPF for SPF is deprecated we will adjust the warning > but that has not happened yet. > Fair enough. > Current SPF libraries ask for SPF first then TXT so having a SPF > record reduces the query load. > I did not know that. Okay, so there is sense in adding the DNS SPF RR to a zone then. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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
9.3.3 - SPF record checks
Hello, I noticed in the 9.3.3 announcement the following new SPF check: Adds a new configuration option, "check-spf"; valid values are "warn" (default) and "ignore". When set to "warn", checks SPF and TXT records in spf format, warning if either resource record type occurs without a corresponding record of the other resource record type. [RT #33355] I'm a bit curious about this because I thought that the SPF record type was being deprecated - section 3.1 of http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/?include_text=1 If it is being deprecated, then checking for an SPF record and finding no corresponding TXT record makes sense, but finding a TXT record and warning that there is no SPF record would seem a little pointless. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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 view - differing SOA serial number
On Thu, 2010-07-08 at 23:02 -0400, Barry Margolin wrote: > > Are you sure both views are actually getting the notifies? You need the > master to send two notifies, each one satisfying the match-XXX criteria > of one of the views. > > If only one notify is sent, only the view that it matches will receive > it and perform the zone transfer. It doesn't matter that the other view > uses the same file -- files are only read when named reloads (when it > starts up or you do "rndc reload"). > Well we changed things by creating separate zone files for each view, but that made no difference to the original problem. However, you are absolutely right, the notifies were only being seen by one view (logging the notifies and transfers showed this). > The other view will eventually update when the SOA Refresh timer expires. > That is exactly what we saw. The SOA serial numbers were different, but every so often they would get 'closer' - this was when the refresh occurred. It has been a bit convoluted but we have the notifies working correctly now as well :-) The zones show the same SOA serial number regardless of whether inside the campus, outside, or at one of the remote secondaries, and they remain consistent after an update. Many thanks to people for the replies. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split view - differing SOA serial number
On Thu, 2010-07-08 at 07:34 -0400, Alan Clegg wrote: > On 7/8/2010 7:26 AM, John Horne wrote: > > > However, when checking the SOA serial number of our reverse zone we are > > seeing different values depending on whether we are inside or outside of > > the campus. This zone is maintained internally by MS Windows servers, > > and so our main servers (141.163.1.250 and 141.163.177.1) act as slaves. > > [..] > > > Both views use the same zone file (which currently contains 3330257 as > > the serial number), and the zone is configured to use a single master. > > If I use rndc to reload the zone in both views, then nothing changes. If > > I stop and restart the whole named service, then both views have the > > same serial number. Why doesn't a reload cause the zone serial number to > > be updated from the file copy of the zone? > > You need to specify different "file" locations for each of the slaved > zones (even if the data is the same) in each view. > Does that apply for master zones which are common (i.e. the same data) to both views as well? John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split view - differing SOA serial number
On Thu, 2010-07-08 at 13:37 +0200, Matus UHLAR - fantomas wrote: > > I think you can for example configure one view as slave of the other view, > with > sending notifies from master to slave and using no zone file for the slave > part. > Interesting idea. I will look into that. Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split view - differing SOA serial number
On Thu, 2010-07-08 at 07:34 -0400, Alan Clegg wrote: > On 7/8/2010 7:26 AM, John Horne wrote: > > > However, when checking the SOA serial number of our reverse zone we are > > seeing different values depending on whether we are inside or outside of > > the campus. This zone is maintained internally by MS Windows servers, > > and so our main servers (141.163.1.250 and 141.163.177.1) act as slaves. > > [..] > > > Both views use the same zone file (which currently contains 3330257 as > > the serial number), and the zone is configured to use a single master. > > If I use rndc to reload the zone in both views, then nothing changes. If > > I stop and restart the whole named service, then both views have the > > same serial number. Why doesn't a reload cause the zone serial number to > > be updated from the file copy of the zone? > > You need to specify different "file" locations for each of the slaved > zones (even if the data is the same) in each view. > Okay, but why? As said this generally works, it just seems a bit out of step between the views. I say 'okay', but actually that means we are going to have to have twice as many zone files as before (no problem), but we are also going to have to almost double the configuration size if we have to individually define each slave zone in both views. John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Split view - differing SOA serial number
Hello, We are running BIND 9.7.0, and use a split view such that there is a difference depending on whether you are within our site campus or not. For all the other zones we support we simply 'include' the zone file into both views. Generally this seems to work fine. However, when checking the SOA serial number of our reverse zone we are seeing different values depending on whether we are inside or outside of the campus. This zone is maintained internally by MS Windows servers, and so our main servers (141.163.1.250 and 141.163.177.1) act as slaves. For example, at this moment: Inside: dig 163.141.in-addr.arpa. soa @141.163.1.250 +short ils009.uopnet.plymouth.ac.uk. admin.uopnet.plymouth.ac.uk. 3330257 3600 600 86400 3600 Outside: dig 163.141.in-addr.arpa. soa @141.163.1.250 +short ils009.uopnet.plymouth.ac.uk. admin.uopnet.plymouth.ac.uk. 3330251 3600 600 86400 3600 Both views use the same zone file (which currently contains 3330257 as the serial number), and the zone is configured to use a single master. If I use rndc to reload the zone in both views, then nothing changes. If I stop and restart the whole named service, then both views have the same serial number. Why doesn't a reload cause the zone serial number to be updated from the file copy of the zone? When the zone changes on the master, BIND receives a notify and I would expect that to trigger a transfer of the zone according to named.conf. I would then expect named to reload the zone for each view it appears in. As such since this zone is in both the internal and external views, I would expect the serial number to always be the same. I am a little confused as to where the difference is coming from. I assume I am missing something obvious!? Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split view logging?
On Thu, 2009-11-19 at 14:55 -0800, Gregory Hicks wrote:
> > From: Chris Buxton
> > Date: Tue, 17 Nov 2009 08:16:18 -0800
> >
> > On Nov 17, 2009, at 7:02 AM, John Horne wrote:
> >
> > > Hello,
> > >
> > > Using BIND 9.5.1, is it possible to configure split view logging -
> > > that is, a separate logging channel/category for different views?
> > > I'm trying to separate out the queries of our local clients from
> > > the external ones.
> >
> > No, not using views. The logging statement, like the options
> > statement, is a singleton statement type.
> >
> > You would have to stand up separate instances of named, with separate
> > configs, to achieve your goal.
>
> Well, not exactly...
>
> I have two views: "trusted" (hosts on my internal LAN), and "external"
> (hosts external to my LAN). I want queries logged from my internal LAN
> to /var/log/named.trusted.{0-9} and all other queries to go to
> /var/log/named.external.{0-9}. I've also got some odd sods and trash
> going to other log files...
>
> First, create a 'pipe' in the /var/log directory with the name of the
> logging file. (You probably want to do this in the named startup
> script.) Log absolutely EVERYTHING to the log file.
>
Wow! Well thanks for that. I can see that your way would work, however I
was hoping for something a little simpler like putting logging stmts
into each view :-) (Perhaps BIND 10?)
Thanks for the reply,
John.
--
John Horne Tel: +44 (0)1752 587287
University of Plymouth, UK Fax: +44 (0)1752 587001
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Split view logging?
Hello, Using BIND 9.5.1, is it possible to configure split view logging - that is, a separate logging channel/category for different views? I'm trying to separate out the queries of our local clients from the external ones. Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nslookup not showng TTL
On Thu, 2009-10-15 at 13:15 -0400, Kevin Darcy wrote: > > > Removing features from nslookup gets us that much closer to KILLING and > BURYING it. Forever. > So why does the ISC still distribute it? (Although I guess the answer may simply be "because people still use it".) Don't get me wrong here - I've been using dig for years, and only use nslookup if I have to on my Windows laptop at work, on the Linux/UNIX systems dig is only used. If nslookup was no longer present in the BIND distribution then that doesn't bother me at all. John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nslookup not showng TTL
On Thu, 2009-10-15 at 10:47 +0200, Adam Tkac wrote: > On Thu, Oct 15, 2009 at 09:06:56AM +0100, John Horne wrote: > > > > How can I see the TTL value using nslookup? > > I'm not sure how force nslookup to show TTL but the `dig` utility is > far more better tool for getting such information: > I agree, it's not for me though :-) I have to teach some Windows people about the DNS, and wanted to show them that they could use 'nslookup' on either the Linux box provided, or their own Windows PC's. In this instance the TTL is important. So I was hoping that the MS and BIND nslookup commands would display something pretty much similar to each other so as not to confuse the people too much. As far as I can tell no BIND 9 nslookup command shows the TTL. I am currently looking at an 8.2.3 version to see if I can patch the 9.5.1 one to display TTL's again. It may, however, be better to introduce them to dig rather than having to maintain the nslookup command. John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Nslookup not showng TTL
Hello, Using BIND 9.5.1 it seems that the nslookup command is not showing the TTL value of found records. It makes no difference if I set 'debug' or 'd2'. Example: == nslookup > set debug > www.plymouth.ac.uk Server: 127.0.0.1 Address:127.0.0.1#53 QUESTIONS: www.plymouth.ac.uk, type = A, class = IN ANSWERS: -> www.plymouth.ac.uk canonical name = extranet.plymouth.ac.uk. -> extranet.plymouth.ac.uk internet address = 141.163.163.185 AUTHORITY RECORDS: -> plymouth.ac.uk nameserver = dns0.plymouth.ac.uk. -> plymouth.ac.uk nameserver = dns1.plymouth.ac.uk. ADDITIONAL RECORDS: -> dns0.plymouth.ac.uk internet address = 141.163.1.250 -> dns1.plymouth.ac.uk internet address = 141.163.177.1 www.plymouth.ac.uk canonical name = extranet.plymouth.ac.uk. Name: extranet.plymouth.ac.uk Address: 141.163.163.185 > == How can I see the TTL value using nslookup? Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem with bind book example
On Wed, 2009-09-23 at 15:17 -0700, Linda W wrote:
>
> In my main config it's in the section:
> root "." IN {
> type hint;
> file "root.hint";
> };
>
I don't have the BIND book to hand, but that should be:
zone "." IN {
John.
--
John Horne, University of Plymouth, UK
Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Invalid lan. and local. TLDs
On Sat, 2009-08-29 at 13:24 +1000, Mark Andrews wrote: > > Or one can just configure your recursive server as a stealth slave > of the root zone. You make a qery every hour or so and transfer > it twice a day. > I have been wondering how to do a transfer twice a day without having to write something (albeit it would probably be a simple shell script). I have been running a root zone transfer on my home PC today by using: min-refresh-time 14400; // 4 hours notify no; This seems to work well enough, but for some reason it has done transfers (or at least SOA checks) every 3 hours! I have run tcpdump on the network interface to the F root server all day, and hence it shows when the transfers have occurred. So, two things: 1) is this a bug, setting min-refresh-time to 4 hours and it running every 3 hours? 2) Is this a reasonable way to perform a root zone transfer twice a day? (Using a value of 12 hours obviously.) Although we may not have right up to the minute accuracy of the root zone, it would be at most 12 hours out of date, and the DNS locally would still work since the TLD's have multiple NS records (hence we wouldn't lose a TLD unless it had only one NS and that was changed). John. -- ------ John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Invalid lan. and local. TLDs
On Sat, 2009-08-29 at 13:24 +1000, Mark Andrews wrote: > In message , "Bill Larson" writes: > > John Horne said: > > > > > Hello, > > > > > > I noticed one of the root servers stats > > > ( http://stats.l.root-servers.org/cgi-bin/dsc-grapher.pl? > > window=604800&plot=qtype_vs_invalid_tld&server=L-root ) of queried invalid > > TLDs, as at the moment we have no 'local.' or 'lan.' zones configured. > > Hence, any such queries from us go out to the Internet (sorry). > > > > > > I gather that these zones are used by MS and MAC servers to some extent, > > > so I am wondering if it would be better to simply create an empty zone > > > or one with a wildcard in it? Or does it make any difference? (I have no > > > idea what the zones are used for.) > > > > Or one can just configure your recursive server as a stealth slave > of the root zone. You make a qery every hour or so and transfer > it twice a day. > Many thanks for this. An interesting solution! I notice that this very question came up in 2004 (https://lists.isc.org/pipermail/bind-users/2004-December/054202.html), and note the concerns about NOTIFY. I am first going to install dnstop to see exactly what is going on. Thanks, John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: john.ho...@plymouth.ac.uk Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Invalid lan. and local. TLDs
Hello, I noticed one of the root servers stats ( http://stats.l.root-servers.org/cgi-bin/dsc-grapher.pl?window=604800&plot=qtype_vs_invalid_tld&server=L-root ) of queried invalid TLDs, as at the moment we have no 'local.' or 'lan.' zones configured. Hence, any such queries from us go out to the Internet (sorry). I gather that these zones are used by MS and MAC servers to some extent, so I am wondering if it would be better to simply create an empty zone or one with a wildcard in it? Or does it make any difference? (I have no idea what the zones are used for.) Whilst we have already configured zones for private (RFC 1918) zones, and several other 'local' type forward and reverse zones, would it be worth creating zones for 'belkin.', 'invalid.' and so on? Is that something that others do? I came across the above web site of stats by accident, but can't seem to find stats from other root servers. Anyone know if there are other stats available? Thanks, John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: john.ho...@plymouth.ac.uk Fax: +44 (0)1752 587001 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
