Re: Named Service

2019-01-22 Thread Peter DeVries
You should want the -chroot portion so you are running named in a chroot
environment but you don't need it.  There are two files named.service and
named-chroot.service.  There is also rndc-startup.service (maybe the wrong
filename) that helps configure rndc if it isn't already.  I typically
remove that and opt for my own manual rndc config.

Peter

On Tue, Jan 22, 2019 at 12:35 PM Jordan Tinsley 
wrote:

> Thank you for the information!  Also, do I need to use the {-chroot}
> portion?
>
>
>
> Thanks,
>
> Jordan
>
>
>
> *From:* Peter DeVries 
> *Sent:* Tuesday, January 22, 2019 11:32 AM
> *To:* Jordan Tinsley 
> *Cc:* bind-users 
> *Subject:* Re: Named Service
>
>
>
> You didn't mention your OS.  I'm assuming Redhat Linux.   The files you
> are looking for are /usr/lib/systemd/system/named{-chroot}.service.  The
> files are not included in the BIND source.  The easiest thing is to pull
> them out of one of the existing redhat BIND packages and edit for your
> needs.  There is nothing in the script that is version specific.
>
>
>
>
>
> On Tue, Jan 22, 2019 at 10:13 AM Jordan Tinsley 
> wrote:
>
> Hello,
>
>
>
> Just wondering how to get the named service setup when compiling from
> source?
>
>
>
> When I tried on a test machine to enable named for startup using systemctl
> enable named or systemctl start named
>
>
>
> I get an error that named.service doesn’t exist.  I may be overlooking
> documentation somewhere, but I don’t see anything about this.
>
>
>
> Thanks,
>
> Jordan
>
> ___
> 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: Named Service

2019-01-22 Thread Peter DeVries
You didn't mention your OS.  I'm assuming Redhat Linux.   The files you are
looking for are /usr/lib/systemd/system/named{-chroot}.service.  The files
are not included in the BIND source.  The easiest thing is to pull them out
of one of the existing redhat BIND packages and edit for your needs.  There
is nothing in the script that is version specific.


On Tue, Jan 22, 2019 at 10:13 AM Jordan Tinsley 
wrote:

> Hello,
>
>
>
> Just wondering how to get the named service setup when compiling from
> source?
>
>
>
> When I tried on a test machine to enable named for startup using systemctl
> enable named or systemctl start named
>
>
>
> I get an error that named.service doesn’t exist.  I may be overlooking
> documentation somewhere, but I don’t see anything about this.
>
>
>
> Thanks,
>
> Jordan
> ___
> 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: Question regarding different responses that I am getting for a lookup.

2018-08-06 Thread Peter DeVries
They are probably using a load balancer of some sort that is choosing
between multiple systems and directing you to the one closest or no under
load at the moment.   The low TTL is usually a sign of this as well.



On Mon, Aug 6, 2018 at 2:12 PM, Bhangui, Sandeep - BLS CTR <
bhangui.sand...@bls.gov> wrote:

> Hello
>
>
>
> Not sure why I am getting different responses when I perform a dig on
> sso.dol.gov.
>
>
>
> Dig is performed from a server which is capable of querying the root
> servers….what could be the issue.   Both dig commands below are run from
> the same server which acts as DNS server capable of performing DNS queries
> on the internet.
>
>
>
> The dig +trace +all output is the same when I query my local server as
> well as when I query the VZ NS.
>
>
>
> Any guidance/pointers would be appreciated.
>
>
>
> Running Bind 9.11.3 on RHEL 6.x is that is of any relevance.
>
>
>
> I have a feeling that the external DNS entry presented  for sso.dol.gov
> is messed up…
>
>
>
> Thanks
>
> Sandeep
>
>
>
>
>
>
>
> sh-4.1# dig *sso.dol.gov *
>
>
>
> ; <<>> DiG 9.11.3 <<>> sso.dol.gov
>
> ;; global options: +cmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12647
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
>
>
>
> ;; OPT PSEUDOSECTION:
>
> ; EDNS: version: 0, flags:; udp: 4096
>
> ; COOKIE: 191369419bc6df077b8f30ce5b688c9e77211f348bb29b35 (good)
>
> ;; QUESTION SECTION:
>
> ;sso.dol.gov.   IN  A
>
>
>
> ;; ANSWER SECTION:
>
> sso.dol.gov.77266   IN  CNAME   sso.gslb.dol.gov.
>
> sso.gslb.dol.gov.   15  IN  A   *10.49.1.80*
>
>
>
> ;; AUTHORITY SECTION:
>
> gslb.dol.gov.   77266   IN  NS  silprodgslb.dol.gov.
>
> gslb.dol.gov.   77266   IN  NS  stldrpgslb.dol.gov.
>
>
>
> ;; Query time: 27 msec
>
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>
> ;; WHEN: Mon Aug 06 13:59:58 EDT 2018
>
> ;; MSG SIZE  rcvd: 158
>
>
>
>
>
> sh-4.1# dig *@198.6.1.1 * *sso.dol.gov
> *
>
>
>
> ; <<>> DiG 9.11.3 <<>> @198.6.1.1 sso.dol.gov
>
> ; (1 server found)
>
> ;; global options: +cmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25189
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
>
>
> ;; OPT PSEUDOSECTION:
>
> ; EDNS: version: 0, flags:; udp: 4000
>
> ;; QUESTION SECTION:
>
> ;sso.dol.gov.   IN  A
>
>
>
> ;; ANSWER SECTION:
>
> sso.dol.gov.86378   IN  CNAME   sso.gslb.dol.gov.
>
> sso.gslb.dol.gov.   15  IN  A   *152.180.20.21*
>
>
>
> ;; Query time: 93 msec
>
> ;; SERVER: 198.6.1.1#53(198.6.1.1)
>
> ;; WHEN: Mon Aug 06 14:01:42 EDT 2018
>
> ;; MSG SIZE  rcvd: 79
>
>
>
> ___
> 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: cyberia.net.sa

2018-06-26 Thread Peter DeVries
You're going to have to provide more information than that.   What isn't
working from your internet perspective?

Looks fine from where I'm sitting.

; <<>> DiG 9.11.2-P1 <<>> cyberia.net.sa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4586
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cyberia.net.sa.IN  A

;; ANSWER SECTION:
cyberia.net.sa. 600 IN  A   212.119.92.15

;; AUTHORITY SECTION:
cyberia.net.sa. 600 IN  NS  ns2.cyberia.net.sa.
cyberia.net.sa. 600 IN  NS  ns1.cyberia.net.sa.

;; ADDITIONAL SECTION:
ns1.cyberia.net.sa. 372 IN  A   212.119.92.5
ns2.cyberia.net.sa. 372 IN  A   212.119.93.5


On Tue, Jun 26, 2018 at 7:08 AM, Mohammed Ejaz  wrote:

> I  am using bind I have problem in resolving my domain cyberia.net.sa
> over the internet. Whereas it is working fine internally. Any clue would
> be  highly appeicated.
>
>
>
> Thanks,
>
> Mohammed Ejaz
>
> Asst. Operation Director of Systems.
>
> Cyberia SAUDI ARABIA
>
> P.O.Box: 301079, Riyadh 11372
>
> Phone:  (+966) 11 464 7114 Ext. 140
>
> Mobile:  (+966) 562311787
>
> Fax:  (+966) 11 465 4735
>
> Website: http://www.cyberia.net.sa
>
>
>
> ___
> 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: extranet.aro.army.mil - not resolving

2018-05-31 Thread Peter DeVries
+cd disables DNSSEC validation.  You are running some very old versions of
dig in some cases which don't have dnssec support.   The 9.9 version of dig
you have on at least one server should work.

What version of BIND server are you running on the problematic system?

On Thu, May 31, 2018 at 8:18 PM, cwiel...@uci.edu  wrote:

> Hi
>
> Can you elaborate on +cd? a dig option, I am not finding it as an option.
>
> thanks
> con
>
> > On May 31, 2018, at 2:51 PM, Warren Kumari  wrote:
> >
> > Try it with +cd and see if that fixes it.
> >
> > The DNSSEC stuff for this domain is all borked up -- sufficiently that
> > I felt like I was playing snakes and ladders while looking at:
> > http://dnsviz.net/d/extranet.aro.army.mil/dnssec/
> > On Thu, May 31, 2018 at 5:45 PM John Miller 
> wrote:
> >>
> >> Hi Con,
> >>
> >> May I suggest running dig +trace extranet.aro.army.mil from your
> >> nameserver?  That'll make the delegation process explicit and help you
> >> troubleshoot a little better.  It could be that one of the three main
> >> army.mil nameservers is unreachable by your ns for some reason
> >> (routing being a likely culprit).
> >>
> >> John
> >>
> >> On Thu, May 31, 2018 at 5:29 PM, Con Wieland  wrote:
> >>> and here they are but I don’t see anything indicating what the problem
> might be
> >>>
> >>> 31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> >>> 31-May-2018 13:56:01.151 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> >>> 31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> >>> 31-May-2018 13:56:06.153 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> >>> 31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> >>> 31-May-2018 13:56:11.158 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> >>> 31-May-2018 13:56:11.158 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> >>> 31-May-2018 13:56:21.168 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> >>>
>  On May 31, 2018, at 12:51 PM, Reindl Harald 
> wrote:
> 
> 
> 
>  Am 31.05.2018 um 21:42 schrieb Con Wieland:
> > agreed but why would my server not resolve it while others do?
> 
>  ask the logs of 128.200.1.201
> 
>  ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
>  ;; global options: +cmd
>  ;; Got answer:
>  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
>  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>  ;; SERVER: 128.200.1.201#53(128.200.1.201)
> 
> >> On May 31, 2018, at 12:16 PM, Reindl Harald 
> wrote:
> >>
> >>
> >>
> >> Am 31.05.2018 um 21:09 schrieb Con Wieland:
> >>> I have a nameserver that can not resolve extranet.aro.army.mil.
> >>
> >> terrible slow and insane config - fix it
> >>
> >> https://intodns.com/aro.army.mil
> >>
> >> ;; Query time: 1175 msec
> >> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> >> ;; WHEN: Do Mai 31 21:12:26 CEST 2018
> >> ;; MSG SIZE  rcvd: 247
> >>
> >> ;; Query time: 1109 msec
> >> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> >> ;; WHEN: Do Mai 31 21:12:52 CEST 2018
> >> ;; MSG SIZE  rcvd: 191
> >>
> >> ;; ANSWER SECTION:
> >> aro.army.mil.   2022IN  NS  ns03.army.mil.
> >> aro.army.mil.   2022IN  NS  ns02.army.mil.
> >> aro.army.mil.   2022IN  NS  ns01.army.mil.
> >>
> >> ;; Query time: 163 msec
> >> ;; SERVER: 192.82.113.7#53(192.82.113.7)
> >> ;; WHEN: Do Mai 31 21:15:37 CEST 2018
> >> ;; MSG SIZE  rcvd: 98
> >> WarnSOA REFRESH WARNING: Your SOA REFRESH interval is:
> 900. That is
> >> not so ok
> >> WarnSOA RETRY   Your SOA RETRY value is: 90. That is
> NOT OK
> 
> >>>
> >>> ___
> >>> 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
> >>
> >>
> >>
> >> --
> >> John Miller
> >> Senior Systems Engineer
> >> Brandeis University ITS
> >> johnm...@brandeis.edu
> >> (781) 736-4619
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 

Re: extranet.aro.army.mil - not resolving

2018-05-31 Thread Peter DeVries
It's messy to be sure but it's not failing validation on any of the systems
I'm testing on (no AD bit because the CNAMEs aren't signed but no SERVFAIL
either)(.   I see a bunch of dig versions in your posting (9.3?).  What
version BIND is the server running?

On Thu, May 31, 2018 at 5:51 PM, Warren Kumari  wrote:

> Try it with +cd and see if that fixes it.
>
> The DNSSEC stuff for this domain is all borked up -- sufficiently that
> I felt like I was playing snakes and ladders while looking at:
> http://dnsviz.net/d/extranet.aro.army.mil/dnssec/
> On Thu, May 31, 2018 at 5:45 PM John Miller  wrote:
> >
> > Hi Con,
> >
> > May I suggest running dig +trace extranet.aro.army.mil from your
> > nameserver?  That'll make the delegation process explicit and help you
> > troubleshoot a little better.  It could be that one of the three main
> > army.mil nameservers is unreachable by your ns for some reason
> > (routing being a likely culprit).
> >
> > John
> >
> > On Thu, May 31, 2018 at 5:29 PM, Con Wieland  wrote:
> > > and here they are but I don’t see anything indicating what the problem
> might be
> > >
> > > 31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> > > 31-May-2018 13:56:01.151 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > > 31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> > > 31-May-2018 13:56:06.153 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > > 31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> > > 31-May-2018 13:56:11.158 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> > > 31-May-2018 13:56:11.158 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > > 31-May-2018 13:56:21.168 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> > >
> > >> On May 31, 2018, at 12:51 PM, Reindl Harald 
> wrote:
> > >>
> > >>
> > >>
> > >> Am 31.05.2018 um 21:42 schrieb Con Wieland:
> > >>> agreed but why would my server not resolve it while others do?
> > >>
> > >> ask the logs of 128.200.1.201
> > >>
> > >> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
> > >> ;; global options: +cmd
> > >> ;; Got answer:
> > >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
> > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> > >> ;; SERVER: 128.200.1.201#53(128.200.1.201)
> > >>
> >  On May 31, 2018, at 12:16 PM, Reindl Harald 
> wrote:
> > 
> > 
> > 
> >  Am 31.05.2018 um 21:09 schrieb Con Wieland:
> > > I have a nameserver that can not resolve extranet.aro.army.mil.
> > 
> >  terrible slow and insane config - fix it
> > 
> >  https://intodns.com/aro.army.mil
> > 
> >  ;; Query time: 1175 msec
> >  ;; SERVER: 127.0.0.1#53(127.0.0.1)
> >  ;; WHEN: Do Mai 31 21:12:26 CEST 2018
> >  ;; MSG SIZE  rcvd: 247
> > 
> >  ;; Query time: 1109 msec
> >  ;; SERVER: 8.8.8.8#53(8.8.8.8)
> >  ;; WHEN: Do Mai 31 21:12:52 CEST 2018
> >  ;; MSG SIZE  rcvd: 191
> > 
> >  ;; ANSWER SECTION:
> >  aro.army.mil.   2022IN  NS  ns03.army.mil.
> >  aro.army.mil.   2022IN  NS  ns02.army.mil.
> >  aro.army.mil.   2022IN  NS  ns01.army.mil.
> > 
> >  ;; Query time: 163 msec
> >  ;; SERVER: 192.82.113.7#53(192.82.113.7)
> >  ;; WHEN: Do Mai 31 21:15:37 CEST 2018
> >  ;; MSG SIZE  rcvd: 98
> >  WarnSOA REFRESH WARNING: Your SOA REFRESH interval is:
> 900. That is
> >  not so ok
> >  WarnSOA RETRY   Your SOA RETRY value is: 90. That is
> NOT OK
> > >>
> > >
> > > ___
> > > 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
> >
> >
> >
> > --
> > John Miller
> > Senior Systems Engineer
> > Brandeis University ITS
> > johnm...@brandeis.edu
> > (781) 736-4619
> > ___
> > 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
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the