A possible tweak to res_hnok to protect against barmy nameservers

Ted_Rule at flextech.co.uk Ted_Rule at flextech.co.uk
Tue Nov 9 12:46:49 UTC 1999



See attached Email below for where this saga started.

Basically NS.ZF.NET is returning Additional Records of the form

     .    0S   IN   A    0.0.0.0

I strongly suspect that the reason behind this is a partially configured name
server, where all fields
in the Zone which haven't been filled in are filled with nuls. When translated
into a real DNS
Response Packet, this leads to A records pointing to 0.0.0.0 for hostnames of
".", with a TTL of
0 seconds.

Since this seems to me to be a highly suspect configuration, whose contents
ought to be prevented from
propagating at the earliest opportunity, I'm suggesting a modification to
res_hnok() to catch any attempt
to encode an A record in the root domain itself. Since such an A record is
surely never going to exist, this
trap should never reject any valid responses? At present, judging by the fact
that dig returns the records
at all, the existing res_hnok() is not catching this odd bit of barminess in the
name format.

I can't honestly remember whether - at this point in the code - *dn points at ""
for the root domain or "."
for the root domain. ( Probably the former ). In which case the existing code
below:

     /usr/src/bind/bind-8.2.2-rel/src/lib/resolv/res_comp.c

int
res_hnok(const char *dn) {
        int ppch = '\0', pch = PERIOD, ch = *dn++;

        while (ch != '\0') {
                int nch = *dn++;

                if (periodchar(ch)) {
                        (void)NULL;
                } else if (periodchar(pch)) {
                        if (!borderchar(ch))
                                return (0);
                } else if (periodchar(nch) || nch == '\0') {
                        if (!borderchar(ch))
                                return (0);
                } else {
                        if (!middlechar(ch))
                                return (0);
                }
                ppch = pch, pch = ch, ch = nch;
        }
        return (1);
}


Could be changed to:

int
res_hnok(const char *dn) {
        int ppch = '\0', pch = PERIOD, ch = *dn++;

        if ( ch == '\0' )
     return (0);    /** Additional root trap **/

        while (ch != '\0') {
                int nch = *dn++;

                if (periodchar(ch)) {
                        (void)NULL;
                } else if (periodchar(pch)) {
                        if (!borderchar(ch))
                                return (0);
                } else if (periodchar(nch) || nch == '\0') {
                        if (!borderchar(ch))
                                return (0);
                } else {
                        if (!middlechar(ch))
                                return (0);
                }
                ppch = pch, pch = ch, ch = nch;
        }
        return (1);
}






Ted Rule
03/11/99 13:59

To:   BMEGA at PACBELL.NET, AMEGA at PACBELL.NET, hostmaster at zf.net
cc:   dnsmaster at flextech.co.uk

Subject:  HOITMAIL.COM and ZF.NET

I've noticed a couple of Mail Bounces recently related to subtle misspellings of
HOTMAIL.COM

The most recent involved HOITMAIL.COM, which sat undelivered for several days
before being
auto-bounced by our Internet Mail Relay.

Investigating further, we find many many things wrong with this domain and its
owner.

The .com servers list ns.zf.net and dns.zf.net as NS records, but whilst both
these servers declare themselves
authoratitive for the zone, neither give out an SOA record. Both declare the
non-existent host 0.0.0.0 as the next
most valid NS record, which is barmy. Both list this non-existent host with a
host A record of ".", which is even
barmier. The NS and A records for these items have TTLs of zero seconds, which
is also stupid, but given that
the records themselves are stupid, this is perhaps a good thing!

The ZF.NET domain, which supposedly hosts the name servers for HOITMAIL.COM, has
a Zone Expiry Timer
5 minutes greater than the  refresh/retry timers, which is fairly stupid.

The supposed A record for hoitmail,com doesn't answer SMTP port requests.

If it is intended to make the zone an auto-bounce for hotmail.com, it would have
been better to create
a real zone with a real set of SOA and NS records but NO MX or A records - SMTP
MTA's would then have declared
the Mail Domain unreachable. As it stands, it's a complete mess.

The SMTP MTA and/or the local DNS server here might have been able to make a
better stab at rejecting
mail bound for this broken zone by declaring any zone without a valid SOA as
invalid, but this is not necessarily
part of the DNS standards.

If someone would care to investigate all these misconfigurations, I'd be more
than happy to hear the outcome.

Various diagnostics shown below.


Ted Rule,
Flextech Television




$ dig @dns.zf.net  hoitmail.com any

; <<>> DiG 8.2 <<>> @dns.zf.net hoitmail.com any
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;;      hoitmail.com, type = ANY, class = IN

;; ANSWER SECTION:
hoitmail.com.           23h53m20s IN A  209.241.185.109

;; AUTHORITY SECTION:
.                       0S IN NS        .

;; ADDITIONAL SECTION:
.                       0S IN A         0.0.0.0

;; Total query time: 196 msec
;; FROM: homer.flextech.co.uk to SERVER: dns.zf.net  216.102.246.43
;; WHEN: Wed Nov  3 13:32:59 1999
;; MSG SIZE  sent: 30  rcvd: 73


$ dig @dns.zf.net  hoitmail.com any

; <<>> DiG 8.2 <<>> @dns.zf.net hoitmail.com any
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;;      hoitmail.com, type = ANY, class = IN

;; ANSWER SECTION:
hoitmail.com.           23h53m20s IN A  209.241.185.109

;; AUTHORITY SECTION:
.                       0S IN NS        .

;; ADDITIONAL SECTION:
.                       0S IN A         0.0.0.0

;; Total query time: 241 msec
;; FROM: homer.flextech.co.uk to SERVER: dns.zf.net  216.102.246.43
;; WHEN: Wed Nov  3 13:35:03 1999
;; MSG SIZE  sent: 30  rcvd: 73

$ dig  hoitmail.com any

; <<>> DiG 8.2 <<>> hoitmail.com any
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;      hoitmail.com, type = ANY, class = IN

;; ANSWER SECTION:
hoitmail.com.           21h33m50s IN NS  NS.ZF.NET.
hoitmail.com.           21h33m50s IN NS  DNS.ZF.NET.
hoitmail.com.           22h19m55s IN A  209.241.185.109

;; AUTHORITY SECTION:
hoitmail.com.           21h33m50s IN NS  NS.ZF.NET.
hoitmail.com.           21h33m50s IN NS  DNS.ZF.NET.

;; ADDITIONAL SECTION:
NS.ZF.NET.              5h38m10s IN A   209.241.185.37
DNS.ZF.NET.             4h20m59s IN A   216.102.246.43

;; Total query time: 8 msec
;; FROM: homer.flextech.co.uk to SERVER: default -- 195.188.171.98
;; WHEN: Wed Nov  3 13:35:12 1999
;; MSG SIZE  sent: 30  rcvd: 147


$ whois zf.net
[rs.internic.net]
The Data in Network Solutions' WHOIS database is provided by Network
Solutions for information purposes, and to assist persons in obtaining
information about or related to a domain name registration record.
Network Solutions does not guarantee its accuracy.  By submitting a
WHOIS query, you agree that you will use this Data only for lawful
purposes and that, under no circumstances will you use this Data to:
(1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail
(spam); or  (2) enable high volume, automated, electronic processes
that apply to Network Solutions (or its systems).  Network Solutions
reserves the right to modify these terms at any time.  By submitting
this query, you agree to abide by this policy.

Registrant:
ZF-NET (ZF12-DOM)
   914 Westwood Blvd. #177
   Los Angeles, CA 90024
   US

   Domain Name: ZF.NET

   Administrative Contact:
      HOSTMASTER  (HO1243-ORG)  BMEGA at PACBELL.NET
      3102036699
   Technical Contact, Zone Contact:
      AMEGA  (AM1039-ORG)  AMEGA at PACBELL.NET
      3102036699
   Billing Contact:
      CABILLING  (CA1050-ORG)  CYBERAMY at AOL.COM
      3102036699

   Record last updated on 05-Mar-1999.
   Record created on 23-Jul-1998.
   Database last updated on 2-Nov-1999 06:36:17 EST.

   Domain servers in listed order:

   NS.ZF.NET                    209.241.185.37
   DNS.ZF.NET                   216.102.246.43

$ dig @ns.zf.net zf.net any

; <<>> DiG 8.2 <<>> @ns.zf.net zf.net any
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;;      zf.net, type = ANY, class = IN

;; ANSWER SECTION:
zf.net.                 23h53m20s IN SOA  ns.zf.net. hostmaster.zf.net. (
                                        7               ; serial
                                        23h53m20s       ; refresh
                                        23h53m20s       ; retry
                                        1D              ; expiry
                                        23h53m20s )     ; minimum

zf.net.                 23h53m20s IN A  216.102.246.25

;; AUTHORITY SECTION:
.                       0S IN NS        .

;; ADDITIONAL SECTION:
.                       0S IN A         0.0.0.0

;; Total query time: 560 msec
;; FROM: homer.flextech.co.uk to SERVER: ns.zf.net  209.241.185.37
;; WHEN: Wed Nov  3 13:38:45 1999
;; MSG SIZE  sent: 24  rcvd: 117

[itadmin at homer itadmin]$


*****************************************************************
This E-mail message, (including any attachments), is intended
only for the person or entity to which it is addressed,
and may contain confidential information.

If you are not the intended recipient, any review, retransmission,
disclosure, copying, modification or other use of this E-mail message
or attachments is strictly forbidden.

If you have received this E-mail message in error, please contact the
author and delete the message and any attachments from your computer.

You are also advised that the views and opinions expressed in this E-mail
message and any attachments are the author's own, and may not reflect the
views and opinions of FLEXTECH Television.
*****************************************************************



More information about the bind-workers mailing list