Bind 9, Wildcard Records and Road Runner
Anthony Eden
My name is Anthony Eden and I work for SDC Hawaii, LLC. Our client,
Saipan DataCom, is the registry for the .mp ccTLD. We are
currently preparing for the public launch of the .mp domain and are
having some issues with Bind 9, wildcard records and Time Warner's Road
Runner service, which hopefully you may be able to help us out with.
A little information on the .mp domain and the dotMP service. A portion
of Saipan DataCom's service includes a complete end-to-end solution for
web publishing. Customers purchase a dotMP site and recieve a .mp
second-level domain, a hosted web site and mobile site, email, blogging,
photo uploads, etc. You can view any .mp site on both your desktop
browser and on your mobile phone.
When a .mp domain is registered their site and associated services are
automatically created and are immediately available for the customers
use. We accomplish this by using a wildcard DNS record in bind for all
.mp domains:
*.mp. IN A 66.135.225.102
This record can be found in the mp zone file. When a site doesn't exist
they still see a page displaying a message.
For most ISPs this works perfectly. You can visit any dotMP site and it
will resolve on both your computer and mobile phone. You can take a
look at ai.mp for an example. In the past this also worked for Road
Runner. However, recently it stopped working for Road Runner and thus
anyone who uses Road Runner for their ISP can not resolve any .mp domain.
Our current understanding is that Road Runner is not caching and
returning these records because there is no SOA record for each SLD.
This is true.
If you look up the SOA record for ai.mp with nslookup you will see:
> ai.mp
Server: 66.135.224.91
Address: 66.135.224.91#53
*** Can't find ai.mp: No answer
However a lookup of the A record for ai.mp will return:
> ai.mp
Server: 66.135.224.91
Address: 66.135.224.91#53
Non-authoritative answer:
Name: ai.mp
Address: 66.135.225.102
If you look up the SOA record for ai.mp with dig you will see:
; <<>> DiG 9.2.1 <<>> -t soa ai.mp
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34794
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ai.mp. IN SOA
;; AUTHORITY SECTION:
mp. 43200 IN SOA ns1.nic.mp.
hostmaster.nic.mp. 2004082401 3600 3600 1209600 43200
;; Query time: 235 msec
;; SERVER: 66.135.224.91#53(66.135.224.91)
;; WHEN: Fri Oct 8 16:29:34 2004
;; MSG SIZE rcvd: 78
We have tried working around this by using a wildcard in front of the
SOA record, but both * and *. failed, so we are looking for other
possible solutions.
Is it proper that Road Runner seems to require an SOA record for any
host in the .mp domain? Is there any way to have bind return an SOA
record for all hosts in the .mp domain without having to set up a zone
file for each SLD? If all else fails would it be possible to modify
bind to have it return the same SOA record for every .mp request?
Any help on this would be greatly appriciated. If you can point me to
an archived discussion which may help solve this problem then I would be
happy to look into that as well.
Thank you for your time.
Sincerely,
Anthony Eden
Jim Reid
Anthony> When a .mp domain is registered their site and associated
Anthony> services are automatically created and are immediately
Anthony> available for the customers use. We accomplish this by
Anthony> using a wildcard DNS record in bind for all .mp domains:
Anthony> *.mp. IN A 66.135.225.102
Anthony> This record can be found in the mp zone file.
You should remove this wildcard RR. It is dangerous and evil. You'll
be repeating the Verisign SiteFinder debacle. The IAB document
"Architectural Concerns on the Use of DNS Wildcards" provides a very
good explanation of the problem space and why this use of wildcards is
usually a Very Bad Idea. It's at
http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
A careful study of the ICANN pages on SiteFinder is also strongly
recommended. Start at:
http://www.icann.org/topics/wildcard-history.html.
Pay particular attention to the Security & Stability Committee's
report and recommendations on this incident. The Internet Community
comments show some of the very real problems that were created by the
addition of a wildcard RR in a TLD. The SECSAC report has lots more
detail on these problems. Repeating these troubles in .mp -- or any
other TLD for that matter -- would be Bad News.
Yes, a few TLDs have wildcard RRs in them. In some cases these exist
because of legacy issues. In others, they are for well-understood
purposes. That does not mean it's OK to just add one to .mp. You
should consult widely on this and check with ICANN before proceeding.
Anthony> For most ISPs this works perfectly. You can visit any
Anthony> dotMP site and it will resolve on both your computer and
Anthony> mobile phone.
Many DNS administrators use the delegation-only feature of BIND9 to
ignore wildcard records in a TLD zone. Consult the BIND documentation
for more details. My guess is Road Runner is one ISP who uses this
feature. There are bound to be many others. You would probably have to
convince everyone using this feature to switch it off for .mp. Which
is highly unlikely even if it was logistically possible for you to
contact every DNS administrator on the planet who uses BIND. So you end
up with an unstable and inconsistent TLD. For some parts of the world,
.mp won't behave the way you want it to. Users are likely to perceive
this as a problem with the TLD (ie you). They won't blame their ISP
who has deployed defensive measures against wildcards in TLDs, like
the BIND delegation-only feature. In fact your comments about Road
Runner customers suggests this appears to already have happened.
This wildcard record will probably create many more problems than it
solves. For new registrations, the wildcard will work for some
users. For some definition of work. For many others -- like spam
filtering, privacy, misaddressed email, web browsing, error detection,
etc -- this wildcard will break things. Remember the wildcard will
match any non-existent name from any application that makes a DNS
query in .mp. Those won't just come from users typing URLs into their
web browsers who then want to register that name.
Paul Vixie
> ...
> When a .mp domain is registered their site and associated services are
> automatically created and are immediately available for the customers
> use. We accomplish this by using a wildcard DNS record in bind for all
> .mp domains:
>
> *.mp. IN A 66.135.225.102
>
> This record can be found in the mp zone file. When a site doesn't exist
> they still see a page displaying a message.
you don't need a wildcard for this, and some recent widely deployed changes
will keep it from working reliably in a tld, in any case. use ddns.
--
Paul Vixie
Anthony Eden
I am concerned that ddns will not suffice. As it stands we would need
to add an RR for each host added to the system (for example, we would
add an RR for ai.mp). The problem is that there would still be no SOA
for each host, if I understand correctly. Please correct me if I am
wrong. I am under the impression that the use of wildcards is filtered
by looking for a corresponding SOA and thus if we appended RRs to the
.mp zone file then we would still end up with no SOA, is this correct?
Perhaps you can briefly explain how ddns would help?
Sincerely,
Anthony Eden
Paul Vixie wrote:
> Anthony Eden <ant...@sdc-hawaii.co.mp> writes:
>
>
>>...
>>When a .mp domain is registered their site and associated services are
>>automatically created and are immediately available for the customers
>>use. We accomplish this by using a wildcard DNS record in bind for all
>>.mp domains:
>>
>>*.mp. IN A 66.135.225.102
>>
>>This record can be found in the mp zone file. When a site doesn't exist
>>they still see a page displaying a message.
>
>
Paul Vixie
> add an RR for each host added to the system (for example, we would add an
> RR for ai.mp). The problem is that there would still be no SOA for each
> host, if I understand correctly. Please correct me if I am wrong. I am
> under the impression that the use of wildcards is filtered by looking for
> a corresponding SOA and thus if we appended RRs to the .mp zone file then
> we would still end up with no SOA, is this correct?
technically, that's not correct. effectively, that's pretty close.
> Perhaps you can briefly explain how ddns would help?
currently widely deployed dns filtering technology insists that all responses
from a TLD zone's authority server be delegations (empty answer section,
nonempty authority and additional sections). this filtering is controversial
since it keeps any TLD zone from having its own content, it can only delegate.
your supposition about SOA is not completely without merit, since an SOA RR
will appear "under" the delegation point pointed to by the TLD server's
response. so, in effect, there does have to be an SOA, it's just that it
doesn't appear in the TLD zone, and so, is a secondary consideration with
regard to the widely deployed DNS filtering that's affecting your plans.
using ddns, you can create new child zone delegation points. therefore if
your registry process included the following steps, it would have the
effect of allowing near-instantaneous appearance of new subdomains (which
you can interpret as "new url's whose domain-part ends in .MP") without the
use of wildcards and without running into the widely deployed DNS filtering
(which goes by the name of "BIND's delegation-only option").
1. a new subdomain is to be created, $FOO.MP.
2. append a new "zone" directive to the end of your named.conf file, using
a shared primary zone file, such that new subdomains have known content.
3. use "rndc reconfig" to cause new zone to be loaded and served.
4. use "nsupdate" (for DDNS, see RFC2136) to add new NS RRs to "MP" zone.
that's it. the whole process takes less than one second, and is fully
automated, fully secure, uses no wildcards, and encounters no filtering.
it will work on BIND9 (preferred) or BIND8 (if you must; use ndc rather
than rndc in this case).
note that this is a BIND-specific solution, but then this is a BIND-specific
forum (either bind-users@, or comp.protocols.dns.bind, depending on one's
point of view.)
re:
> >>When a .mp domain is registered their site and associated services are
> >>automatically created and are immediately available for the customers
> >>use. We accomplish this by using a wildcard DNS record in bind for all
> >>.mp domains:
> >>
> >>*.mp. IN A 66.135.225.102
> >>
> >>This record can be found in the mp zone file. When a site doesn't exist
> >>they still see a page displaying a message.
> >
> > you don't need a wildcard for this, and some recent widely deployed changes
> > will keep it from working reliably in a tld, in any case. use ddns.
--
Paul Vixie
Anthony Eden
Paul Vixie wrote:
<snip>
>
> using ddns, you can create new child zone delegation points. therefore if
> your registry process included the following steps, it would have the
> effect of allowing near-instantaneous appearance of new subdomains (which
> you can interpret as "new url's whose domain-part ends in .MP") without the
> use of wildcards and without running into the widely deployed DNS filtering
> (which goes by the name of "BIND's delegation-only option").
>
> 1. a new subdomain is to be created, $FOO.MP.
> 2. append a new "zone" directive to the end of your named.conf file, using
> a shared primary zone file, such that new subdomains have known content.
> 3. use "rndc reconfig" to cause new zone to be loaded and served.
> 4. use "nsupdate" (for DDNS, see RFC2136) to add new NS RRs to "MP" zone.
>
> that's it. the whole process takes less than one second, and is fully
> automated, fully secure, uses no wildcards, and encounters no filtering.
> it will work on BIND9 (preferred) or BIND8 (if you must; use ndc rather
> than rndc in this case).
So even with a very large number of zones (hundreds of thousands, if not
millions) this process would still take less than a second? We are
using Bind 9.
>
> note that this is a BIND-specific solution, but then this is a BIND-specific
> forum (either bind-users@, or comp.protocols.dns.bind, depending on one's
> point of view.)
Of course, and since we are using Bind that makes sense. :-)
Sincerely,
Anthony Eden
Paul Vixie
> > automated, fully secure, uses no wildcards, and encounters no
> > filtering. it will work on BIND9 (preferred) or BIND8 (if you must;
> > use ndc rather than rndc in this case).
>
> So even with a very large number of zones (hundreds of thousands, if not
> millions) this process would still take less than a second? We are using
> Bind 9.
regrettably, it will get slower as you get beyond 10000 to 20000 zones, and
even getting that far will require segmentation of your named.conf file into
"include" files. you'd need DLZ, which is going to be integrated into bind9
in the near future, but which is available as a patch for current versions.
rob butler created DLZ under a grant from Stichting NLNet. the patch is
available from them, at <http://www.nlnet.nl/project/bind-dlz/>.
--
Paul Vixie
Mark Foster
If the wcard draft is standardized, records like
www.*.mp. IN A 66.135.225.102
become acceptable, true?
Jonathan de Boyne Pollard
MF> www.*.mp. IN A 66.135.225.102
MF> become acceptable, true?
False. They don't _become_ acceptable. The _already are_ acceptable.
They just don't do what you, no doubt conditioned by all of those
softwares that use wildmat(), think that they do. But then this is true
of wildcards (in DNS) in general. They don't do what people expect them
to do. *Every* DNS server software deviates from the RFC 1034 algorithm
in one respect or other when it comes to wildcards. And they all do so
in the name of doing what the users actually expect wildcards to do.
(One DNS server software, Microsoft's, even does what people expect,
rather than what the RFC 1034 algorithm dictates, with respect to "MX"
resource record sets and wildcards.)
The irony, of course, is that there is no universal agreement amongst
DNS server softwares on how wildcards *should* work. They each deviate
from the RFC 1034 algorithm in different ways. (Microsoft's DNS server
and MaraDNS both also look for wildcards when they find empty resource
record sets. ISC's BIND processes alias chains when it encounters
wildcard "CNAME" resource records. Dan Bernstein's "djbdns" allows
wildcards to match leaf nodes even when interior nodes for enclosing
superdomains exist.)
The wildcard clarification is not yet ready for standardization,
incidentally. It currently contains a few errors.
Jonathan de Boyne Pollard
PV> note that this is a BIND-specific solution, [...]
AE> So even with a very large number of zones (hundreds of thousands,
AE> if not millions) this process would still take less than a second?
PV> regrettably, it will get slower as you get beyond 10000 to 20000
PV> zones, and even getting that far will require segmentation of your
PV> named.conf file into "include" files. you'd need DLZ, [...]
... or one of those non-BIND solutions that you studiously avoided
mentioning, such as "djbdns", PowerDNS, MaraDNS, NSD, and so forth,
which don't have the problems of having to parse tens of thousands of
zone files. (Anthony might be interested to learn that not all TLDs use
BIND, by the way. I know of one TLD that uses "djbdns", for example.)
Don't believe the blurb on the DLZ website, by the way. It paints a
grossly distorted picture in order to make itself look good. The
non-BIND solutions are far from "basic", and support all of the resource
records that BIND does. And as I mentioned, they are in wide use in
equivalent situations. Always be suspicious of something or someone
that chants the "BIND is the standard." mantra, as the DLZ blurb does.
BIND, as the ISC's own web site clearly states, is a *reference
implementation*. That's not the same as a standard.
p...@icke-reklam.ipsec.nu
Jonathan,
why don't you start marketing in your own forum, thus letting
us bind-conformant geeks rest in piece ??
I'm shure you will get less resistance somewhere else, i'm just
starting to find it tiresome hearing wou spreading FUD ( don't
take this personally, i fully respect your rights to have an
opinion, even an opinion that differs from mine. But in a forum
dedicated to item X i find it distrurbing to find advocates
that time after time advocates for item Y. If i respect Your rights
of a differing opinion, please respect my rights to "feel at home"
with my fellow "mates")
I hope we might meet over a beer sometime, that would be a better
environment to discuss our diverting opinions. I'll pay the bill!
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
Bruce Campbell
> zone files. (Anthony might be interested to learn that not all TLDs use
> BIND, by the way. I know of one TLD that uses "djbdns", for example.)
( Anthony's TLD, 'mp', now uses PowerDNS )
Of the 258 TLDs at the moment, 245 of them use BIND for one or more of
their listed nameservers, leaving 13 that don't use BIND at all.
As of last night, here are the easily-detectable nameserver versions and
the count of TLDs in which they are used. The popularity of BIND may be
of small interest to the bind-users list.
Number
of
Nameserver ID TLDs TLDs using, _in part_
- - -
incognito DNS Commander 1 AQ (1/4)
MaraDNS 1 TP (1/7)
MyDNS 1 PRO (3/3)
totd 1 VA (1/7)
ATLAS 2 COM (13/13), NET (13/13)
PowerDNS 2 MP (2/2), TK (1+/3)
Windows 4 CR, FM, GM, JM
TinyDNS (djbdns) 8 BF, CH, DK, GL, GOV, IM (2/2), LI, LV
Bind 4 15
UltraDNS 21
NSD 23
Bind 8 160
Bind 9 223
( Note that a given nameserver may serve multiple TLDs, and a small number
of nameservers were not able to be detected by Roy's tool. )
--==--
Bruce.
Stephane Bortzmeyer
Bruce Campbell <bruce.c...@ripe.net> wrote
> Of the 258 TLDs at the moment, 245 of them use BIND for one or more
> of their listed nameservers,
Remember that most ccTLD have at least one secondary nameserver they
do not control (for resiliency) so the choice is not completely in
their hands.
> NSD 23
...
> ( Note that a given nameserver may serve multiple TLDs,
Indeed, when we switched ns2.nic.fr from BIND to NSD, we changed the
statistics a lot :-)
Stephane Bortzmeyer
Bruce Campbell <bruce.c...@ripe.net> wrote
a message of 38 lines which said:
> ( Note that a given nameserver may serve multiple TLDs,
Here is the same count, but per nameserver and not per-TLD. There are
803 nameservers in the TLDs.
BIND 9 410
BIND 8 236
Unknown 62
UltraDNS 16
ATLAS 12
BIND 4 11
NSD 10
TinyDNS 9
Microsoft 4
PowerDNS 2
MyDNS 2
q 1
MaraDNS 0
totd 0
incognito 0
Jonathan de Boyne Pollard
JdeBP> use BIND, by the way. I know of one TLD that uses
JdeBP> "djbdns", for example.)
BC> ( Anthony's TLD, 'mp', now uses PowerDNS )
I know. I've been watching his foray into the world of PowerDNS. I don't know
whether he decided to try it before or after he read what I posted. (What's
particulary interesting is that he's trying to configure it to do *exactly*
what I said, last year, a TLD registry, such as Verisign, could do to thwart
the flawed "delegation-only" mechanism. I am waiting to see whether he achieves
it.)
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-coup.html#Resistance>
BC> ( Note that a given nameserver may serve multiple TLDs, [...] )
So a breakdown by number of distinct server IP addresses (not server
names), in addition to the one by number of TLDs, might be a good idea.
Stephane Bortzmeyer
Jonathan de Boyne Pollard <J.deBoyn...@Tesco.NET> wrote
> So a breakdown by number of distinct server IP addresses (not server
> names), in addition to the one by number of TLDs, might be a good idea.
Ask and Thou Shalt receive. But there is little difference between
server names and IP addresses, very few TLD name servers have several
addresses for a name, or the opposite (this is mostly for TLD which
compress their set of NS).
BIND 9 429
BIND 8 293
Unknown 58
UltraDNS 16
ATLAS 14
BIND 4 11
NSD 9
TinyDNS 9
Microsoft 3
MyDNS 3
PowerDNS 2
q 2
MaraDNS 1
totd 0
incognito 0
Barry Margolin
Stephane Bortzmeyer <bortz...@nic.fr> wrote:
> On Thu, Nov 18, 2004 at 04:44:22AM +0000,
> Jonathan de Boyne Pollard <J.deBoyn...@Tesco.NET> wrote
> a message of 19 lines which said:
>
> > So a breakdown by number of distinct server IP addresses (not server
> > names), in addition to the one by number of TLDs, might be a good idea.
>
> Ask and Thou Shalt receive. But there is little difference between
> server names and IP addresses, very few TLD name servers have several
> addresses for a name, or the opposite (this is mostly for TLD which
> compress their set of NS).
Don't some of the root and/or TLD servers make use of anycast, so one IP
corresponds to multiple servers?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Stephane Bortzmeyer
Barry Margolin <bar...@alum.mit.edu> wrote
> Don't some of the root and/or TLD servers make use of anycast, so
> one IP corresponds to multiple servers?
While you can find out how many addresses are for a name, you cannot
easily see how many servers are for an address (there is
www.root-servers.org for the root nameservers).
And I assume that *all* instances of an anycasted server run the same
software. (I admit it may not be always true.)