<div dir="ltr"><div><div>. . .well, I never expected to get "flamed" as by GED, "<i>As a general observation, not knowing what you're doing is dangerous<br>
on the Internet.  Please take some time out of your undoubtedly busy life to try to ensure that you aren't a menace to the rest of us.  A<br>
good start might be to read the famous DNS and BIND</i>."<br><br></div>Actually I have two copies of Cricket Liu's book, both 4th and 5th edition.  (4th ed. autographed.)<br><br></div>Regardless, the reason for two name servers pointing to the same IP address is because the domain registrar requires two designated name servers; so since we only have the one platform running DNS with BIND Version: 9.10.2 Perhaps in the future a second installation may be incorporated.<div><br></div><div>Regardless this system has worked well since 2002.  Only as of 3 NOV 2017 has it started failing.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 21, 2017 at 9:53 AM,  <span dir="ltr"><<a href="mailto:bind-users-request@lists.isc.org" target="_blank">bind-users-request@lists.isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send bind-users mailing list submissions to<br>
        <a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:bind-users-request@lists.isc.org">bind-users-request@lists.isc.<wbr>org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:bind-users-owner@lists.isc.org">bind-users-owner@lists.isc.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of bind-users digest..."<br>
<br>Today's Topics:<br>
<br>
   1. Re: Domain Not Resolving (G.W. Haywood)<br>
   2. Re: Domain Not Resolving (Reindl Harald)<br>
   3. localhost entries in zones, was Re: Domain Not Resolving<br>
      (Tony Finch)<br>
   4. Re: DNAME usage? (Timothe Litt)<br>
   5. Re: localhost entries in zones, was Re: Domain Not Resolving<br>
      (Reindl Harald)<br>
<br><br>---------- Forwarded message ----------<br>From: "G.W. Haywood" <<a href="mailto:bind@jubileegroup.co.uk">bind@jubileegroup.co.uk</a>><br>To: <a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>Cc: <br>Bcc: <br>Date: Tue, 21 Nov 2017 13:42:12 +0000 (GMT)<br>Subject: Re: Domain Not Resolving<br>Hi there,<br>
<br>
On Tue, 21 Nov 2017, Ron Wingfield wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... our registered domain, <a href="http://archaxis.net" rel="noreferrer" target="_blank">archaxis.net</a>, is not resolving ...<br>
</blockquote>
<br>
As has been mentioned, you don't have a nameserver listening on IP<br>
162.202.233.81.  At a guess, you need to restart it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We run BIND version 9.10.2 ...<br>
</blockquote>
<br>
Upgrade.  See for example<br>
<br>
<a href="http://www.cvedetails.com/cve/CVE-2016-2776/" rel="noreferrer" target="_blank">http://www.cvedetails.com/cve/<wbr>CVE-2016-2776/</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... This has worked for past months until 3 NOV 2017 ...<br>
</blockquote>
<br>
It depends on your definition of 'worked'.  I'd say that it has never<br>
worked, it's just sort of limped along in spite of all your mistakes.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Again, I emphasize that this configuration has been working since modified<br>
Thr Aug 6 2015 following conversion to AT&T U-verse, and has not changed<br>
since Jan 12 2017 when added an SPF TXT RR for <a href="http://archaxis.net" rel="noreferrer" target="_blank">archaxis.net</a>.<br>
[...]<br>
Can any of you list members see any thing wrong with the previously<br>
included zone file?<br>
</blockquote>
<br>
Your configuration has probably never been correct.  At some stage,<br>
something you wanted to happen might have happened, but that was just<br>
blind luck.  Your zone file is a mess.  Most importantly the four<br>
names ns1, ns2, alpha and bravo all have the same IP address which is<br>
ridiculous in this context.  There are two SPF TXT records when only<br>
one is allowed by the RFCs, and I suspect that neither of them will do<br>
what's required.  The simplest thing you can do with those is delete<br>
them.  The address for localhost (127.0.0.1) should be in /etc/hosts,<br>
not in your zone file, and very probably it already is.<br>
<br>
When you've got the rest of your DNS mess sorted out, and when you've<br>
ensured your site is secure (upgrade BIND - and keep it up to date;<br>
did you know that you have servers listening to the entire Internet on<br>
ports 22, 110, 8080 and 60443?; are *they* patched up to date? this<br>
includes firmware updates for your Linksys router ...) then you might<br>
drop by the SPF users' mailing list for advice on your SPF TXT record.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After reporting this continuing unsatisfactory fail to AT&T, they have yet<br>
again responded "As was stated, it shows that we are correctly delegating<br>
the records.  The issue still persists that your nameservers A records are<br>
not resolving.  That is wholly outside our control or access.  PTR requests<br>
will continue to fail as the <a href="http://ns1.archaxis.net" rel="noreferrer" target="_blank">ns1.archaxis.net</a> and <a href="http://ns2.archaxis.net" rel="noreferrer" target="_blank">ns2.archaxis.net</a> are not<br>
responding to requests."<br>
</blockquote>
<br>
AT&T is correct.  You have told them that you are running your own<br>
name servers, which is a lie - you've only ever had one, and that's<br>
not acceptable.  Your name service is not running on the one server<br>
which you do have.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Who is to blame?<br>
</blockquote>
<br>
You are.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am at my wit?s end.  This was working ? why did it just stop?<br>
</blockquote>
<br>
I don't know why it stopped.  You *might* have suffered from the DOS<br>
attack mentioned in the above CVE, but I think it's much more likely<br>
that you broke something.  It might be that that something was your<br>
nameserver configuration, or perhaps you've broken the server's boot<br>
scripts, or perhaps you've changed your router or its configuration<br>
and it isn't forwarding DNS requests to your internal server.  These<br>
are all your responsibilities.<br>
<br>
There are many free DNS services available.  I suggest you pick one of<br>
them, and many of your problems will be, er, resolved.  The services<br>
from <a href="http://he.net" rel="noreferrer" target="_blank">he.net</a> have always been very good for my purposes, and extend to<br>
areas beyond simple IPv4 DNS.  They will keep their servers patched.<br>
They offer educational material too.<br>
<br>
As a general observation, not knowing what you're doing is dangerous<br>
on the Internet.  Please take some time out of your undoubtedly busy<br>
life to try to ensure that you aren't a menace to the rest of us.  A<br>
good start might be to read the famous "DNS and BIND".<br>
<br>
-- <br>
<br>
73,<br>
Ged.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Reindl Harald <<a href="mailto:h.reindl@thelounge.net">h.reindl@thelounge.net</a>><br>To: <a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>Cc: <br>Bcc: <br>Date: Tue, 21 Nov 2017 15:10:37 +0100<br>Subject: Re: Domain Not Resolving<br><br>
<br>
Am 21.11.2017 um 14:42 schrieb G.W. Haywood via bind-users:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The address for localhost (127.0.0.1) should be in /etc/hosts,<br>
not in your zone file, and very probably it already is<br>
</blockquote>
<br>
that part is not true<br>
<br>
<a href="https://tools.ietf.org/html/rfc1537" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rf<wbr>c1537</a> says:<br>
Note that all domains that contain hosts should have a "localhost" A record in them<br>
<br>
simply because /etc/hosts is not considered in case of a DNS lookup at all and a unqualified query for "localhost" with "search <a href="http://thelounge.net" rel="noreferrer" target="_blank">thelounge.net</a>" in /etc/resolv.conf would be expanded to "<a href="http://localhost.thelounge.net" rel="noreferrer" target="_blank">localhost.thelounge.net</a>." and so correctly answered at the first try - our dns backend adds them to every single zone-file because of rfc1537 for years<br>
<br>
<a href="http://localhost.thelounge.net" rel="noreferrer" target="_blank">localhost.thelounge.net</a>. 86400  IN      A       127.0.0.1<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Tony Finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>><br>To: Reindl Harald <<a href="mailto:h.reindl@thelounge.net">h.reindl@thelounge.net</a>><br>Cc: <a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>Bcc: <br>Date: Tue, 21 Nov 2017 14:27:13 +0000<br>Subject: localhost entries in zones, was Re: Domain Not Resolving<br>Reindl Harald <<a href="mailto:h.reindl@thelounge.net">h.reindl@thelounge.net</a>> wrote:<br>
> Am 21.11.2017 um 14:42 schrieb G.W. Haywood via bind-users:<br>
> > The address for localhost (127.0.0.1) should be in /etc/hosts,<br>
> > not in your zone file, and very probably it already is<br>
><br>
> that part is not true<br>
><br>
> <a href="https://tools.ietf.org/html/rfc1537" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>rfc1537</a> says:<br>
> Note that all domains that contain hosts should have a "localhost" A record in<br>
> them<br>
<br>
That advice is no longer a good idea. "localhost" in the DNS can lead to<br>
problems with the web browser same-origin security policy.<br>
<br>
<a href="http://seclists.org/bugtraq/2008/Jan/270" rel="noreferrer" target="_blank">http://seclists.org/bugtraq/<wbr>2008/Jan/270</a><br>
<br>
> simply because /etc/hosts is not considered in case of a DNS lookup at all and<br>
> a unqualified query for "localhost" with "search <a href="http://thelounge.net" rel="noreferrer" target="_blank">thelounge.net</a>" in<br>
> /etc/resolv.conf would be expanded to "<a href="http://localhost.thelounge.net" rel="noreferrer" target="_blank">localhost.thelounge.net</a>."<br>
<br>
I investigated this a few months ago when I was deleting the localhost<br>
entries from our zones and I found that our recursive servers were<br>
receiving almost no localhost queries, so there would be no performance<br>
impact in deleting them.<br>
<br>
There has been some discussion about localhost queries and the DNS in the<br>
IETF dnsop working group recently. This thread was informative:<br>
<a href="https://www.ietf.org/mail-archive/web/dnsop/current/msg20968.html" rel="noreferrer" target="_blank">https://www.ietf.org/mail-<wbr>archive/web/dnsop/current/<wbr>msg20968.html</a><br>
<br>
Tony.<br>
--<br>
f.anthony.n.finch  <<a href="mailto:dot@dotat.at">dot@dotat.at</a>>  <a href="http://dotat.at/" rel="noreferrer" target="_blank">http://dotat.at/</a>  -  I xn--zr8h punycode<br>
Shannon: Southwest 5 to 7, becoming variable 3, then cyclonic 6 to gale 8.<br>
Rough or very rough. Rain. Moderate or poor.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Timothe Litt <<a href="mailto:litt@acm.org">litt@acm.org</a>><br>To: <a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>Cc: <br>Bcc: <br>Date: Tue, 21 Nov 2017 10:20:11 -0500<br>Subject: Re: DNAME usage?<br>
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    On 17-Nov-17 18:04, Mark Andrews wrote:<br>
    <blockquote type="cite">
      <pre>DYN used to just require a TSIG signed update request set to a server specified in
a SRV record.</pre>
    </blockquote>
    Depends on which service.  The one I referred to is the one that was
    popular (free) for people who wanted to reach a machine on a dynamic
    IP address.  Because it was popular, it was implemented in a number
    of routers, including Linksys (low end) and Cisco (IOS).  I believe
    they discontinued the free version, but the protocol lives on.<br>
    <br>
    It's worse than DNS UPDATE in an number of respects - but is trivial
    to implement in a router or script as the core is just an HTTP GET.<br>
    <blockquote type="cite">
      <pre>
We have a perfectly fine protocol for updating the DNS but DNS hosting companies
want to reinvent the wheel.
</pre>
    </blockquote>
    Agree. I wish that the DNS UPDATE protocol was the only one in the
    wild.  Unfortunately, (non-jail broken) routers don't provide that
    option, but do provide the http ("dyn") version.  So if you want to
    use a service that requires it - or want to bridge a router that
    supports it to DNS UPDATE, some invention is required.  I outlined
    an approach that works for me.<br>
    <br>
    For reference, cisco's IOS (now) supports both methods - to some
    extent.<br>
    <br>
    See <a href="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dns/configuration/15-sy/dns-15-sy-book/Dynamic-DNS-Support.html#GUID-DCA9088D-EB90-46DE-9E33-306C30BB79CE" target="_blank">https://www.cisco.com/c/en/us/<wbr>td/docs/ios-xml/ios/ipaddr_<wbr>dns/configuration/15-sy/dns-<wbr>15-sy-book/Dynamic-DNS-<wbr>Support.html#GUID-DCA9088D-<wbr>EB90-46DE-9E33-306C30BB79CE</a><br>
    <br>
    And from that page, here's the reference to dyndns (you can change
    the URI for other http services; it lists 6 others)<br>
    <blockquote>add
<a class="m_3762582264702338874moz-txt-link-freetext" href="http://test:test@members.dyndns.org/nic/update?system=dyndns&hostname=" target="_blank">http://test:test@members.<wbr>dyndns.org/nic/update?system=<wbr>dyndns&hostname=</a><h>&myip=<a><br>
    </blockquote>
    I use https, of course.<br>
    <br>
    Naturally, IOS doesn't support TSIG - so DNS UPDATE from it has to
    be authorized by IP address. :-(<br>
    <br>
    2136/7 have been around since 1997, so there's really no excuse for
    DNS providers not tosupport them.<br>
    <br>
    But we live in a world of excuses :-(<br>
    <br>
  </div>

<br><br>---------- Forwarded message ----------<br>From: Reindl Harald <<a href="mailto:h.reindl@thelounge.net">h.reindl@thelounge.net</a>><br>To: <a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>Cc: <br>Bcc: <br>Date: Tue, 21 Nov 2017 16:53:50 +0100<br>Subject: Re: localhost entries in zones, was Re: Domain Not Resolving<br><br>
<br>
Am 21.11.2017 um 15:27 schrieb Tony Finch:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Reindl Harald <<a href="mailto:h.reindl@thelounge.net" target="_blank">h.reindl@thelounge.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 21.11.2017 um 14:42 schrieb G.W. Haywood via bind-users:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The address for localhost (127.0.0.1) should be in /etc/hosts,<br>
not in your zone file, and very probably it already is<br>
</blockquote>
<br>
that part is not true<br>
<br>
<a href="https://tools.ietf.org/html/rfc1537" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rf<wbr>c1537</a> says:<br>
Note that all domains that contain hosts should have a "localhost" A record in<br>
them<br>
</blockquote>
<br>
That advice is no longer a good idea. "localhost" in the DNS can lead to<br>
problems with the web browser same-origin security policy.<br>
<br>
<a href="http://seclists.org/bugtraq/2008/Jan/270" rel="noreferrer" target="_blank">http://seclists.org/bugtraq/20<wbr>08/Jan/270</a><br>
</blockquote>
<br>
interesting - but however "administrators often mistakenly drop the trailing dot" is nonsense because "Note that all domains that contain hosts should have a localhost A record" says exactly that<br>
______________________<br>
<br>
from that webpage:<br>
<br>
It's a common and sensible practice to install records of the form<br>
"localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely<br>
however, administrators often mistakenly drop the trailing dot,<br>
introducing an interesting variation of Cross-Site Scripting (XSS) I<br>
call Same-Site Scripting<br>
<br>
<br>______________________________<wbr>_________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a><br></blockquote></div><br></div>