[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

booboos?: Re: BerkeleyLUG.ORG - renewed & transferred; slaves? ...: Re: Wither berkeleylug.ORG - keep/drop decide by: 2019-04-17T04:39:28Z - currently expires 2019-05-17T04:39:28Z

From: "Rick Moen" <rick@linuxmafia.com>
Subject: Re: BerkeleyLUG.ORG - renewed & transferred; slaves? ...: Re: Wither berkeleylug.ORG - keep/drop decide by: 2019-04-17T04:39:28Z - currently expires 2019-05-17T04:39:28Z 
Date: Thu, 18 Apr 2019 00:38:56 -0700



{scratches head}  Hey, I think someone made a boo-boo in the auth
nameserver listings (as I'm seeing double).

$ whois berkeleylug.org | grep 'Name Server' | grep -v "Name Server\n"
Name Server: PUCK.NETHER.NET
Name Server: NS0.BERKELEYLUG.ORG
Name Server: PUCK.NETHER.NET
Name Server: NS0.BERKELEYLUG.ORG


No ... not sure why that shows/showed "double" for you there.
I get:
$ whois berkeleylug.org 2>&1 | grep -i 'name.*server'
Name Server: PUCK.NETHER.NET
Name Server: NS0.BERKELEYLUG.ORG
$
In any case, looking at actual DNS data:
$ (for ns in $(dig +short org. NS); do echo $(dig @"$ns" +norecurse +noall +authority berkeleylug.org. NS | awk '{print $NF;}' | sort) "[$ns]"; done) 
ns0.berkeleylug.org. puck.nether.net. [a0.org.afilias-nst.info.]
ns0.berkeleylug.org. puck.nether.net. [d0.org.afilias-nst.org.]
ns0.berkeleylug.org. puck.nether.net. [b2.org.afilias-nst.org.]
ns0.berkeleylug.org. puck.nether.net. [b0.org.afilias-nst.org.]
ns0.berkeleylug.org. puck.nether.net. [c0.org.afilias-nst.info.]
ns0.berkeleylug.org. puck.nether.net. [a2.org.afilias-nst.info.]
$
I'm not seeing "double" there.


$ dig -t soa berkeleylug.org +short
ns0.berkeleylug.org. Michael\.Paoli.cal.berkeley.edu.berkeleylug.org. 1555254673 10800 3600 1209600 86400 
$

Er, I suspect that backslash is another boo-boo, but I was requesting
that record just to verify where the master nameserver is.


Nope, that's intentional, and correct.  :-)

The first . is interpreted as @ to change it into an email address ...
unless preceded by \, in which case it's literal.
So,
Michael.Paoli.cal.berkeley.edu.berkeleylug.org.
would incorrectly be interpreted as email at non-existent domain:
Michael@Paoli.cal.berkeley.edu.berkeleylug.org
whereas:
Michael\.Paoli.cal.berkeley.edu.berkeleylug.org.
is correctly interpreted as:
Michael.Paoli@cal.berkeley.edu.berkeleylug.org


$ dig -t axfr berkeleylug.org. @ns0.berkeleylug.org

[RM:  redacting return value of the entire zonefile.  Suffice to say,
public AXFR appears to be supported, which you might want to curtail
for security reasons over the long term.]


No, that intentionally allows an source IP address to do AXFR.  A conscious
decision I made years ago - at least for the [L]UG domains - and I think
I have likewise on my own domains.  Why?  Well, it happened about like
this:
I was looking over logs, saw moderate spattering of AXFR denied.  One of
'em somehow caught my attention - or maybe there was something reasonably
attention getting in the "reverse" DNS I did on the IP ... following the
trail (very) slightly and quite easily, I quickly found - and may have
been in reverse DNS or trace of something else, essentially
something like, "Please allow us to do AXFR, we're researchers (or
something like that) and use this data to survey and map The
Internet - Thanks" ... and along (probably) with some web URL
information or other stuff to easily check further and also validate
the legitimacy of the request and match it to the requesting IP.
So, I thought, hmmm, sure, sounds quite legitimate and reasonable
and useful, so, sure, why not?
And, I then further thought, heck, [L]UG(s) - can I think of any particularly
good reasons to not make AXFR open to all?  I could think of no good
reason to not open it up - after all, the data is pretty much open to
public anyway (anyone knowing the RR(s) can always query and and/or all
types), and it's pretty much all out there for public (e.g. most if not
all RRs - or at least domains, generally on list(s), web site, etc.),
also helps "learning"/educational (general [L]UG) "missions"(s), etc.
so ... sure, why not?  Open up AXFR to all.
And, additionally, downside risk?  Just about zilch.  I mean the DNS
server allows queries over TCP anyway, so short of any potential of
allowing the whole zone to be accessed as a whole, about zilch in the
way of additional security risk.  And given how relatively public
most (if not all) that data is anyway, again, zero to negligible
security risk.  And also, makes some things easier - e.g. don't have to
manage allowing specific IPs when, e.g. a slave is added or changes
IPs, etc., or if (potential) slave wants to check that they can transfer okay.
So ... I went ahead and opened 'em all up (perhaps one of 'em first, but
likely all in fairly short order).  I might've even mentioned it (or at
least the first - and maybe even the "why" once-upon-a-time on one of
the lists.  And sure, "bad actors" also pull the AXFR data, ... but again
little additional risk (if any).

That being said, other environments are quite different.  E.g. DNS
data - especially entire zone, would be on a "need to know basis" - as
it may "leak" data/information about infrastructure, IPs, etc. that
one might not want to make generally public.  So, e.g. most companies
and the like, generally don't allow AXFR by all.

In any case, thanks for bothering to look these things over.  Folks
might not otherwise learn why they are as they are, and/or other
useful/informative bits (like things to check for, and how, etc.)

--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To post to this group, send email to berkeleylug@googlegroups.com.
Visit this group at https://groups.google.com/group/berkeleylug.
For more options, visit https://groups.google.com/d/optout.