Tillbaka till svenska Fidonet
English   Information   Debug  
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4779
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1117
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   2632
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13030
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2055
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4275
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   27611
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/1974
DOS_INTERNET   0/196
duplikat   5999
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33774
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   23439
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12841
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4155
FN_SYSOP   41520
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13565
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16041
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22002
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   894
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
Möte OSDEBATE, 18996 texter
 lista första sista föregående nästa
Text 366, 507 rader
Skriven 2004-08-21 09:59:10 av Frank Haber (1:379/45)
Ärende: DNS Glue and Multiple Registrars
========================================
From: "Frank Haber" <frhaber@N0SPMrcn.com>

This is a multi-part message in MIME format.

------=_NextPart_000_00FC_01C48765.81D0ADC0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I'm just getting my feet wet in NS records, etc., the better to understand my
client's problems.  I found the attached messages useful  One's from my local
ISP's support NG, the other is what's referred to in that message.

--

-Frank

------=_NextPart_000_00FC_01C48765.81D0ADC0
Content-Type: text/plain;
        name="Re_ RCN DNS refreshes.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="Re_ RCN DNS refreshes.txt"

From: "Chris Jackman" <chris.jackman@rcn.com>
Subject: Re: RCN DNS refreshes?
Date: Saturday, August 14, 2004 11:54 AM

On 2004-08-14, Geoff <geoffNUMBERTWO@rcnDOT.com> wrote:
<  I made the change on Wednesday. My registrar took 36 hours to push
<  the update (as measured by dnsreport.com). Could this be related
<  to the fact that the registrar is associated with Rackspace, and
<  I was switching away from a Rackspace-hosted service? Surely not.....
<=20
<  By the way, I find dnsreport.com really useful. Check out what
<  it has to say about RCN:
<=20
<  http://dnsreport.com/tools/dnsreport.ch?domain=3Drcn.com

Yes, we've seen it, We've gotten tickets with its output.  There are some
things it doesn't check for, and things it warns for that aren't problems (like
the .org servers not returning glue for .com/net ns records).


Here's one post explaining the glue thing, read the whole=20 thread at the
bottom of this page:
http://www.digitalpoint.com/lists/74646.html =20


Also, dnsreport.com doesn't check for things like a=20 domain being delegated
to NS records in a second domain, and that second domain not having A records
for its NS=20 records.

example: quicklister.com
do a dnsreport on that, and it'll come up looking ok.

You'll see its hosted at retrohosting.com. =20 do a dnsreport on that, and
it'll come up looking ok.

But if we do a couple digs:

first the Gtlds:

dig ns quicklister.com @a.gtld-servers.net

; <<>> DiG 8.3 <<>> ns quicklister.com @a.gtld-servers.net=20
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUERY SECTION:
;;      quicklister.com, type =3D NS, class =3D IN

;; ANSWER SECTION:
quicklister.com.        2D IN NS        dns1.retrohosting.com.
quicklister.com.        2D IN NS        dns2.retrohosting.com.

;; ADDITIONAL SECTION:
dns1.retrohosting.com.  2D IN A         69.93.246.7
dns2.retrohosting.com.  2D IN A         69.93.246.6



There's quicklister.com using retrohosting.com.  So lets check retrohosting:

>dig ns retrohosting.com @a.gtld-servers.net

; <<>> DiG 8.3 <<>> ns retrohosting.com @a.gtld-servers.net=20
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUERY SECTION:
;;      retrohosting.com, type =3D NS, class =3D IN

;; ANSWER SECTION:
retrohosting.com.       2D IN NS        dns1.retrohosting.com.
retrohosting.com.       2D IN NS        dns2.retrohosting.com.

;; ADDITIONAL SECTION:
dns1.retrohosting.com.  2D IN A         69.93.246.7
dns2.retrohosting.com.  2D IN A         69.93.246.6


Okay, and you see two A records, which is good, but the nameservers at
69.93.246.6 and .7 are supposed to have those A records also.


But when we go to look:=20

dig a dns1.retrohosting.com @69.93.246.7

; <<>> DiG 8.3 <<>> a dns1.retrohosting.com @69.93.246.7=20
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;      dns1.retrohosting.com, type =3D A, class =3D IN

;; AUTHORITY SECTION:
retrohosting.com.       4h40s IN SOA    dns1.retrohosting.com. =
root.cybernet01.retrohosting.com. (
                                        2004050401      ; serial
                                        4H              ; refresh
                                        2H              ; retry
                                        5w6d16h         ; expiry
                                        1D )            ; minimum



We get the SOA record, which means the dns server doesn't have an A record, and
is suggesting we contact the SOA person.


But it's still a good site for quick info.=00
------=_NextPart_000_00FC_01C48765.81D0ADC0
Content-Type: text/plain;
        name="Should be dnsreport_com.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="Should be dnsreport_com.txt"

            Re: Should be dnsreport.com
            From: Len Conrad
            Date: Tuesday, December 23, 2003
            Time: 4:41:29 am

            >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=20
            YELLOW=20
            WARN:

            "Your NS records APPEAR to be:"

            Len: the "APPEAR" suggests they might be something else. Why =
the=20
            doubt? But=20
            they aren't, there's no doubt. The APPEAR is totally =
misleading, and=20

            anybody anywhere who wants to KNOW what the NS records are =
(this=20
            includes=20
            the "apparently" incapable DNSReport) learns them simply by =
asking=20
            the .au=20
            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,=20
            probabilistic protocol.

            "NOTE: These records may be inaccurate"

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

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

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

            and the above DNSReport comment is abosolutely wrong, and =
proved so=20
            by a=20
            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=20
            referral. ns.ripe.net DOES know EXACTLY the NS delegation =
records=20
            for=20
            goya.com.au, and returns them as non-parenthetical =
"referral", which=20
            is=20
            exactly what ns.ripe.net (as parent NS for com.au) is =
supposed to=20
do.

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

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

            outright bogus=20
            failures".

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

            btw, before anyone starts throwing around inflammatory words =
like=20
            "hate",=20
            he should know that I have really tried, directly with =
Scott, to=20
            make his=20
            DNSReport better by correcting this and other faults, but he =
refuses=20
            to=20
            learn how DNS works and refuses to correct his reports. Not =
a very=20
            responsible position for a service that pretends to help =
people with=20
            their=20
            DNS. And I would say the majority of people who use =
DNSReport are=20
            DNS=20
            ignorant or novices, since DNS experts use dig and other =
geeky tools=20
            for=20
            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=20
            only=20
            >domain register for .au domains. I didn't have any choice =
to=20
            register=20
            >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=20
            misleading.

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

            the "false problem" is that your .au domain is delegated to =
a .net=20
            NS. Which means that when ns1.telstra.net is queried for =
your=20
            domain, all=20
            the delegation records are returned (aka a "referral") but =
only the=20
            .au=20
            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=20
            absolutely no error, and is absolutely no problem. A =
querying DNS=20
            would=20
            then obtain the "missing" A record, aka "fetch the glue", by =

            querying for=20
            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=20
            extra=20
            query and its horrendous delay is what DSNReport is bitching =
about.=20
            This=20
            took such a long time that DNSReport has to warn about it =
and=20
            recommend=20
            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=20
            server.

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

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

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

            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=20
            DNSReport, like 1000s of others), you would have to =
re-delegate your=20
            .au=20
            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=20
            .com and=20
            .net domains delegated to, respectively, .net and .com (or =
any other=20
            TLD)=20
            NS would ALL be flagged by DNSReport as WARNINGs. ie, the =
whole=20
            world of=20
            Internet would merit a WARNING from DNSReport.

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

            administrator.

            Len







            Messages In This Thread:
              Should be dnsreport.com by Mia''s Virtual Post Office on =
Dec 22,=20
              2003 at 3:51:05 pm
              Should be dnsreport.com by Mia''s Virtual Post Office on =
Dec 22,=20
              2003 at 4:10:21 pm
                Re: Should be dnsreport.com by Michael Wise on Dec 22, =
2003 at=20
                5:14:54 pm
                Re: Should be dnsreport.com by Len Conrad on Dec 22, =
2003 at=20
                5:33:46 pm
                Re: Should be dnsreport.com by Nicholas Orr on Dec 22, =
2003 at=20
                6:23:25 pm
                Re: Should be dnsreport.com by Len Conrad on Dec 23, =
2003 at=20
                4:41:29 am
                Re: Should be dnsreport.com by Michael Wise on Dec 23, =
2003 at=20
                10:00:20 am
                Re: Should be dnsreport.com by Len Conrad on Dec 23, =
2003 at=20
                11:37:18 am
                Re: Should be dnsreport.com by Thomas Sulentic on Dec =
23, 2003=20
                at 12:07:46 pm
                Re: Should be dnsreport.com by Michael Wise on Dec 23, =
2003 at=20
                5:15:33 pm
                Re: Should be dnsreport.com by Len Conrad on Dec 23, =
2003 at=20
                9:06:03 pm
                Re: Should be dnsreport.com by Men & Mice Support on Dec =
26,=20
                2003 at 12:55:46 pm




      Return to Digital Point Solutions' Home Page



------=_NextPart_000_00FC_01C48765.81D0ADC0--

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)