Ok.. so if I am following this the domain academy.edu
(http://www.dnsreport.com/tools/dnsreport.ch?domain=academy.edu) means
that the top level dns servers do not have the proper records to supply
both the ns and A records. They are supplying the ns record but not the
A record? And in this case ATT does not have the record properly set up
for the client? Not quite sure who to tell the customer to yell at, ATT
or the gods that administer the top level dns servers.
Sorry to be so dense on this one but have run across about 3 or 4 of
these in the last two weeks.
Thank you very much for the help.. at least it sheds some light on the
topic... was about to run out and get them some elmers school glue to
fix them up.
Roger
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry
Sent: Monday, September 24, 2001 6:15 PM
To: [EMAIL PROTECTED]
Subject: Re: [IMail Forum] what the heck is glue at root?
>Ok.. once and a while when researching mail problems I see a message
>about invalid glue at root from DNSREPORT.COM .. Can anyone enlighten
>me as to what glue at root is...
"glue" usually refers to A records in NS lookups, that weren't
specifically
requested, but are needed. For example, if I want to find the A record
for
www.declude.com, I first need to check with the root servers to find the
NS
record for declude.com (the nameservers responsible for handling DNS
requests for the declude.com domain). The root servers say they are
udns1.ultradns.net and
udns2.ultradns.net.
So the question is, how do I figure out what IP address
udns1.ultradns.net
and udns2.ultradns.net are? The answer is that the root server has to
tell
me; that's the "glue". If they didn't tell me, I would have to look up
the
A record for those two domains, but would have to look up the NS records
first. And what if their DNS server was at declude.com? Then I would
have
to go to the nameserver for declude.com to get the IP address of
udns1.ultradns.net, but in order to find the nameserver for declude.com,
I
would need to find the IP address of udns1.ultradns.net, causing an
infinite loop.
I believe the RFCs require the glue to be there for root servers, and
other
DNS servers that are the start of a new zone. Every so often, a root
server won't give out the glue -- I have no idea why it would not,
though. I only recall seeing this happen with some of the country TLDs
(such as .uk). And, when it happens, it seems that some of the root
servers will have the glue and others will not.
>... what a customer would need to do to fix it ...
That I have no idea of. I guess the first step would be to ask the
people
who are in charge of the root servers for the TLD (.uk, .com, whatever)
why
the glue isn't being sent, to see if there is a valid reason. If not,
yell
at 'em.
>and how it might impact mail delivery?
At the very least, it will slow down mail delivery. That's because
unnecessary DNS lookups need to be done. Instead of 2 packets being
sent
(1 to root asking for the NS for the domain, and 1 to the NS asking for
the
MX record), 4 or more packets may need to be sent (you also need to send
an
NS for the NS you had requested, and an A for that NS).
---
NOTE: Please be aware that during the next few days/weeks we may be
very
shorthanded, and may send very brief or slow responses, due to the
disaster
in the U.S. and our involvement with the local Red Cross chapter.
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
