Re: 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

[Rick Moen <rick@linuxmafia.com>]

Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

> No ... not sure why that shows/showed "double" for you there.

After posting, I realised it must have been two separate sections of
WHOIS return values reporting the same data.  That's a limitation of 
my scripting tactics in use, there.

If it hadn't been way too damned late, and my trying to catch up on
sysadmin tasks while lying in bed before sleep, I'd have figured out
where the apparent doubling came from.  But I just didn't have time to
pursue the matter, so just noted the anomaly so I could complete the
task and go to sleep.

> 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.

That part everyone who does DNS knows.

The thing is, the reason I'd never seen escaping of periods in anyone 
else's SOA RNAME subfield, even though I've seen a ton of zonefiles, 
is this is the literally the first time I've seen a zone whose zone 
administrator is reached via a firstname.lastname corporate-style e-mail
address.  It's always been like rm@example.com, noc@example.com,
ops@example.com, hostmaster@example.com, root@example.com .  

So, yeah, the need to escape your LHS period makes total sense for parsing
(now that I see that problem arise); I'd just never seen anyone needing
to solve that specific problem before.

And, again, I was on the edge of sleep and lacked time to ponder the
matter, so I noted the anomaly and completed the task so I could nod
off.


> No, that intentionally allows an source IP address to do AXFR.

Fine, as long as it's intentional.

As you almost certainly already know, most DNS admins lock down
AXFR/IXFR to authorised slave nameserver IP addresses only, as policy,
to implement a minor security measure to make the job of intruders doing
resource discovery a little harder.  Presumably you know all about the
arguments for (e.g. 'but I want all of this to be completely public!')
and against, so there's no reason to trot them out.  If not, knock
yourself out arguing with or against US-CERT:
https://www.us-cert.gov/ncas/alerts/TA15-103A

> And, I then further thought, heck, [L]UG(s) - can I think of any
> particularly good reasons to not make AXFR open to all?

There are reasons.  Whether they're good or not is in the eye of the
beholder.  Your system, your policy.

I consider locking down AXFR/IXFR best practices, and that's what I
teach people.  But you do you.

-- 
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.