Should be dnsreport.com

Re: Should be dnsreport.com

From:

Date:

Time:

>Feel free to look up my domain "goya.com.au".

DNSReport says it won't give your domain a green PASS but a big, fat YELLOW
WARN:

"Your NS records APPEAR to be:"

Len: the "APPEAR" suggests they might be something else. Why the doubt? But
they aren't, there's no doubt. The APPEAR is totally misleading, and
anybody anywhere who wants to KNOW what the NS records are (this includes
the "apparently" incapable DNSReport) learns them simply by asking the .au
parent NSs what the ARE:

# dig @ns1.ausregistry.net goya.com.au. ns

; <<>> DiG 9.2.3rc3 <<>> @ns1.ausregistry.net goya.com.au. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58744
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;goya.com.au. IN NS

;; AUTHORITY SECTION:
goya.com.au. 3600 IN NS ns1.telstra.net.
goya.com.au. 3600 IN NS mail.goya.com.au.

There, that didn't APPEAR too hard, did it? DNS isn't fuzzy, hit-and-miss,
probabilistic protocol.

"NOTE: These records may be inaccurate"

Len's NOTE: BS alert!! Weasel-words alert!! What's inaccurate is DNSReport.

"... since the parent servers (ns.ripe.net.) do not know the NS records for
goya.com.au"

ns.ripe.net is not the "parent servers", it's just one of 9 servers
delegated with authority for com.au.

and the above DNSReport comment is abosolutely wrong, and proved so by a
single query:

tx1# dig @ns.ripe.net goya.com.au any

; <<>> DiG 9.2.3 <<>> @193.0.0.193 goya.com.au any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9142
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;goya.com.au. IN ANY

;; AUTHORITY SECTION:
goya.com.au. 3600 IN NS mail.goya.com.au.
goya.com.au. 3600 IN NS ns1.telstra.net.

(or give a referral to other DNS servers)!"

Why the melodramatic "!" The above response is a boring, banal
referral. ns.ripe.net DOES know EXACTLY the NS delegation records for
goya.com.au, and returns them as non-parenthetical "referral", which is
exactly what ns.ripe.net (as parent NS for com.au) is supposed to do.

"This may cause other tests not to work properly, such as the 'Nameservers
on separate class C' test."

Len's translation: "this irresponsibly bogus WARNing may cause other bogus
DNSreport tests to give more irresponsibly bogus warnings or outright bogus
failures".

ie, the "problem" is totally within DNSReport, and not with goya.com.au,
nor with any part of Internet.

btw, before anyone starts throwing around inflammatory words like "hate",
he should know that I have really tried, directly with Scott, to make his
DNSReport better by correcting this and other faults, but he refuses to
learn how DNS works and refuses to correct his reports. Not a very
responsible position for a service that pretends to help people with their
DNS. And I would say the majority of people who use DNSReport are DNS
ignorant or novices, since DNS experts use dig and other geeky tools for
the DNS queries and analysis.

Is DNSReports helpful? yes, of course. No one is saying it isn't.

>I registered my domain name with (what used to be at the time) the only
>domain register for .au domains. I didn't have any choice to register
>with any one else.
>They manage the delegation for me. I've set up the domain properly,

... everything about your delegation is done properly..

> but my domain gives this message when run through dnsreports.

... so, confirming yet again, the WARNING is totally useless and misleading.

>If you could, explain how I could alter my domain reg/delegation to work
>any differently that wouldn't give this warning.

the "false problem" is that your .au domain is delegated to a .net
NS. Which means that when ns1.telstra.net is queried for your domain, all
the delegation records are returned (aka a "referral") but only the .au
glue is returned:

# dig @ns1.telstra.net goya.com.au. ns

; <<>> DiG 9.2.3rc3 <<>> @ns1.telstra.net goya.com.au. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62323
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;goya.com.au. IN NS

;; ANSWER SECTION:
goya.com.au. 86400 IN NS mail.goya.com.au.
goya.com.au. 86400 IN NS ns1.telstra.net.

;; ADDITIONAL SECTION:
mail.goya.com.au. 86400 IN A 203.222.103.130

tisk, tisk, the A record for ns1.telstra.net. is "missing". This is
absolutely no error, and is absolutely no problem. A querying DNS would
then obtain the "missing" A record, aka "fetch the glue", by querying for
ns1.telstra.net:

# dig @a.gtld-servers.net ns1.telstra.net

; <<>> DiG 9.2.3rc3 <<>> @a.gtld-servers.net ns1.telstra.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55759
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;ns1.telstra.net. IN A

;; ANSWER SECTION:
ns1.telstra.net. 172800 IN A 139.130.4.5

So with one additional query, the "missing" glue is obtained. This extra
query and its horrendous delay is what DSNReport is bitching about. This
took such a long time that DNSReport has to warn about it and recommend
changing your delegation to avoid the "delay".

So how long is this delay?

;; Query time: 64 msec

ouch! This 64 ms really slows down my surfing users and my mail server.

Even better, after the query, the A record is cached in my local DNS for
172800s, (48h), during which time the "missing" glue is available locally
from my cache at exactly the same speed as if the "missing" glue had been
delivered to my DNS cache on the first query.

Why doesn't .au NS have the A record for the .net NS? Because any .net A
record is "out of zone" for the .au parent NS. (and vice versa). This is
how DNS works.

In fact, the (Verisign) gTLD servers used to be the parent NSs for .com,
.net, and .org. (The .org domain was stripped from Verisign and given
ISOC and ISOC's NSs.) So ALL .com and .net domains delegated to an .org NS
will also be erroneously flagged as "missing glue" at the .com and .net
NSs. Likewise all .org domains delegated to .net or .com NSs (or ANY
non-.org NS) will be WARNed by DNSReport as "missing glue".

If you want to "fix" your non-problem (then you have been duped by
DNSReport, like 1000s of others), you would have to re-delegate your .au
domain to only .au NSs, as DNSReport irresponsibly recommends.

Imagine this situation: verisign also loses the .net, so the
gtld-servers.net would be authoritative only for .com, meaning all .com and
.net domains delegated to, respectively, .net and .com (or any other TLD)
NS would ALL be flagged by DNSReport as WARNINGs. ie, the whole world of
Internet would merit a WARNING from DNSReport.

I hope some of you have learned a little bit more about how delegation
works, because mastering delegation a key responsibility for any DNS
administrator.

Len

Sales:
888/4-DPOINT

Support:
858/452-3696