[sf-lug] SF[-]LUG & domain(s) Re: Domain ...
Rick Moen
rick at linuxmafia.com
Mon Apr 8 19:30:37 PDT 2019
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
$
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).
_What_ existing DNS data? Looks like there is no data being served.
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?
More information about the sf-lug
mailing list