On Tuesday 14 November 2006 08:25, Pete Ehlke wrote:
> >www.macys.com is an alias for www.macys.com.edgekey.net.
> >www.macys.com.edgekey.net has address 72.246.68.134
> >Using domain server:
> >Name: 127.0.0.1
> >Address: 127.0.0.1#53
> >Aliases:
There are a bunch of tools provided with djbdns that reveal the issues, but
let's try another test and see what problems they do have.
They have a number of issues, courtesy of dnsreport.com:-
1) ERROR: One or more of your nameservers reports that it is an open DNS
server. This usually means that anyone in the world can query it for domains
it is not authoritative for (it is possible that the DNS server advertises
that it does recursive lookups when it does not, but that shouldn't happen).
This can cause an excessive load on your DNS server. Also, it is strongly
discouraged to have a DNS server be both authoritative for your domain and be
recursive (even if it is not open), due to the potential for cache poisoning
(with no recursion, there is no cache, and it is impossible to poison it).
Also, the bad guys could use your DNS server as part of an attack, by forging
their IP address. Problem record(s) are:
Server 129.33.82.4 reports that it will do recursive lookups.
129.33.82.5 reports that it will do recursive lookups.
2) You have one or more missing (stealth) nameservers. The following
nameserver(s) are listed (at your nameservers) as nameservers for your
domain, but are not listed at the parent nameservers (therefore, they may or
may not get used, depending on whether your DNS servers return them in the
authority section for other requests, per RFC2181 5.4.1). You need to make
sure that these stealth nameservers are working; if they are not responding,
you may have serious problems! The DNS Report will not query these servers,
so you need to be very careful that they are working properly.
blduswxdnsb01.boulder.mebs.ihost.com.
blduswxdnsb02.boulder.mebs.ihost.com.
rtpussxdnsb03.raleigh.mebs.ihost.com.
rtpussxdnsb04.raleigh.mebs.ihost.com.
This is listed as an ERROR because there are some cases where nasty problems
can occur (if the TTLs vary from the NS records at the root servers and the
NS records point to your own domain, for example).
3) Your DNS servers leak stealth information in non-NS requests:
Stealth nameservers are leaked [blduswxdnsb01.boulder.mebs.ihost.com.]!
Stealth nameservers are leaked [blduswxdnsb02.boulder.mebs.ihost.com.]!
Stealth nameservers are leaked [rtpussxdnsb03.raleigh.mebs.ihost.com.]!
Stealth nameservers are leaked [rtpussxdnsb04.raleigh.mebs.ihost.com.]!
This can cause some serious problems (especially if there is a TTL
discrepancy). If you must have stealth NS records (NS records listed at the
authoritative DNS servers, but not the parent DNS servers), you should make
sure that your DNS server does not leak the stealth NS records in response to
other queries.
4) WARNING: Your SOA (Start of Authority) record states that your master
(primary) name server is: rtpussxdnsb03.raleigh.mebs.ihost.com.. However,
that server is not listed at the parent servers as one of your NS records!
This is probably legal, but you should be sure that you know what you are
doing.
5) ERROR: I could not complete a connection to one or more of your
mailservers:
fdsmail01.fds.com: Timed out [Last data sent: [Did not connect]]
fdsmail02.fds.com: Timed out [Last data sent: [Did not connect]]
6) WARNING: One or more of your mailservers is claiming to be a host other
than what it really is (the SMTP greeting should be a 3-digit code, followed
by a space or a dash, then the host name). If your mailserver sends out
E-mail using this domain in its EHLO or HELO, your E-mail might get blocked
by anti-spam software. This is also a technical violation of RFC821 4.3 (and
RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have
an A record pointing back to the same server. Note that this one test may use
a cached DNS record.
mail4.mayco.com claims to be invalid hostname
'******0*******************************':
220 ******0*******************************
7) WARNING: One or more of your mailservers does not accept mail in the
domain literal format (user@[0.0.0.0]). Mailservers are technically required
RFC1123 5.2.17 to accept mail to domain literals for any of its IP addresses.
Not accepting domain literals can make it more difficult to test your
mailserver, and can prevent you from receiving E-mail from people reporting
problems with your mailserver. However, it is unlikely that any problems will
occur if the domain literals are not accepted (mailservers at many common
large domains have this problem).
mail4.mayco.com's postmaster@[68.93.211.14] response:
>>> RCPT TO:<postmaster@[68.93.211.14]>
<<< 554 <postmaster@[68.93.211.14]>: Relay access denied
8) ERROR: I couldn't find any A records for www.macys.com. If you want a
website at www.macys.com, you will need an A record for www.macys.com. If you
do not want a website at www.macys.com, you can ignore this error.
> Old news. dnscache is insufficiently robust in chasing legal but
> complicated DNS chains such as those used by Akamai. DJB has refused to
> address the issue, claiming that despite the fact that Akamai-hosted
> sites are perfectly resolvable for hundreds of millions of users through
> BIND, MS-DNS, maradns, nominum CNS, and powerdns, there is nothing wrong
> with dnscache and its inability to follow these chains is not a problem.
>
> Welcome to Dan Bernstein. google dnscache+akamai for more details.
How far do want want to go to 'compensate for' someones broken design and
implementation of DNS records ?
You could hand out CNAME's and referals to every domain in the world
e.g. .us, .biz, .to, .uk in a merry circle.
The whole point of DNS is like a telephone book - name:number. If I want to
look up an Atlanta (GA) number, I don't expect to get referred to an
anchorage (AK) telephone directory. (yes, I know that's simplistic (and you
can do that in DNS) but I'm trying to make a pertinent point about keeping it
simple).
Name servers should only respond to requests that they are authoritative for.
If they are authoritative, they should provide glue (IP address) for
delegations/other name servers. (They have to be 'in-baliwick' to do this.)
I'm not sure about the others, but Bind installations usually have the
resolver and authoritative DNS together (against their own documented
recommendations) so when it gives out a glueless referral, a second request
will give out the IP even if it isn't authoritative for that domain or tree
branch (ie. if the DNS is in the .com, Bind will give out IP's for DNS
in .net if it has them in it's cache). That's how it short-circuits the
authoritative lookups it is supposed to be doing.
The 100 limit is there to prevent loops or chain reactions as per Section
4.3.3 of RFC 1034, Section 7.1 of RFC 1035 and Section 6.1.3.3 of RFC 1123
Security issues (cache poisoning, stale records, lame delegations), open
resolvers issuing non-authoritative records, and caches accepting them are
all problems.
The www.macy.com DNS setup is a convoluted mess and broken in several
places. This can be easily fixed. Perhaps
people should email them and ask them to fix it ;-)
--
Regards...Martin
|