[sf-lug] SFLUG.org

Michael Paoli Michael.Paoli at cal.berkeley.edu
Mon Apr 8 20:22:51 PDT 2019


> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] SF[-]LUG & domain(s) Re: Domain ...
> Date: Mon, 8 Apr 2019 19:30:37 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> DNS queries against sf-lug.org. ... if we remove the -
>> give us SERVFAIL ... but that might be semi-expected
>> if someone just acquired domain and hadn't yet
>> planned out or provided for the infrastructure to use it ... at
>> least quite yet.
>
> As you say:
>
> $ dig -t soa sflug.org
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58438
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> $
>
> Moreover, looking up and then going straight to the four (newly)
> authoritative servers:
>
> $ whois sflug.org | grep 'Name Server'
> Name Server: NS0.SUNNYSIDE.COM
> Name Server: NS1.SUNNYSIDE.COM
> Name Server: NS2.SUNNYSIDE.COM
> Name Server: NS3.SUNNYSIDE.COM
>
> $ dig -t soa sflug.org @NS0.SUNNYSIDE.COM
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 38967
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>
> $ dig -t soa sflug.org @NS1.SUNNYSIDE.COM
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53871
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>
> $ dig -t soa sflug.org @NS2.SUNNYSIDE.COM
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24111
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>
> $ dig -t soa sflug.org @NS3.SUNNYSIDE.COM
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41074
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>
> $


Yep, true that:
$ dig +noall +answer +nottl org. NS | head -n 1
org.                    IN      NS      b2.org.afilias-nst.org.
$ dig @b2.org.afilias-nst.org. +noall +authority +norecurse sflug.org. NS
sflug.org.              86400   IN      NS      ns0.sunnyside.com.
sflug.org.              86400   IN      NS      ns1.sunnyside.com.
sflug.org.              86400   IN      NS      ns2.sunnyside.com.
sflug.org.              86400   IN      NS      ns3.sunnyside.com.
$

$ (for NS in 0 1 2 3; do NS=ns"$NS".sunnyside.com.; dig @"$NS"  
+norecurse +noall +answer sflug.org. NS sflug.org. SOA sflug.org. ANY;  
done)
$ (for NS in 0 1 2 3; do NS=ns"$NS".sunnyside.com.; dig @"$NS"  
+norecurse +noall +answer +comments sflug.org. NS sflug.org. SOA  
sflug.org. ANY; done) | sort -u

; EDNS: version: 0, flags:; udp: 4096
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12141
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14463
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18128
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21335
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 26515
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33214
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 42339
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 4862
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 50045
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52826
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 62725
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 62957
;; Got answer:
;; OPT PSEUDOSECTION:
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
$

No "there" there.


> In light of which, I'm driven to ask:
>
>> Would also be good to have a "dump" of any existing sflug.org DNS data
> [...]
>> In any case, whatever's in DNS might be slightly (or more?) useful to
>> have dump of that data (e.g. could avoid an RFC violating serial #
>> jump on zone, or avoid "mystery" issues over longer TTLs that are/were
>> in effect but subsequently "unknown" - yet cached elsewhere in DNS).

Maybe I was hoping someone else might do (some of) the work/research
for a change ... either show definitively that there's no DNS data there
to be had, ... or provide a dump of it (or as much as feasible, based
on any "known"(/guessed) RR records.

*Anyone* (well, with a bit 'o skill, and some access and enough knowing
to look up / search how) could'a done those DNS queries and reached
those conclusions ... needn't be me or "you" (Rick), ... could be some
other ^SF[-]\{0,1\}LUG$ers.


> _What_ existing DNS data?  Looks like there is no data being served.

Yep, as you concluded, and as I semi-guessed might be the case with the
slight peek I'd taken earlier ... but I'd - at that time - not more
thoroughly checked to (fully) rule out other likely possibilities.

> I noticed the above a few minutes ago, when I set out to determine if Al
> Whaley had happened to leave any of the authoritative nameservers open
> to AXFR queries, in which case I'd be able to post the temporary
> zonefile and tell you there's no need to ask Al for it.  But then I
> couldn't help noticing that there doesn't appear to _be any zone data_
> being published, ergo rendering geekish obsessions over avoiding
> theoretical S/N regression and over theoretical problematically long
> TTLs a completely moot point, n'est-ce pas?

Yes, true, no "there" there.  And, ... if we (me, & you Rick), had sat
back and waited (at least some longer while), ... might someone else
have braved checking and more-or-less reporting that they'd found same?

Sometimes some folks might be wee less intimidated if we don't so quickly
jump to provide answer ... but rather hang back and wait - at least some
reasonable  bit first.

Okay, maybe I could'a been a bit more explicit, and ask, "Who wants to
check / see if ..." ... but I thought folk(s) might take a (subtle) hint,
and perhaps start to (at least partially) fill in the gaps - of what
at least hadn't been fully said/covered.




More information about the sf-lug mailing list