bind-users Digest, Vol 2770, Issue 2
Ron Wingfield
foobaryou at gmail.com
Tue Nov 21 17:05:44 UTC 2017
. . .well, I never expected to get "flamed" as by GED, "
*As a general observation, not knowing what you're doing is dangerous 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 good start
might be to read the famous DNS and BIND*."
Actually I have two copies of Cricket Liu's book, both 4th and 5th
edition. (4th ed. autographed.)
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.
Regardless this system has worked well since 2002. Only as of 3 NOV 2017
has it started failing.
On Tue, Nov 21, 2017 at 9:53 AM, <bind-users-request at lists.isc.org> wrote:
> Send bind-users mailing list submissions to
> bind-users at lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-request at lists.isc.org
>
> You can reach the person managing the list at
> bind-users-owner at lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
>
> Today's Topics:
>
> 1. Re: Domain Not Resolving (G.W. Haywood)
> 2. Re: Domain Not Resolving (Reindl Harald)
> 3. localhost entries in zones, was Re: Domain Not Resolving
> (Tony Finch)
> 4. Re: DNAME usage? (Timothe Litt)
> 5. Re: localhost entries in zones, was Re: Domain Not Resolving
> (Reindl Harald)
>
>
> ---------- Forwarded message ----------
> From: "G.W. Haywood" <bind at jubileegroup.co.uk>
> To: bind-users at lists.isc.org
> Cc:
> Bcc:
> Date: Tue, 21 Nov 2017 13:42:12 +0000 (GMT)
> Subject: Re: Domain Not Resolving
> Hi there,
>
> On Tue, 21 Nov 2017, Ron Wingfield wrote:
>
> ... our registered domain, archaxis.net, is not resolving ...
>>
>
> As has been mentioned, you don't have a nameserver listening on IP
> 162.202.233.81. At a guess, you need to restart it.
>
> We run BIND version 9.10.2 ...
>>
>
> Upgrade. See for example
>
> http://www.cvedetails.com/cve/CVE-2016-2776/
>
> ... This has worked for past months until 3 NOV 2017 ...
>>
>
> It depends on your definition of 'worked'. I'd say that it has never
> worked, it's just sort of limped along in spite of all your mistakes.
>
> Again, I emphasize that this configuration has been working since modified
>> Thr Aug 6 2015 following conversion to AT&T U-verse, and has not changed
>> since Jan 12 2017 when added an SPF TXT RR for archaxis.net.
>> [...]
>> Can any of you list members see any thing wrong with the previously
>> included zone file?
>>
>
> Your configuration has probably never been correct. At some stage,
> something you wanted to happen might have happened, but that was just
> blind luck. Your zone file is a mess. Most importantly the four
> names ns1, ns2, alpha and bravo all have the same IP address which is
> ridiculous in this context. There are two SPF TXT records when only
> one is allowed by the RFCs, and I suspect that neither of them will do
> what's required. The simplest thing you can do with those is delete
> them. The address for localhost (127.0.0.1) should be in /etc/hosts,
> not in your zone file, and very probably it already is.
>
> When you've got the rest of your DNS mess sorted out, and when you've
> ensured your site is secure (upgrade BIND - and keep it up to date;
> did you know that you have servers listening to the entire Internet on
> ports 22, 110, 8080 and 60443?; are *they* patched up to date? this
> includes firmware updates for your Linksys router ...) then you might
> drop by the SPF users' mailing list for advice on your SPF TXT record.
>
> After reporting this continuing unsatisfactory fail to AT&T, they have yet
>> again responded "As was stated, it shows that we are correctly delegating
>> the records. The issue still persists that your nameservers A records are
>> not resolving. That is wholly outside our control or access. PTR
>> requests
>> will continue to fail as the ns1.archaxis.net and ns2.archaxis.net are
>> not
>> responding to requests."
>>
>
> AT&T is correct. You have told them that you are running your own
> name servers, which is a lie - you've only ever had one, and that's
> not acceptable. Your name service is not running on the one server
> which you do have.
>
> Who is to blame?
>>
>
> You are.
>
> I am at my wit?s end. This was working ? why did it just stop?
>>
>
> I don't know why it stopped. You *might* have suffered from the DOS
> attack mentioned in the above CVE, but I think it's much more likely
> that you broke something. It might be that that something was your
> nameserver configuration, or perhaps you've broken the server's boot
> scripts, or perhaps you've changed your router or its configuration
> and it isn't forwarding DNS requests to your internal server. These
> are all your responsibilities.
>
> There are many free DNS services available. I suggest you pick one of
> them, and many of your problems will be, er, resolved. The services
> from he.net have always been very good for my purposes, and extend to
> areas beyond simple IPv4 DNS. They will keep their servers patched.
> They offer educational material too.
>
> As a general observation, not knowing what you're doing is dangerous
> 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
> good start might be to read the famous "DNS and BIND".
>
> --
>
> 73,
> Ged.
>
>
>
> ---------- Forwarded message ----------
> From: Reindl Harald <h.reindl at thelounge.net>
> To: bind-users at lists.isc.org
> Cc:
> Bcc:
> Date: Tue, 21 Nov 2017 15:10:37 +0100
> Subject: Re: Domain Not Resolving
>
>
> Am 21.11.2017 um 14:42 schrieb G.W. Haywood via bind-users:
>
>> The address for localhost (127.0.0.1) should be in /etc/hosts,
>> not in your zone file, and very probably it already is
>>
>
> that part is not true
>
> https://tools.ietf.org/html/rfc1537 says:
> Note that all domains that contain hosts should have a "localhost" A
> record in them
>
> simply because /etc/hosts is not considered in case of a DNS lookup at all
> and a unqualified query for "localhost" with "search thelounge.net" in
> /etc/resolv.conf would be expanded to "localhost.thelounge.net." and so
> correctly answered at the first try - our dns backend adds them to every
> single zone-file because of rfc1537 for years
>
> localhost.thelounge.net. 86400 IN A 127.0.0.1
>
>
>
> ---------- Forwarded message ----------
> From: Tony Finch <dot at dotat.at>
> To: Reindl Harald <h.reindl at thelounge.net>
> Cc: bind-users at lists.isc.org
> Bcc:
> Date: Tue, 21 Nov 2017 14:27:13 +0000
> Subject: localhost entries in zones, was Re: Domain Not Resolving
> Reindl Harald <h.reindl at thelounge.net> wrote:
> > Am 21.11.2017 um 14:42 schrieb G.W. Haywood via bind-users:
> > > The address for localhost (127.0.0.1) should be in /etc/hosts,
> > > not in your zone file, and very probably it already is
> >
> > that part is not true
> >
> > https://tools.ietf.org/html/rfc1537 says:
> > Note that all domains that contain hosts should have a "localhost" A
> record in
> > them
>
> That advice is no longer a good idea. "localhost" in the DNS can lead to
> problems with the web browser same-origin security policy.
>
> http://seclists.org/bugtraq/2008/Jan/270
>
> > simply because /etc/hosts is not considered in case of a DNS lookup at
> all and
> > a unqualified query for "localhost" with "search thelounge.net" in
> > /etc/resolv.conf would be expanded to "localhost.thelounge.net."
>
> I investigated this a few months ago when I was deleting the localhost
> entries from our zones and I found that our recursive servers were
> receiving almost no localhost queries, so there would be no performance
> impact in deleting them.
>
> There has been some discussion about localhost queries and the DNS in the
> IETF dnsop working group recently. This thread was informative:
> https://www.ietf.org/mail-archive/web/dnsop/current/msg20968.html
>
> Tony.
> --
> f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h
> punycode
> Shannon: Southwest 5 to 7, becoming variable 3, then cyclonic 6 to gale 8.
> Rough or very rough. Rain. Moderate or poor.
>
>
>
> ---------- Forwarded message ----------
> From: Timothe Litt <litt at acm.org>
> To: bind-users at lists.isc.org
> Cc:
> Bcc:
> Date: Tue, 21 Nov 2017 10:20:11 -0500
> Subject: Re: DNAME usage?
> On 17-Nov-17 18:04, Mark Andrews wrote:
>
> DYN used to just require a TSIG signed update request set to a server specified in
> a SRV record.
>
> 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.
>
> 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.
>
>
> We have a perfectly fine protocol for updating the DNS but DNS hosting companies
> want to reinvent the wheel.
>
> 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.
>
> For reference, cisco's IOS (now) supports both methods - to some extent.
>
> See 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
>
> And from that page, here's the reference to dyndns (you can change the URI
> for other http services; it lists 6 others)
>
> add http://test:test@members.dyndns.org/nic/update?system=dyndns&hostname=
> <h>&myip=<a>
>
> I use https, of course.
>
> Naturally, IOS doesn't support TSIG - so DNS UPDATE from it has to be
> authorized by IP address. :-(
>
> 2136/7 have been around since 1997, so there's really no excuse for DNS
> providers not tosupport them.
>
> But we live in a world of excuses :-(
>
>
>
> ---------- Forwarded message ----------
> From: Reindl Harald <h.reindl at thelounge.net>
> To: bind-users at lists.isc.org
> Cc:
> Bcc:
> Date: Tue, 21 Nov 2017 16:53:50 +0100
> Subject: Re: localhost entries in zones, was Re: Domain Not Resolving
>
>
> Am 21.11.2017 um 15:27 schrieb Tony Finch:
>
>> Reindl Harald <h.reindl at thelounge.net> wrote:
>>
>>> Am 21.11.2017 um 14:42 schrieb G.W. Haywood via bind-users:
>>>
>>>> The address for localhost (127.0.0.1) should be in /etc/hosts,
>>>> not in your zone file, and very probably it already is
>>>>
>>>
>>> that part is not true
>>>
>>> https://tools.ietf.org/html/rfc1537 says:
>>> Note that all domains that contain hosts should have a "localhost" A
>>> record in
>>> them
>>>
>>
>> That advice is no longer a good idea. "localhost" in the DNS can lead to
>> problems with the web browser same-origin security policy.
>>
>> http://seclists.org/bugtraq/2008/Jan/270
>>
>
> 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
> ______________________
>
> from that webpage:
>
> It's a common and sensible practice to install records of the form
> "localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely
> however, administrators often mistakenly drop the trailing dot,
> introducing an interesting variation of Cross-Site Scripting (XSS) I
> call Same-Site Scripting
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20171121/4f289b93/attachment-0001.html>
More information about the bind-users
mailing list