NS pointing to CNAME illegal?
David Lowe
People -
I recently ran into a problem with getting a SERVFAIL result from trying
to resolve a domain name. Since the domain name existed, and querying the
server directly was working fine, I poked around to try to see what was
up. The only strangeness I could come up with was that the authoritative
nameservers for the domain in question were pointing to CNAMEs.
The resolver is running BIND 8.1.1 - and I do, with CNAME logging enabled,
get:
Sep 10 16:28:58 XXX named[7996]: ns_resp: query(www.XXXXXX.com) NS points
to CNAME (NS.XXXXXX.COM:) learnt (CNAME=XXXXXX.com:NS=XXX.XX.XX.XX)
So I have a few questions:
1. Is NS -> CNAME "illegal" per RFC 1035?
2. Is enforcement of this new to the latest BIND versions? Some random
servers I tested were able to correctly resolve addresses in this domain.
(Just lucky?)
3. This strangeness isn't mentioned in the O'Reilly book, that I could
find... is it in there?
Thanks for any insight you might be able to provide,
David Lowe
Don Lewis
On Sep 11, 1:27am, David Lowe wrote:
} Subject: NS pointing to CNAME illegal?
} People -
}
} I recently ran into a problem with getting a SERVFAIL result from trying
} to resolve a domain name. Since the domain name existed, and querying the
} server directly was working fine, I poked around to try to see what was
} up. The only strangeness I could come up with was that the authoritative
} nameservers for the domain in question were pointing to CNAMEs.
}
} The resolver is running BIND 8.1.1 - and I do, with CNAME logging enabled,
} get:
}
} Sep 10 16:28:58 XXX named[7996]: ns_resp: query(www.XXXXXX.com) NS points
} to CNAME (NS.XXXXXX.COM:) learnt (CNAME=XXXXXX.com:NS=XXX.XX.XX.XX)
}
} So I have a few questions:
}
} 1. Is NS -> CNAME "illegal" per RFC 1035?
RFC 1034 says:
Domain names in RRs which point at another name should always point at
the primary name and not the alias.
I believe this RFC dates from before the time that RFCs started
distinguishing between should and must. For instance it also says:
If a CNAME RR is present at a node, no other data should be
present;
and it's pretty widely agreed this is illegal.
} 2. Is enforcement of this new to the latest BIND versions?
BIND has never followed CNAME RRs that are referenced by NS RRs. Older
versions of BIND (4.8.3 and earlier) would silently melt your network wires
if they encountered this situation, and would probably either time out
the query or eventually return SERVFAIL. Early versions of 4.9 silently
ignored any NS RRs that pointed to CNAME RRs, and if they couldn't find
a responsive server amoung those NS RRs that remained, they would return
a SERVFAIL response. The most recent versions of 4.9.x added diagnostic
logging so that you know why you're getting a SERVFAIL response so that
you can either fix the problem yourself or you can figure out who to
yell at to fix the problem.
} Some random
} servers I tested were able to correctly resolve addresses in this domain.
} (Just lucky?)
You were lucky. It is possible for this to intermittently work if other
rules are broken. Typically, someone will register my.domain with the NIC
and will tell the NIC that the name server is ns.my.domain, and the address
of that server is 10.11.12.13. In the actual zone file for my.domain,
they'll have:
IN NS ns.my.domain.
ns IN CNAME foobar.my.domain.
foobar IN A 10.11.12.13
This isn't legal, because the authoritative data for ns.my.domain in the
my.domain zone file doesn't match the glue data in the zone above, and
because the authoritative RR is a CNAME it can't even coexist with the
the glue A RR. It will work, but only intermittently. When a server
with an empty cache first makes a query for somehost.my.domain, it forwards
this query to either the root servers or the server for domain. The response
will be a delegation containing:
my.domain. IN NS ns.my.domain.
in the authority section, and
ns.my.domain. IN A 10.11.12.13
in the additional data section. The server would cache this information
resend the query to 10.11.12.13 from which it would get the final answer.
The problem comes when the A RR for ns.my.domain times out. When the
server sends out a query to refresh the A RR, it may send it to a server
that has an authoritative copy of the my.domain zone from which it will get
the CNAME in response. From that point on, the server will not send queries
to 10.11.12.13 until the CNAME RR times out.
If you think that pointing NS RRs at CNAME RRs should be legalized and
that BIND should be fixed, there are some problems:
There will be an increase in DNS traffic due to a greater need
to follow CNAME RRs.
You may need to use glue CNAME RRs as well as glue A RRs in
parent zones.
For efficiency, additional data processing may need to be modified
to follow CNAME chains. The RFCs only mention looking for A RRs.
(RFC 1035 - NS records cause both the usual additional section
processing to locate a type A record)
This makes a part of BIND that is already incredibly nasty much worse.
An increased probability that you could get into situations where a
query will deadlock because it doesn't have enough information on
how to proceed and also doesn't know where to get that information.
--- Truck
Steve Sobol
>
>1. Is NS -> CNAME "illegal" per RFC 1035?
Yes
>2. Is enforcement of this new to the latest BIND versions? Some random
>servers I tested were able to correctly resolve addresses in this domain.
>(Just lucky?)
The older servers recognized it as illegal, but I don't know if they enforced
it.
>3. This strangeness isn't mentioned in the O'Reilly book, that I could
>find... is it in there?
Yes.
--
NACS.NET ** Steve Sobol (sjsobol @ nacs.net) ** 216 619-2000, 1-888-273-NACS
Cleveland 33.6/K56Flex/ISDN 216 377-1010 Lake County 440 951-8266
Akron 330 762-0734 ** Consulting & Leased Lines ** No Busy Signals!!!
(and if that's not enough, we've got the best people in town!)