[Top] [All Lists]

Re: new DNS classes

2017-07-08 20:59:41

In message 
<EDFEF9A1-99CF-4F25-9C1C-051E78949967(_at_)qti(_dot_)qualcomm(_dot_)com>, Pete 
k writes:
On 7 Jul 2017, at 19:18, Mark Andrews wrote:

In message 
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, 
CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in 
BIND configs that underly their implementation. And at that point I 
"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 
exercise for each individual implementer. (Yes, I know about
draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.) 
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

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

Pete Resnick <>
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

<Prev in Thread] Current Thread [Next in Thread>