EDNS and fallback
Hello, I am trying to understand EDNS queries and the fallback capabilities. BIND 9.9.6-P1. I have a particular scenario where two sites are connected via firewall links and UDP fragmentation is not allowed. The symptoms I am seeing is that a dig command sends out several queries with EDNS and bufsize of 4096. The server on the other side of this setup answers back with an answer sized at 3410, yet no packets reach back to the dig query. According to the Knowledgebase article linked below, I expected to see the client fallback to EDNS with a bufsize of 512 when it did not receive a reply. Am I wrong? I have also listed the part that concerns me. https://kb.isc.org/article/AA-01219/30/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html For currently (and recently) supported versions of BIND up to and including BIND 9.9, the fallback algorithm for a 'new' authoritative server operates as follows: Query with EDNS, advertising size 4096, DO (DNSSEC OK) bit set If no response, retry with EDNS, size 512, DO bit set Perhaps it has something to do with the meaning of 'new'? Thank you, Ralph F. Bischof, Jr. The opinions expressed within this communication are not necessarily those of NASA. ___ 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
Simple max-journal-size question
I just can't seem to find the answer to such a simple question (BIND9.9). I have a very active dynamic zone that now has an incredibly large journal file. I would like to use the max-journal-size parameter in the zone declaration to keep this from happening again. I understand that I can freeze the zone, delete the journal, and then thaw the zone. My question deals with when the parameter in the named.conf will take effect. Will an 'rndc reconfig' be sufficient, or must I stop/start named for the parameter to be read for the zone? Thanks in advance, RB ___ 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
ASSERT messages
Hello, We have ~125 servers. About 1330 Central yesterday, the named of 6 of these crashed in 2 hours time (not at the same time, but within two hours). Since then, there have been other asserts at the same machines and with several other machines (total of 11 now). There hves been no changes to the configuration, no updates to software or hardware, nothing to point as to why this started up all of a sudden. The assert message is below. Anyone know of why this may have started? Note Replaced server IP address with xxx.xxx.xxx.xxx BIND 9.8.5-P2 RHEL 5.10 10-Apr-2014 17:36:00.119 general: ../../../lib/dns/rbtdb.c:1150: REQUIRE(rbtdb-future_version == ((void *)0)) failed, back trace 10-Apr-2014 17:36:00.119 general: #0 0x413c1f in assertion_failed()+0x5f 10-Apr-2014 17:36:00.119 general: #1 0x64fbfa in isc_assertion_failed()+0xa 10-Apr-2014 17:36:00.119 general: zone ksc.nasa.gov/IN: refused notify from non-master: xxx.xxx.xxx.xxx#6675 10-Apr-2014 17:36:00.119 general: #2 0x4b6c9c in newversion()+0x4c 10-Apr-2014 17:36:00.119 general: #3 0x4467ea in update_action()+0x29a 10-Apr-2014 17:36:00.119 general: #4 0x66e08c in run()+0x2dc 10-Apr-2014 17:36:00.119 general: #5 0x2b00f98a483d in _fini()+0x2b00f92221d5 10-Apr-2014 17:36:00.119 general: #6 0x2b00fa36526d in _fini()+0x2b00f9ce2c05 10-Apr-2014 17:36:00.119 general: exiting (due to assertion failure) Thank you, Ralph F. Bischof, Jr. NASA Agency DDI SAIC/NICS 256-544-3982 ___ 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: Inline Signing does not update SOA?
-Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Monday, May 07, 2012 4:54 PM To: Bischof, Ralph F. (MSFC-IS40)[NICS] Cc: bind-users@lists.isc.org Subject: Re: Inline Signing does not update SOA? In message a605629600c9a347b5881ffe16f101fb3d82823...@ndmsscc07.ndc.nasa.g ov, Bischof, Ralph F. (MSFC-IS40) [NICS] writes: Hi, I am testing with BIND 9.9.0 and inline signing. I have run upon something that I cannot figure out. W hen I update the SOA record of the master zone file, if I reload the zone with rndc reload, the SOA record is updated. If I perform a stop/start of the named executable, the SOA change is not updated. I can even se e in the log file where the unsigned zone's serial number is incremented, yet the signed version does not ch ange. Below you can see where I started named, stopped named, made a change in the SOA and incremented the s erial number, then started named. After that, I incremented the serial number once more then performed an r ndc reload. If you only changed the SOA serial then this is expected behaviour. The unsigned zone's serial is less than the signed zone's serial. Named works out what has changed in the unsigned zone apart from the serial and applies that to the signed zone. That said I can see a bug where changes only to the SOA other than the serial will be ignored. I did not explain myself well. I am making changes to other parameters in the SOA besides the serial number (MNAME, Email, Retry TTL, etc). It does appear as if the changes are being ignored. Per guidance of Evan Hunt, opened Bug #29271. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 ___ 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
Inline Signing does not update SOA?
Hi, I am testing with BIND 9.9.0 and inline signing. I have run upon something that I cannot figure out. When I update the SOA record of the master zone file, if I reload the zone with rndc reload, the SOA record is updated. If I perform a stop/start of the named executable, the SOA change is not updated. I can even see in the log file where the unsigned zone's serial number is incremented, yet the signed version does not change. Below you can see where I started named, stopped named, made a change in the SOA and incremented the serial number, then started named. After that, I incremented the serial number once more then performed an rndc reload. (Started named) 07-May-2012 08:00:00.664 general: managed-keys-zone: loaded serial 0 07-May-2012 08:00:00.664 general: zone 0.0.127.in-addr.arpa/IN: loaded serial 1 07-May-2012 08:00:00.683 general: zone nasa.gov/IN (unsigned): loaded serial 200804540 07-May-2012 08:00:00.704 general: zone nasa.gov/IN (signed): loaded serial 200804885 (DNSSEC signed) 07-May-2012 08:00:00.705 general: zone localhost/IN: loaded serial 1 07-May-2012 08:00:00.705 general: all zones loaded 07-May-2012 08:00:00.705 general: running 07-May-2012 08:00:00.719 general: zone nasa.gov/IN (signed): receive_secure_serial: unchanged 07-May-2012 08:00:00.719 general: zone nasa.gov/IN (signed): reconfiguring zone keys 07-May-2012 08:00:00.720 general: zone nasa.gov/IN (signed): next key event: 07-May-2012 09:00:00.719 (Stopped named and edited zone file 'nasa.gov') 07-May-2012 08:01:14.057 general: shutting down 07-May-2012 08:01:14.058 general: stopping command channel on 0.0.0.0#953 07-May-2012 08:01:14.064 general: exiting (Started named) 07-May-2012 08:01:49.998 general: managed-keys-zone: loaded serial 0 07-May-2012 08:01:49.999 general: zone 0.0.127.in-addr.arpa/IN: loaded serial 1 07-May-2012 08:01:50.017 general: zone nasa.gov/IN (unsigned): loaded serial 200804541 07-May-2012 08:01:50.039 general: zone nasa.gov/IN (signed): loaded serial 200804885 (DNSSEC signed) 07-May-2012 08:01:50.039 general: zone localhost/IN: loaded serial 1 07-May-2012 08:01:50.040 general: all zones loaded 07-May-2012 08:01:50.040 general: running 07-May-2012 08:01:50.053 general: zone nasa.gov/IN (signed): receive_secure_serial: unchanged 07-May-2012 08:01:50.059 general: zone nasa.gov/IN (signed): reconfiguring zone keys 07-May-2012 08:01:50.060 general: zone nasa.gov/IN (signed): next key event: 07-May-2012 09:01:50.059 (Performed rndc reload) 07-May-2012 08:02:59.553 general: received control channel command 'reload nasa.gov' 07-May-2012 08:02:59.611 general: zone nasa.gov/IN (unsigned): loaded serial 200804542 07-May-2012 08:02:59.612 general: zone nasa.gov/IN (signed): serial 200804886 (unsigned 200804542) Am I doing something wrong? Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 ___ 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: Inline Signing does not update SOA?
Hi Evan, -Original Message- From: Evan Hunt [mailto:e...@isc.org] Sent: Monday, May 07, 2012 12:44 PM To: Spain, Dr. Jeffry A. Cc: Bischof, Ralph F. (MSFC-IS40)[NICS]; bind-users@lists.isc.org Subject: Re: Inline Signing does not update SOA? Ralph: There was a lot of discussion about this issue on the bind forum around the first of the year. My recollection is that with inline-signing enabled, stopping named, editing the zone file, and restarting named isn't a supported method of updating zone data. That was unsupported in the first alpha release of the feature, but it should work now as long as the SOA serial is updated. I am using the released version from ISC. I always update the serial number of the unsigned zone (as I show in the original message). Is there something else that I may be doing wrong? The reason this is important to me is that the application that we use for IPAM/DNS/DHCP utilizes BIND and performs a stop/start to load new versions of the zones. Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SERVFAIL with ocsp.entrust.net.
Thanks for the help everyone. The query is now coming back with a NOERROR response. Of note, any other query besides A or is still showing SERVFAIL. Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 -Original Message- From: bind-users-bounces+ralph.bischof=nasa@lists.isc.org [mailto:bind-users-bounces+ralph.bischof=nasa@lists.isc.org] On Behalf Of Bischof, Ralph F. (MSFC-IS40)[NICS] Sent: Tuesday, April 24, 2012 12:53 PM To: bind-users@lists.isc.org Subject: SERVFAIL with ocsp.entrust.net. Hi Mark, Good to hear. I have been working with someone at Entrust for a while now and had an email last night from him to check again. And, yes, my main concern is dual-stack IPv6 machines, hence the queries being important. Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, April 24, 2012 10:44 AM To: Bischof, Ralph F. (MSFC-IS40)[NICS] Cc: comp-protocols-dns-b...@isc.org Subject: Re: SERVFAIL with ocsp.entrust.net. Entrust is definitely aware of the issue and are working on it. Yes it is a misconfiguration. This breaks FaceTime on dual stack machines on dual stack machines. They reported that they had fixed it earlier today but hadn't when I tested. They acknowledge the report that it was still broken and were going to look at their setup again. Mark ___ 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
SERVFAIL with ocsp.entrust.net.
Hello, I have been trying to find out why my caching servers are giving SERVFAIL as an answer for any type of query except for an A record for the domain in the subject. Whether I try a , TXT, SOA, PTR, TXT, etc, I get a SERVFAIL answer. Yet, it seems that anyone else in the world is getting NOERROR. Now, when I direct the query to the Microsoft DNS servers (8.8.8.8), I also get NOERROR. I have tried different versions of clients (9.4.3-P5 and 9.6-ESV-R4-P3) and get the same response, so I do not think that is the issue. When I use a 'dig +trace', the end of the chain shows a server that does not exist in the last answer consisting of the SOA record. In fact, since Sungard is involved, the whole chain makes no sense to me. I have edited out the extra stuff, but here is what I try to do. First, here is the 'dig +trace' with an A query. I left out the list of the root and gtld servers. [bischrf@nsc1 ~]$ dig +trace ocsp.entrust.net. a ;; Received 300 bytes from 192.149.130.101#53(192.149.130.101) in 0 ms ;; Received 491 bytes from 192.5.5.241#53(f.root-servers.net) in 26 ms entrust.net.172800 IN NS secondary-ns1.allstream.com. entrust.net.172800 IN NS secondary-ns2.allstream.com. entrust.net.172800 IN NS ns1.entrust.net. entrust.net.172800 IN NS ns2.entrust.net. ;; Received 203 bytes from 192.42.93.30#53(g.gtld-servers.net) in 115 ms ocsp.entrust.net. 7200IN NS gns1.sungardns.com. ocsp.entrust.net. 7200IN NS gns2.sungardns.com. ;; Received 85 bytes from 216.13.122.23#53(secondary-ns1.allstream.com) in 120 ms ocsp.entrust.net. 30 IN A 216.191.247.139 ;; Received 50 bytes from 207.19.96.22#53(gns1.sungardns.com) in 109 ms Then a 'dig +trace' looking for the record. [bischrf@nsc1 ~]$ dig +trace ocsp.entrust.net. ;; Received 344 bytes from 192.149.130.101#53(192.149.130.101) in 0 ms ;; Received 491 bytes from 199.7.83.42#53(l.root-servers.net) in 160 ms entrust.net.172800 IN NS secondary-ns1.allstream.com. entrust.net.172800 IN NS secondary-ns2.allstream.com. entrust.net.172800 IN NS ns1.entrust.net. entrust.net.172800 IN NS ns2.entrust.net. ;; Received 203 bytes from 192.26.92.30#53(c.gtld-servers.net) in 34 ms ocsp.entrust.net. 7200IN NS gns1.sungardns.com. ocsp.entrust.net. 7200IN NS gns2.sungardns.com. ;; Received 85 bytes from 216.191.247.202#53(ns2.entrust.net) in 125 ms entrust.net.60 IN SOA phlig3.oamp.sgns.net. hostmaster.phlig3.oamp.sgns.net. 42 10800 3600 604800 60 ;; Received 98 bytes from 207.19.96.22#53(gns1.sungardns.com) in 111 ms NOTE: phlig3.oamp.sgns.net does not exist. -- Here is the query that works. [bischrf@nsc1 ~]$ dig ocsp.entrust.net. a ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29329 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; ANSWER SECTION: ocsp.entrust.net. 24 IN A 216.191.247.203 ;; AUTHORITY SECTION: ocsp.entrust.net. 1675IN NS gns1.sungardns.com. ocsp.entrust.net. 1675IN NS gns2.sungardns.com. --- Now a query. Note there is no authority. [bischrf@nsc1 ~]$ dig ocsp.entrust.net. ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 20073 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 -- So now I try to follow the chain. 1) Query entrust.net. for the NS records. I get 4. [bischrf@nsc1 ~]$ dig entrust.net. ns ;; -HEADER- opcode: QUERY, status: NOERROR, id: 17958 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; ANSWER SECTION: entrust.net.1617IN NS ns2.entrust.net. entrust.net.1617IN NS secondary-ns1.allstream.com. entrust.net.1617IN NS ns1.entrust.net. entrust.net.1617IN NS secondary-ns2.allstream.com. - 2) I pick one of those and ask for the NS records for ocsp.entrust.net. [bischrf@nsc1 ~]$ dig @ns1.entrust.net. ocsp.entrust.net. ns ;; -HEADER- opcode: QUERY, status: NOERROR, id: 7029 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: ocsp.entrust.net. 7200IN NS gns1.sungardns.com. ocsp.entrust.net. 7200IN NS gns2.sungardns.com. -- 3) I pick one of those and try a query. [bischrf@nsc1 ~]$ dig @gns1.sungardns.com. ocsp.entrust.net. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4292 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion
RE: SERVFAIL with ocsp.entrust.net.
-Original Message- From: bind-users-bounces+ralph.bischof=nasa@lists.isc.org [mailto:bind-users-bounces+ralph.bischof=nasa@lists.isc.org] On Behalf Of Barry Margolin Sent: Tuesday, April 24, 2012 9:37 AM To: comp-protocols-dns-b...@isc.org Subject: Re: SERVFAIL with ocsp.entrust.net. In article mailman.576.1335276428.63724.bind-us...@lists.isc.org, Bischof, Ralph F. (MSFC-IS40)[NICS] ralph.bisc...@nasa.gov wrote: Hello, I have been trying to find out why my caching servers are giving SERVFAIL as an answer for any type of query except for an A record for the domain in the subject. Whether I try a , TXT, SOA, PTR, TXT, etc, I get a SERVFAIL answer. Yet, it seems that anyone else in the world is getting NOERROR. Now, when I direct the query to the Microsoft DNS servers (8.8.8.8), I also get NOERROR. I have tried different versions of clients (9.4.3-P5 and 9.6-ESV-R4-P3) and get the same response, so I do not think that is the issue. 8.8.8.8 is Google Public DNS, nothing to do with Microsoft. Oops. Had MS on the mind. I honestly meant Google. When I use a 'dig +trace', the end of the chain shows a server that does not exist in the last answer consisting of the SOA record. In fact, since Sungard is involved, the whole chain makes no sense to me. I have edited out the extra stuff, but here is what I try to do. They're delegating the ocsp.entrust.net subdomain to gnsX.sungardns.com, but those machines are configured to be authoritative for the entire entrust.net zone. But they have different contents than the real entrust.net zone. This is causing confusion in caching servers, because negative responses (like the NOANSWER response to queries) have the wrong domain in the authority section. Right. I have tried to explain this to both Sungard and Entrust. I don't understand how this works. Would you agree that this is a misconfiguration? First, here is the 'dig +trace' with an A query. I left out the list of the root and gtld servers. [bischrf@nsc1 ~]$ dig +trace ocsp.entrust.net. a ;; Received 300 bytes from 192.149.130.101#53(192.149.130.101) in 0 ms ;; Received 491 bytes from 192.5.5.241#53(f.root-servers.net) in 26 ms entrust.net.172800 IN NS secondary-ns1.allstream.com. entrust.net.172800 IN NS secondary-ns2.allstream.com. entrust.net.172800 IN NS ns1.entrust.net. entrust.net.172800 IN NS ns2.entrust.net. ;; Received 203 bytes from 192.42.93.30#53(g.gtld-servers.net) in 115 ms ocsp.entrust.net. 7200IN NS gns1.sungardns.com. ocsp.entrust.net. 7200IN NS gns2.sungardns.com. ;; Received 85 bytes from 216.13.122.23#53(secondary-ns1.allstream.com) in 120 ms ocsp.entrust.net. 30 IN A 216.191.247.139 ;; Received 50 bytes from 207.19.96.22#53(gns1.sungardns.com) in 109 ms Then a 'dig +trace' looking for the record. [bischrf@nsc1 ~]$ dig +trace ocsp.entrust.net. ;; Received 344 bytes from 192.149.130.101#53(192.149.130.101) in 0 ms ;; Received 491 bytes from 199.7.83.42#53(l.root-servers.net) in 160 ms entrust.net.172800 IN NS secondary-ns1.allstream.com. entrust.net.172800 IN NS secondary-ns2.allstream.com. entrust.net.172800 IN NS ns1.entrust.net. entrust.net.172800 IN NS ns2.entrust.net. ;; Received 203 bytes from 192.26.92.30#53(c.gtld-servers.net) in 34 ms ocsp.entrust.net. 7200IN NS gns1.sungardns.com. ocsp.entrust.net. 7200IN NS gns2.sungardns.com. ;; Received 85 bytes from 216.191.247.202#53(ns2.entrust.net) in 125 ms entrust.net.60 IN SOA phlig3.oamp.sgns.net. hostmaster.phlig3.oamp.sgns.net. 42 10800 3600 604800 60 ;; Received 98 bytes from 207.19.96.22#53(gns1.sungardns.com) in 111 ms NOTE: phlig3.oamp.sgns.net does not exist. -- Here is the query that works. [bischrf@nsc1 ~]$ dig ocsp.entrust.net. a ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29329 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; ANSWER SECTION: ocsp.entrust.net. 24 IN A 216.191.247.203 ;; AUTHORITY SECTION: ocsp.entrust.net. 1675IN NS gns1.sungardns.com. ocsp.entrust.net. 1675IN NS gns2.sungardns.com. --- Now a query. Note there is no authority. [bischrf@nsc1 ~]$ dig ocsp.entrust.net. ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 20073 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 -- So now I try to follow the chain. 1) Query entrust.net. for the NS records. I
SERVFAIL with ocsp.entrust.net.
Hi Mark, Good to hear. I have been working with someone at Entrust for a while now and had an email last night from him to check again. And, yes, my main concern is dual-stack IPv6 machines, hence the queries being important. Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, April 24, 2012 10:44 AM To: Bischof, Ralph F. (MSFC-IS40)[NICS] Cc: comp-protocols-dns-b...@isc.org Subject: Re: SERVFAIL with ocsp.entrust.net. Entrust is definitely aware of the issue and are working on it. Yes it is a misconfiguration. This breaks FaceTime on dual stack machines on dual stack machines. They reported that they had fixed it earlier today but hadn't when I tested. They acknowledge the report that it was still broken and were going to look at their setup again. Mark ___ 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
INSIST message
Hello, I have had a couple of INSIST messages in my general log. I am running BIND 9.6-ESV-R4-P3. Can someone enlighten me as to why I would be getting these? Out of over 125 machines, this is the only one that has logged this message starting yesterday. This is a recursive authoritative server. Can I offer any other information to help troubleshoot this? 17-Feb-2012 14:46:40.301 general: task.c:1229: INSISTmanager-tasks).head == ((void *)0)) ? isc_boolean_true : isc_boolean_false)) failed Thank you, Ralph F. Bischof, Jr. NASA Agency IPAM/DNS/DHCP SAIC/NICS 256-544-3982 ___ 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
