In message
<EDFEF9A1-99CF-4F25-9C1C-051E78949967(_at_)qti(_dot_)qualcomm(_dot_)com>, Pete
Resnic
k writes:
On 7 Jul 2017, at 19:18, Mark Andrews wrote:
In message
<A94C17CD-DC4B-43C9-AD3D-69735FC6B2BC(_at_)qti(_dot_)qualcomm(_dot_)com>,
Pete Resnick writes:
On 6 Jul 2017, at 16:52, Mark Andrews wrote:
Or you could stop trying to reinforce the myth that new RR types
are hard to deploy. They really aren't. They actually get used
all the time.
I'm running the latest version of MacOS Server. I can't get a new RR
type into the UI. Even if I use the command line "dnsconfig" tool, I
can't add a record of a type it doesn't know about; I only get A,
AAAA,
CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in
the
BIND configs that underly their implementation. And at that point I
say,
"New RR types are hard to deploy; not a myth." Telling me I can use a
different operating system or not use a validating UI is not a
reasonable response.
Well use nsupdate. That also ships with the Mac.
Of course doing that likely means I'll have records that don't show up
in the server UI. Not entirely thrilling. And I could accomplish exactly
the same thing by directly editing the BIND config files, so I'm not
sure what that gains me in terms of "not hard to deploy".
Given Macs can register their own addresses in the DNS using UPDATE
I doubt that the strawman you are attempting to raise here happens
and if it does log a bug with Apple. Log a bug with Apple that the
tool doesn't support all known types and that it doesn't support
unknown types.
The fact is the DNS doesn't provide a way for implementations to
dynamically update the RR types to provide sensible UI; it's left as
an
exercise for each individual implementer. (Yes, I know about
draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.)
You
can't much complain about the difficulty of deployment when the
community won't provide the tools to make deployment easier.
Well BIND is designed to allow new types to be added easily. It
may require recompiling rather than updating a text file but it is
not beyond people to do because we see people doing just that.
¬(â??ð??¥ð??¶(ð??¥) â?? â??ð??¥ð??¶(ð??¥))
Just because you you see some people recompiling does not mean that all
(or most, or a significant number) can. Set that aside, it is nowhere
near reasonable for knowing how to recompile a piece of code to be
required in order for me to add a new RR type. Set that aside, this is
the epitome of "hard to deploy": Some implementations can't do it at
all, some implementations you have to go hacking around in hidden config
files, and some implementations you have to recompile the binary to get
a reasonable UI experience.
This is the problem with DNS being considered a system service rather
than a user application. It's got both aspects. Until the user
experience for configuring the DNS with a new RR type does not require
the skills of someone able to recompile code, it is absolutely going to
be the case that new RR types are hard to deploy, and calling it a myth
is not helpful.
We supply user applications to manipulate the DNS. Those tools are
capable of updating yet to be defined types. Putting a front end
on those tools that takes the new type someone dreams up is easy.
We also supply C libraries that can do the same thing. No one needs
to wait to use a new type.
There are python and perl tools available that can also send update
messages.
If you just want the new records to be a blob of text a shell script
like this will convert the record to unknown format suitable to be
used by nsupdate.
% sh junk
hello world
\# 11 68656C6C6F20776F726C64
% cat junk
read record
hex=`printf "%s" "$record" | hexdump -ve '/1 "%02X"'`
length=`printf "%s" "$hex" | wc -c`
length=`expr $length / 2`
echo '\#' $length $hex
%
You can create all DNS records similarly. Building them up
field by field.
One can do something similar in any scripting language.
So no it isn't hard to use a new type. You just need to stop waiting
for the stupid DNS hoster to do it for you and organise to do it
yourself.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org