Subject: Re: DNS RRTYPEs, the difficulty with

From: Doug Barton <[email-masked]>
Date: Fri, 02 Mar 2012 01:32:12 -0800

On 02/28/2012 15:06, John R. Levine wrote:
> In your little dialog, the boss was entirely reasonable -- the practical
> benefit from implementing SPF records would be zip.
> 
>> Or, put more simply, your conclusion seems to be that we can never add
>> new RRs. Given that adding new RRs is crucial to the growth of the
>> Internet, I reject that conclusion completely.
> 
> No, I'm saying that it would be a lot more productive to help people
> improve their provisioning systems, rather than say how stupid they are
> for not doing what we want. 

Um, who called anyone stupid? As you pointed out above, the lack of
movement from SPF{TXT} to SPF{SPF} was entirely rational.

My point was that *we* need to learn from our experiences with SPF, and
not do the same things again.

> By the way, what's your opinion of draft-levine-dnsextlang-02?

It isn't clear to me what problem you're trying to solve. For resolving
name servers 3597 should be enough. For authoritative name servers your
idea is sort of interesting, but generally upgrading the software to
pick up support for new RRtypes is a good idea, since you'll also pick
up new security fixes, etc.

Doug

-- 
    If you're never wrong, you're not trying hard enough

---

From: "John R. Levine" <[email-masked]>
Date: 2 Mar 2012 12:00:22 -0500

> up new security fixes, etc.

Oh, wow.  Now I see the problem: people here are totally unaware of what 
using DNS software is like if you're not a DNS weenie.

If you think that it's reasonable to require a new version of your DNS 
software every time there's a new RR, you've conceded total defeat.  On 
most servers I know, software upgrades are risky and infrequent.  It could 
easily take a year for a new version of BIND to percolate out of the lab, 
into the various distribution channels, and to be installed on people's 
servers, by which time everyone has built their applications with TXT 
records and it's too late.

Moreover, the servers aren't the hard part, it's the provisioning systems. 
You and I may edit our zone files with emacs, but civilians use web based 
things with pulldown menus and checkboxes.  If they can't enter an RR into 
one of them it doesn't matter whether the name server supports it or not. 
This latest round of teeth gnashing was provoked by discussions in the 
spfbis WG, where we're wondering whether to deprecate the type 99 SPF 
record.  Among the reasons it's unused in practice is that nobody's 
provisioning system lets you create SPF records.

The point of my draft is that it's an extension language that both name 
servers and provisioning systems can read on the fly.  Add a new stanza to 
/etc/rrtypes and you're done, no software upgrades needed.  The risk is 
much lower since the worst that will happen if the new stanza is broken is 
that the provisioning software and name servers will ignore it, not 
that the whole thing will crash.

Sure, there are some RRs with complex semantics that can't be done without 
new code (DNSSEC being the major example), but most RRs are syntactically 
and semantically trivial, just a bunch of fields that the server doesn't 
even interpret once it's parsed the master records or their equivalent.

Until the DNS crowd admits that provisioning systems are a major 
bottleneck, and telling people to hand-code more types into them isn't 
going to happen, there's no chance of getting more RRs deployed.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Doug Barton <[email-masked]>
Date: Fri, 02 Mar 2012 10:09:47 -0800

> using DNS software is like if you're not a DNS weenie.

Assuming you're the only one with the True WisdomTM is almost always a
bad idea. I stated earlier in the thread that I've done the kinds of
provisioning systems you describe. And I'm not going to throw my resume
at you, but I'm also intimately familiar with DNS at the large
enterprise level.

> most servers I know, software upgrades are risky and infrequent.  It
> could easily take a year for a new version of BIND to percolate out of
> the lab, into the various distribution channels, and to be installed on
> people's servers, by which time everyone has built their applications
> with TXT records and it's too late.

I understand what you're saying, and I've seen this kind of
institutional lethargy in action. My point is that just because this is
a very common situation doesn't make it correct, or even defensible.

We have a longstanding culture of DNS being a set-and-forget service. Us
"DNS weenies" have been the worst offenders in enabling this bad
behavior by trying to be backwards-backwards-backwards compatible with
every new change. Those days are over. And just because properly
updating your software can be difficult doesn't make it the wrong answer.

> Moreover, the servers aren't the hard part, it's the provisioning
> systems. You and I may edit our zone files with emacs, but civilians use
> web based things with pulldown menus and checkboxes.  If they can't
> enter an RR into one of them it doesn't matter whether the name server
> supports it or not.

Yes, I get that bit too.

> servers and provisioning systems can read on the fly.  Add a new stanza
> to /etc/rrtypes and you're done, no software upgrades needed.  The risk
> is much lower since the worst that will happen if the new stanza is
> broken is that the provisioning software and name servers will ignore
> it, not that the whole thing will crash.

So it seems to me that what you're proposing would also cause the need
for changes to be made to the provisioning systems. Or are you
suggesting that the same users who cannot handle anything other than
point and click are suddenly going to be able to enter specially
formatted text strings that they don't understand? And/or that the
people who operate those provisioning systems are going to allow end
users to "Add a new stanza to /etc/rrtypes"?

> going to happen, there's no chance of getting more RRs deployed.

The rest of this discussion is almost certainly more suitable for dnsop,
but I'll say one more time that I disagree with you on this point.
Provisioning systems *are* a bottleneck, no one is disputing that. But
our experience with new TLDs, IPv6 and DNSSEC shows that when there is
user demand for these changes, they get made.

I'll also add one more point based on my experience with DNS
provisioning system UI design, most of what you are trying to accomplish
with your draft on the UI side can be handled with a simple text field
in an HTML form that allows the user to enter free-form stuff that is
then checked for syntax errors and loaded if the name server software
supports the record. I realize that we disagree on right solution for
the name server support side of the equation, but my point is that most
of what you claim to be trying to achieve is already easily accomplished.

Doug (emacs!?! vi or die, baby)

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 Mar 2012 10:34:02 -0800

On Mar 2, 2012, at 10:09 AM, Doug Barton wrote:

> formatted text strings that they don't understand?

Yes, that's exactly the point. If they can copy-and-paste from a tool that created the text string, this will be of huge benefit.

> And/or that the

No, that's not what is proposed. What is proposed is that if the operator has added the stanza, the user can add the RRtypes.

> user demand for these changes, they get made.

The purpose of the proposal is to allow protocols with less press oomph than "new TLDs, IPv6 and DNSSEC" to be deployed. Maybe you don't want that, but many of us do.

> of what you claim to be trying to achieve is already easily accomplished.

Here, I agree with you more than I agree with John, but history has shown that HTML forms are not sufficient. I'm not sure why.

--Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Fri, 02 Mar 2012 10:46:53 -0800

On 03/02/2012 10:34, Paul Hoffman wrote:
>>> The point of my draft is that it's an extension language that
>>> both name servers and provisioning systems can read on the fly.
>>> Add a new stanza to /etc/rrtypes and you're done, no software
>>> upgrades needed.  The risk is much lower since the worst that
>>> will happen if the new stanza is broken is that the provisioning
>>> software and name servers will ignore it, not that the whole
>>> thing will crash.
>> 
>> So it seems to me that what you're proposing would also cause the
>> need for changes to be made to the provisioning systems. Or are
>> you suggesting that the same users who cannot handle anything other
>> than point and click are suddenly going to be able to enter
>> specially formatted text strings that they don't understand?
> 
> Yes, that's exactly the point. If they can copy-and-paste from a tool
> that created the text string, this will be of huge benefit.

So new tools still have to be created for new RRtypes, right? This
sounds like an "elephants all the way down" situation to me.

>> And/or that the people who operate those provisioning systems are
>> going to allow end users to "Add a new stanza to /etc/rrtypes"?
> 
> No, that's not what is proposed. What is proposed is that if the
> operator has added the stanza, the user can add the RRtypes.

So less difficult than a full-fledged change to the provisioning system,
but still requires operator intervention, and now you have operators
*and* users with chances to make fatal errors.

>>> bottleneck, and telling people to hand-code more types into them
>>> isn't going to happen, there's no chance of getting more RRs
>>> deployed.
>> 
>> The rest of this discussion is almost certainly more suitable for
>> dnsop, but I'll say one more time that I disagree with you on this
>> point. Provisioning systems *are* a bottleneck, no one is disputing
>> that. But our experience with new TLDs, IPv6 and DNSSEC shows that
>> when there is user demand for these changes, they get made.
> 
> The purpose of the proposal is to allow protocols with less press
> oomph than "new TLDs, IPv6 and DNSSEC" to be deployed. Maybe you
> don't want that, but many of us do.

Please don't use that kind of ad-hominem-adjacent line of argument with
me. I'm already on record numerous times, including in this thread,
saying that I believe the ability to deploy new RRtypes is crucial to
the ongoing health of the Internet.

>> provisioning system UI design, most of what you are trying to
>> accomplish with your draft on the UI side can be handled with a
>> simple text field in an HTML form that allows the user to enter
>> free-form stuff that is then checked for syntax errors and loaded
>> if the name server software supports the record. I realize that we
>> disagree on right solution for the name server support side of the
>> equation, but my point is that most of what you claim to be trying
>> to achieve is already easily accomplished.
> 
> 
> Here, I agree with you more than I agree with John, but history has
> shown that HTML forms are not sufficient. I'm not sure why.

IME this has been because of the lack of a validation step in between
user entry and (attempted) deployment. My (simplified) work flow for
these kinds of systems has been:

User input
    |
Sanity checks based on internal policy
    |
named-checkzone (or equivalent)
    |
Deploy to name server
    |
Validate that the new zone loaded correctly

Skipping steps 2, 3, or 5 *will* cause tears, at some point.

Doug

---

From: "John R. Levine" <[email-masked]>
Date: 2 Mar 2012 13:48:01 -0500

Skipping over all the parts I agree with, and noting that two decades of 
telling people to upgrade their DNS servers frequently hasn't worked, we 
get to ...

>> then checked for syntax errors

Checked for syntax errors?  By what?

The whole point of the extension language is to describe the syntax of new 
RRs as data that provisioning software and nams servers can read at 
runtime, so you don't have to patch your software for every new RR.

It also can be translated into an HTML form for the RR that the user can 
fill in, the provisioning software can syntax check by field, so you don't 
have to build an entire BIND master file parser into your PHP web scripts.

And, of course, your DNS server uses the same data to parse new RRs 
without being patched.

Regards,

---

From: [email-masked]
Date: Fri, 02 Mar 2012 10:48:13 -0800 (PST)

I've rarely read a message on this list that I agreed with more.

+1000 to everything said below.

				Ned

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Doug Barton <[email-masked]>
Date: Fri, 02 Mar 2012 11:09:07 -0800

> Checked for syntax errors?  By what?

Didn't you answer your own question further down in your own post? :)

But seriously folks, I really do understand what you're saying, but my
experience as both a DNS protocol weenie and as a designer/builder of
provisioning systems designed for non-DNS-protocol-weenie end users
tells me that your proposed solution is not likely to work in the (IMO
overly optimistic) manner in which you describe, and even if it did it's
the wrong solution to the problem.

If you want to discuss it further, dnsop is probably where that
discussion should take place, I've already repeated myself enough times
here.

Doug

---

From: Mark Andrews <[email-masked]>
Date: Sat, 03 Mar 2012 09:48:16 +1100

In message <[email-masked]>, "John R. Levine" wr
> records and it's too late.

Well for BIND it's add a new file that defines the type's methods
and recompile.  That isn't a whole new version.

> provisioning system lets you create SPF records.

Which is why there is a format for unknown types.  You can cut and
paste them as easily as known types.  Unfortunately the provision
systems often do a subset of RFC 1035 types let alone anything
newer.  Basically they are often just plain garbage.

> going to happen, there's no chance of getting more RRs deployed.

Until provisoning systems accept UNKNOWN record types they will
always be a bottle neck.  Without that you will have to wait for
the change request to be processed.  Given the history just getting
AAAA records added to most of these system it will be forever.

All the tools we ship support UNKNOWN record types and classes.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R. Levine" <[email-masked]>
Date: 2 Mar 2012 18:13:23 -0500

> and recompile.  That isn't a whole new version.

Recompile -> new version.  These days, most server systems are built from 
precompiled packages.  Check your local Linux box for an example.

> newer.  Basically they are often just plain garbage.

Well, yes.  Wouldn't it be nice to have provisioning systems that could be 
configured to support the RR types you want to use?  If so, you might want 
to look at my draft.

> AAAA records added to most of these system it will be forever.

AAAA was unusually painful, since it requires adding a parser for IPv6 
addresses.  (Having hacked it into my provisioning system, I speak from 
experience.)  Most new RR types are just strings, numbers, names, and the 
occasional bit field.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 03 Mar 2012 12:19:31 +0100

On 03/Mar/12 00:13, John R. Levine wrote:
> addresses.  (Having hacked it into my provisioning system, I speak
> from experience.)  Most new RR types are just strings, numbers, names,
> and the occasional bit field.

Yeah, and if ISPs already had troubles with ho-de-ho-de-ho-de-ho, how
will they join in on skee-bop-de-google-eet-skee-bop-de-goat?

Given that, designers of new RR types will want to stick to string
formats just to spare ISPs some parsing, at the cost of losing a half
of the advantages that RFC 5507 talks about, along with syntactic
validations aimed at preventing some permerror/permfail cases.

---

From: [email-masked]
Date: Sat, 03 Mar 2012 07:56:45 -0800 (PST)

> validations aimed at preventing some permerror/permfail cases.

Doubtful. If a record needs to have, say, a priority field, or a port number,
given the existence of MX, SRV, and various other RRs it's going to be very
difficult for the designers of said field to argue that that should be done as
ASCII text that has to be parsed out to use.

More generally, this is trying to have things both ways. We can't
simultaneously assert that deploying simple new RRs is a breeze, making this
unnnecessary, and that it's so difficult that everything should be crammed into
TXT Format no matter the actual structure is.

				NNed

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 3 Mar 2012 17:05:08 +0100

> ASCII text that has to be parsed out to use.

Agree with you but too many people today "just" program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself.

   Patrik

---

From: Hector <[email-masked]>
Date: Sat, 03 Mar 2012 11:23:30 -0500

> TXT Format no matter the actual structure is.

Whats missing from all this is whether a TXT based protocol 
application can successfully pass all IETF/IESG and DNS community 
reveals, full endorsement and move to Internet Status.  Sounds like 
isn't an issue any more with the aggressive push with protocols like 
DKIM and other TXT only proposed standard protocols.

That was what I was trying to get out of all this.  What is the new 
developer going to think when he invents the next DNS application? 
Which approach does he use for greater endorsement?

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 03 Mar 2012 11:29:10 -0500

On Saturday, March 03, 2012 05:05:08 PM Patrik Fältström wrote:
> > Doubtful. If a record needs to have, say, a priority field, or a port
> > number, given the existence of MX, SRV, and various other RRs it's
> > going to be very difficult for the designers of said field to argue
> > that that should be done as ASCII text that has to be parsed out to
> > use.
> 
> Agree with you but too many people today "just" program in perl och python
> where the parsing is just a cast or similar, and they do not understand
> this argument of yours -- which I once again completely stand behind
> myself.

There's a design trade off here that one should not over generalize about.  
Sometimes an ASCII text record will be fine, in other cases, it probably won't.  
Making the 'easy' case really easy so that new RRTypes get traction is a 
worthwhile goal.  It certainly won't apply to all new RRTypes and so claims 
that it's not a universal solution don't mean it's not useful.

Scott K

---

From: Hector <[email-masked]>
Date: Sat, 03 Mar 2012 11:39:41 -0500

� wrote:
> this argument of yours -- which I once again completely stand behind myself.

The original version of Sender-ID (Caller ID Policy) was an XML 
version of SPF. In fact, the experimental record still exist:

    nslookup -query=txt _ep.hotmail.com

    "<ep xmlns='http://ms.net/1' testing='true'>
     <out><m><indirect>list1._ep.hotmail.com</indirect>
     <indirect>list2._ep.hotmail.com</indirect>
     <indirect>list3._ep.hotmail.com</indirect></m></out></ep>"

It was introductions like this that raised eyebrows and the need to 
include a new RR type with the simpler language SPF TXT fallback for 
SPF and SENDER-ID.

If TXT becomes the acceptable norm, than perhaps the XML format cane 
easily be reconsidered for a DNS TXT storage with a common XML I/O 
construct. :(

--
HLS

---

From: [email-masked]
Date: Sat, 03 Mar 2012 08:38:16 -0800 (PST)

> Agree with you but too many people today "just" program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again compl…

Regardless of the language you program in, you still have to get your proposal
approved. For that to happen the folks who review these things would in effect
be conceding that there is in fact a major deployment problem out there.

That's the point I was trying to make, not that people wouldn't argue for this
approach.

I am unaware of any counterexamples that have actually made it through the
process, but if they exist feel free to point them out.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 3 Mar 2012 17:43:26 -0000

>Agree with you but too many people today "just" program in perl och python where the parsing is just a cast or similar, and they do not
>understand this argument of yours -- which I once again completely stand behind myself.

Honestly, if new RR types were all text to be parsed by clients, a la
SPF and DKIM, that wouldn't be the worst thing in the world.  The main
advantage of a new RR type is that clients can ask for it specifically
and know that any they answer they get is that kind of data, as opposed
to overloaded TXT where you get what you get.

If the DNS records have binary fields, the parsing happens in the DNS
server.  If they're text, the parsing happens in the client.  Back
when the DNS was young, the suggestion that clients would have to
parse the records would have seemed nuts.  Now mail clients parse
multiple SPF and DKIM records on every mail transaction and nobody
cares.  An advantage of parsing in the server is that you catch syntax
records earlier, but that's still no guarantee that the data are
valid.  (For example, see the MX data for international.com, which
caused a mail loop I fixed yesterday.)  An advantage of parsing in the
client is that the parser is in code managed by people who care about
it, rather than managed by some distant DNS operator.

I suppose that unparsed records mean that the server can't add
additional section records, but based on yesterday's discussion, it
sounds like nobody's using them any more, so who cares?

---

From: Hector <[email-masked]>
Date: Sat, 03 Mar 2012 13:21:38 -0500

John Levine wrote:

> Now mail clients parse
> cares.  

Well....., its not like anyone really had a choice.

SPF is still maturing with its RR type, DKIM didn't bother, and now 
also have VBR, ADSP and now ATPS and then DMARC (all by the same group 
of people), where for the total coverage aware integrator is a major 
overhead, 4-5 calls with a very low yield.  I care about it. Its ugly. 
But no choice.

> sounds like nobody's using them any more, so who cares?

Do you think a TXT only based DNS application can today pass the 
IETF/IESG DNS community endorsement to IS?

I think another part of the problem is that many of these TXT bases 
protocols currently on the radar are all related in some form or 
fashion.  A solution to merge all or just some where applicable, to 
reduce multiple calls and redundancy, can help alleviate some of the 
concerns.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 04 Mar 2012 13:46:59 +0100

On 03/Mar/12 18:43, John Levine wrote:
> SPF and DKIM, that wouldn't be the worst thing in the world.

Well, since that's what is currently being done, it must obviously be
feasible.  However, there is no reason to stick to it if a better
choice is available.

> The main advantage of a new RR type is that clients can ask for it
> specifically and know that any they answer they get is that kind of
> data, as opposed to overloaded TXT where you get what you get.

Yes, possibly better than using _prefixes.

> An advantage of parsing in the server is that you catch syntax 
> valid.

Allowing a binary form is also an advantage, although I agree that the
hype on performance is a relic.

> An advantage of parsing in the client is that the parser is in code
> managed by people who care about it, rather than managed by some
> distant DNS operator.

I see a tendency to stick to good parsing models, both by referencing
their specs in newer specs and by reusing library function.  Except
for possible bugs, whose patches could be promptly broadcasted as
security fixes, we gathered enough experience with those formats that
I think we're likely to get a generic spec right on the first attempt.

Public keys, IP addresses, flags, are all candidates for binary field
formats.  The binary version of "tag=value" could look much like DER,
except that tag enumerations could be drawn from the relevant protocol
registry.  I guess there's plenty of possibilities better than XML.

> sounds like nobody's using them any more, so who cares?

You mean that a response to a query for, say, DKIM could come with a
few byte worth of ADSP added as a bonus, if it fits within the
response size?  This feature is also missing from
draft-levine-dnsextlang-02.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 4 Mar 2012 23:33:18 -0500

Hey, if people don't like the restrictions of the TXT RR, have I got
an answer for you!
See http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02
A little out of data but gives you a wide variety of formats :-)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Sat, Mar 3, 2012 at 11:39 AM, Hector <[email-masked]> wrote:
>>> number,
>> where the parsing is just a cast or similar, and they do not understand this
>> argument of yours -- which I once again completely stand behind myself.
>
>
> The original version of Sender-ID (Caller ID Policy) was an XML version of
> SPF. In fact, the experimental record still exist:
>
> It was introductions like this that raised eyebrows and the need to include
> a new RR type with the simpler language SPF TXT fallback for SPF and
> SENDER-ID.
>
> If TXT becomes the acceptable norm, than perhaps the XML format cane easily
> be reconsidered for a DNS TXT storage with a common XML I/O construct. :(
>
> --
> HLS
>

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 4 Mar 2012 00:22:05 +0100

> Sometimes an ASCII text record will be fine, in other cases, it probably won't.

My point is as we move again towards multiple text representations of "the digit five" for example, both encoding and parsing is easier and more secure if that digit is really for example eight bits and not "text" that someone has to parse.

   Patrik

---

From: "John Levine" <[email-masked]>
Date: 5 Mar 2012 17:09:38 -0000

>My point is as we move again towards multiple text representations of "the digit five" for example,
>both encoding and parsing is easier and more secure if that digit is really for example eight bits
>and not "text" that someone has to parse.

Unless you provision your DNS zones with a hex debugger, the digit
will always start out as text that someone has to parse.  The question
is who does the parsing, the DNS server or the application.  As I said
in a previous message, I can see plausible reasons to put the parser into
the application.

Would you really want to build an SPF or DKIM parser into every DNS
server?  That's a lot of code that the DNS manager doesn't care about,
but the mail manager does.

R's,
John

PS: For anyone who didn't read my previous message, I am NOT saying
that it's fine to overload everything into TXT.  I am saying that new
RRTYPEs that are text blobs interpreted by client software wouldn't
necessarily be bad.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 05 Mar 2012 20:01:53 +0100

> but the mail manager does.

But it would be the same code, most likely by the same author(s).  It
may be generic for a kind of syntax or specific for a RR type,
according to its author's convenience.  On a system that allows new RR
types without recompiling, the code would come as some sort of plugin
in both cases.

Why is it important what the DNS manager cares about?  Parsers,
including null parsers, would come with the same sub-package that
enables the new RR type definition.  Their complexity would only
matter to the people who read/maintain their sources.

> RRTYPEs that are text blobs interpreted by client software wouldn't

Agreed.  That doesn't preclude syntax checking on loading the zone,
though.

---

From: Hector Santos <[email-masked]>
Date: Mon, 05 Mar 2012 14:19:24 -0500

> matter to the people who read/maintain their sources.

+1

> Agreed.  That doesn't preclude syntax checking on loading the zone,

As a Windows shop, there is no hiding of the long product development 
battles between the *nix weenies world and the WinDoze world.  At a 
general level, the WinDoze world is not one that is use to and relies 
on text based "editors" configuration, they need the GUI.  I even 
recourse getting a private message suggesting my customers must be 
"stupid."

Nonetheless, to reach critical mass, it is important the GUI is 
developed for this stuff. I can't rely on customers becoming text 
editor people if that is the only way to make this work.  They only 
way I could even begin to offer DKIM, ADSP and even now ATPS is to 
provide a GUI, like this public version we have here for ADSP and ATPS

        http://www.winserver.com/public/wcadsp

Just consider that ATPS has SHA1, BASE32 functions to produce the 
records.  That adds complexity for any DNS server manager (Windows or 
Bind) to consider. Its just not a plug and play consideration.  Its 
probably easier for the ISP Web-based managers since its more of an 
add-on to there current DNS software, using command line tools to act 
on GUI posted information.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: [email-masked]
Date: Mon, 05 Mar 2012 19:56:15 -0800 (PST)

> types without recompiling, the code would come as some sort of plugin

There are some false equivalences floating around here. I don't think anyone is
suggesting that having provisioning systems or even DNS servers themselves
check for syntax errors in the contents of complex records like DKIM, SPF,
DMARC, or whatever is necessarily a bad idea. (Whether or not it will actually
happen is another matter; I'm dubious.)

Rather, the issue is with requiring it to happen in order to deploy a new
RRTYPE of this sort, which is the result you get if the DNS server returns some
series of tokens instead of the original text string. That's the sort of thing
that forces people to upgrade, or search around for a script to do the
conversion (which won't even occur to some), and that's an extra burden we
don't need to impose.

> Why is it important what the DNS manager cares about?

Speaking as a DNS manager myself, I care a lot about being forced to upgrade.
Upgrades bring unwanted bugs in other areas.

In fact I'm not entirely thrilled with the idea of plugins to do some extra
syntax. More code means more possibilities of bugs. I'd actually prefer to see
more cross-checking of existing stuff - less code and greater benefit.

> Parsers,

I'm sorry, but you're being naive about this. Complexity does matter to the
people who just use software because added complexity translates to more bugs.

> Agreed.  That doesn't preclude syntax checking on loading the zone,

As long as we stick with syntax checking I'm (mostly) OK with it.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 6 Mar 2012 04:46:28 -0000

>> server?

Here's another thought experiment.  DKIM records are a sequence of
tag=value fields.  Let's imagine a binary version of DKIM records
where each field is a length byte, a tag byte, and a suitably coded
value.  For the values that are currently strings, it's the string,
for the values that are currently base64, it's the binary value.

Since DNS TXT records are a sequence of binary strings each preceded
by a length byte, we could just stuff this version of DKIM directly
into a TXT record, with the first binary string being "v=DKIM2".
Would that be a good idea?  DNS servers can serve the records without
adding any new features, the records will be marginally faster to
parse.

Would that be a good idea?  Why or why not?  Assume we wave our hands
and we have some way to create the records, hacks in provisioning
systems, or a wizard web site into which you type your parameters and
it gives you a TXT master file record full of hex escapes.  

Or wave them even more vigorously and assume the parser is built into
some future version of BIND.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 6 Mar 2012 05:59:32 +0100

I think we should look a bit on the flow of data. If I simplify we have a flow like this:

Input -P-> DNS server -D-> DNS stub -Q-> Output

P is the provisioning
D is the DNS protocol
Q is the query/parsing in the consumer of the data

What we want is (as described in the IAB RFC on extensions of DNS) the ability to query (in D) for as precise data as possible in the triple {owner, type, class}. Some RR types like NAPTR and TXT have flaws where the selection between records in an RRSet is not in this triple. In some applications that is resolved by having a prefix to the owner. In some other applications that is resolved by parsing the RRSet.

We all do believe that IF it was easier to add a new RRType for each application that would be an architecturally better solution (as adding prefix to the owner have its drawbacks). Now, the question is what blocks the ability to add new RRTypes.

We seem to believe that the "D" part is deployed so that adding new "unknown" RRTypes is not an issue.

Problem is then in "P" and "Q".

And when we talk about parsing, we talk about what the mapping between provisioning and DNS packet format is.

Are we aligned so far?

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Mar 2012 16:42:12 +1100

In message <[email-masked]>, =?iso-8859-1?Q?Pa
trik_F=E4ltstr=F6m?= writes:
> What we want is (as described in the IAB RFC on extensions of DNS) the abilit
> y to query (in D) for as precise data as possible in the triple {owner, type,
>  class}. Some RR types like NAPTR and TXT have flaws where the selection betw
> een records in an RRSet is not in this triple. In some applications that is r
> esolved by having a prefix to the owner. In some other applications that is r
> esolved by parsing the RRSet.
> 
> We all do believe that IF it was easier to add a new RRType for each applicat
> ion that would be an architecturally better solution (as adding prefix to the
>  owner have its drawbacks). Now, the question is what blocks the ability to a
> dd new RRTypes.
> 

I would say DNS master file representation -> DNS wire representation
is one of the main issues on the provisioning side.  This conversion
needs to be done at some point.  The other this is verification of
the input.

DNS wire representation -> text or structured object on the application
side.  Part of the issue here is that some libraries don't provide
hooks to return unknown types as a raw data blob so even if you can
enter the data there isn't a exit path.  I don't know what such
library developers were thinking.  There has been a long but slow
history of new types being added to the DNS and the original set
of types was never expected to be sufficient for all uses.

---

From: [email-masked]
Date: Mon, 05 Mar 2012 22:08:54 -0800 (PST)

> I think we should look a bit on the flow of data. If I simplify we have a

Looking at data flows is usually a good idea.

> P is the provisioning

I think you want to break that into the provisioning interface and the data
format it produces that the DNS server consumes. (My reason for that is we have
a specification for at least such format, with all that implies.)

> What we want is (as described in the IAB RFC on extensions of DNS) the
> ability to query (in D) for as precise data as possible in the triple {owner,
> type, class}. Some RR types like NAPTR and TXT have flaws where the selection
> between records in an RRSet is not in this triple. In some applications that
> is resolved by having a prefix to the owner. In some other applications that
> is resolved by parsing the RRSet.

> We all do believe that IF it was easier to add a new RRType for each
> application that would be an architecturally better solution (as adding prefix
> to the owner have its drawbacks). Now, the question is what blocks the ability
> to add new RRTypes.

Yes, I think we have agreement on all of that.

> We seem to believe that the "D" part is deployed so that adding new "unknown"

I think this is correct, but OTOH someone recently asked about possible issues
in this area, and if I remember correctly, received no response.

> Problem is then in "P" and "Q".

I personally don't see a big problem with "Q", but others clearly do so
we need to leave it in.

> provisioning and DNS packet format is.

I think we need to be a little finer grained than that, per the above.

> Are we aligned so far?

Yes, pretty much.

				Ned

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Mar 2012 13:15:17 +0000

Mark Andrews <[email-masked]> wrote:
> needs to be done at some point.

John's draft addresses that.

> The other this is verification of the input.

What kind of verification?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth, Biscay: Variable 4, becoming west 5 to 7. Moderate or rough. Rain or
showers. Good, occasionally poor.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 01:34:21 +1100

In message <[email-masked]>, Tony F
> What kind of verification?

Most front ends want to make sure what they are feeding to the back
ends wont make it choke.  It also make for a better user experience.

---

From: "John R. Levine" <[email-masked]>
Date: 6 Mar 2012 10:00:17 -0500

> a specification for at least such format, with all that implies.)

I was also going to mention that.  There's a lot of different formats for 
zone file data, with BIND-ish master files being only one of them.

> in this area, and if I remember correctly, received no response.

Last month I ran into a guy on the dmarc list who complained that 
his server returns NOTIMP in response to queries for SPF records ("because 
it doesn't implement them") and clients were doing odd things.  But it's 
been a long time since I've run into anyone else like that, so I agree, 
it's not an issue.

> I personally don't see a big problem with "Q", but others clearly do so

I'm not aware of problems, but I don't use Windows which is where the 
problems are supposed to be.

Regards,

---

From: [email-masked]
Date: Tue, 06 Mar 2012 07:30:18 -0800 (PST)

> problems are supposed to be.

Exactly - neither do I. (Well, OK, I have a Windows laptop at work to handle
the company HR stuff that won't work in anything other than IE, but I try
really, really hard never to use it.)

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 06 Mar 2012 17:01:57 +0100

On 06/Mar/12 04:56, [email-masked] wrote:
>>> Would you really want to build an SPF or DKIM parser into every
>>> DNS server?  That's a lot of code that the DNS manager doesn't
>>> care about, but the mail manager does.
>> 
>> But it would be the same code, most likely by the same author(s).
> 
> There are some false equivalences floating around here. I don't
> think anyone is suggesting that having provisioning systems or even
> DNS servers themselves check for syntax errors in the contents of
> complex records like DKIM, SPF, DMARC, or whatever is necessarily a
> bad idea. (Whether or not it will actually happen is another
> matter; I'm dubious.)
> 
> Rather, the issue is with requiring it to happen in order to deploy
> a new RRTYPE of this sort, which is the result you get if the DNS
> server returns some series of tokens instead of the original text
> string. That's the sort of thing that forces people to upgrade, or
> search around for a script to do the conversion (which won't even
> occur to some), and that's an extra burden we don't need to
> impose.

It would still be possible to work around the need for a plugin, e.g.
by depending on some wizard web site, as in John's thought experiment.

For the rest of us, the possibility to install a plugin that takes
care of all the nitty-gritty details, instead of having to wait for
the release and distribution of the next version of BIND, can make the
difference between deploying a new RR type right away and
procrastinating endlessly.

> Speaking as a DNS manager myself, I care a lot about being forced
> to upgrade. Upgrades bring unwanted bugs in other areas.

(I'd be surprised if bugs in any area were wanted ;-)

The issue is to upgrade once rather than on each new RR type.

> In fact I'm not entirely thrilled with the idea of plugins to do
> some extra syntax. More code means more possibilities of bugs. I'd
> actually prefer to see more cross-checking of existing stuff - less
> code and greater benefit.

Depending on how the plugin mechanism is engineered, code insulation,
data encapsulation, and component tests against large samples of data
may help reduce bugs.

To me, an important point is that zone files keep containing data
"source", rather than the output of possibly unreproducible commands.
 Diagnostic-mode execution of the plugin together with a text-based
/etc/rrtypes may even allow to mechanically build GUI dialogs for each
type, whether for the web or for the desktop.

>> Parsers, including null parsers, would come with the same
>> sub-package that enables the new RR type definition.  Their
>> complexity would only matter to the people who read/maintain
>> their sources.
> 
> I'm sorry, but you're being naive about this. Complexity does
> matter to the people who just use software because added complexity
> translates to more bugs.

Correct, but when you publish a complex record you are calling forth
that complexity.  I don't see much difference if the bug is at mines
or at the remote site, since their effects are comparable.

Generating zone files full of hex escapes, so as to do without any
plugin, can --perhaps should-- stay possible.  However, I doubt that
such usage would result in less bugs, on average.

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Mar 2012 17:00:07 +0000

John R. Levine <[email-masked]> wrote:
>
> I was also going to mention that.  There's a lot of different formats for zone
> file data, with BIND-ish master files being only one of them.

DNS master files are specified in RFC 1035 so it's wrong to imply they are
implementation-specific.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames: Variable, becoming southwest, 4, increasing 6 to gale 8.
Slight or moderate, occasionally rough later. Showers, rain later. Good,
occasionally poor later.

---

From: "John R. Levine" <[email-masked]>
Date: 6 Mar 2012 12:04:05 -0500

> DNS master files are specified in RFC 1035 so it's wrong to imply they are

They're not implementation specific, but they're also not required to 
interoperate, as the wire format queries and responses are.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 06 Mar 2012 18:34:58 +0100

On 06/Mar/12 16:00, John R. Levine wrote:
>> I think this is correct, but OTOH someone recently asked about 
>> possible issues in this area, and if I remember correctly,
>> received no response.
> 
> Last month I ran into a guy on the dmarc list who complained that his
> server returns NOTIMP in response to queries for SPF records ("because
> it doesn't implement them") and clients were doing odd things.  But
> it's been a long time since I've run into anyone else like that, so I
> agree, it's not an issue.

Hm... I have no idea how such response gets cached.  RFC 2136 says
that "an appropriate error will be returned to the requestor's caller"
when RCODE is SERVFAIL or NOTIMP.

Is that the same case that Scott noticed when he wrote:

   Particularly when querying for SPF records of type SPF, persistent
   2 ServFail results are /not rare/.

   http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html
   (emphasis added)
?

IIRC there was also a mirroring issue...

At least, I think these issues will gradually vanish as the software
at the relevant servers gets upgraded.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 12:40:37 -0500

> at the relevant servers gets upgraded.

I don't think it's the same.  It's been awhile since I had data because I 
simply stopped doing any type SPF queries in software I use or support due to 
issues with it (and there's no upside to go expend effort on revisiting the 
issue), but these were definitely SERVFAIL and not NOTIMP, but either would 
have had the same effect of a permanent "temporary error".

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 09:09:11 +1100

In message <[email-masked]>, "John R. Levine" wr
ites:
> zone

They are a interchange standard as per RFC 1034.

The standard format of master files allows them to be exchanged between
hosts (via FTP, mail, or some other mechanism); this facility is useful
when an organization wants a domain, but doesn't want to support a name
server.  The organization can maintain the master files locally using a
text editor, transfer them to a foreign host which runs a name server,
and then arrange with the system administrator of the name server to get
the files loaded.

---

From: "John R. Levine" <[email-masked]>
Date: 6 Mar 2012 17:15:46 -0500

> They are a interchange standard as per RFC 1034.

Yes, we all know that.  But as I presume you also know, there are plenty 
of DNS servers that store the zone info in other ways, ranging from djbdns 
mutant syntax text files to various databases.

Whatever the server uses, the provisioning system better match.

> and then arrange with the system administrator of the name server to get

That is one implementation.  But it's far from the only one.

My system has a web front end that lets my users edit groups of their 
djbdns RRs, which it stores in a database.  Once an hour, a perl script 
goes through the database, regenerates the mutant text files, and stuffs 
them into the name servers.  It's not fabulous, but it gets the job done.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 09:19:31 +1100

> at the relevant servers gets upgraded.

A RFC 1035 recursive server should be able to handle SPF.  It's
just a opaque data blob to it with a name, type, class and ttl
attributes.  To serve SPF a RFC 1035 needed to be upgraded as it had
no way to store / load the record.

DNS software developers should read Section 3.6. "Defining new types,
classes, and special namespaces", especially the sentence:

		New definitions should be expected.

Mark

---

From: "John Levine" <[email-masked]>
Date: 7 Mar 2012 00:08:14 -0000

>> > agree, it's not an issue.

In case it wasn't clear, this is an authoritative server.

>attributes.

Agreed.  Other than a few dusty Suns still running obsolete BIND 4.x,
I don't know of any DNS caches that have problems with arbitrary RRs.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 13:42:47 +1100

In message <[email-masked]>, "John R. Levine" wr
> Whatever the server uses, the provisioning system better match.

BIND stores zones in other ways as well.  You just have to be able
accept them and produce them or else you don't have a comforming
implementation.

> them into the name servers.  It's not fabulous, but it gets the job done.

Nobody says you can't have propriatry methods of data entry.

However we do have standard presentation/entry formats defined and a good
front end will accept those as well.

Mark

---

From: "John R. Levine" <[email-masked]>
Date: 6 Mar 2012 21:49:56 -0500

> front end will accept those as well.

Sigh.  Now we're back to "people who don't do it my way are wrong", so I 
guess we're done.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 13:58:39 +1100

> In case it wasn't clear, this is an authoritative server.

A authoritative server should be returning NOERROR / NXDOMAIN not
NOTIMP provided the zone loads otherwise SERVFAIL if the load fails
for any type other than those in the reserved meta type range.  If
the data isn't in the zone and the name is in use NOERROR is the
response you send.  If the name isn't in use NXDOMAIN is the response
you send.  Failure to load all of the zone is supposed to stop any
of it being served according to RFC 1035.

If you want to be a nameserver developer you don't stop counting
at 1035.  The meta type range was initially reserved in RFC 2929
(Sep 2000).

---

From: "John R. Levine" <[email-masked]>
Date: 6 Mar 2012 22:46:45 -0500

> NOTIMP

Yes, we all know that.  My point, which I would have thought was obvious, 
was that it's been a long time since I've run into anyone whose server was 
broken like that.  As I said, it's not an issue.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 15:12:13 +1100

In message <[email-masked]>, "John R. Levine" wr
> Sigh.  Now we're back to "people who don't do it my way are wrong", so I 

One of point of having standard presentation formats is that they
facilitate data interchange.  I can use my tools to generate the
records and your system can just accept it.  Having to re-format
data is a pain.  If you want to do something else as well there is
no problem with that.

It's a little like credit card numbers.  Breaking them up into 4
boxes of 4 digits and having to move the focus between boxes is a
absolute pain.  These should be cut and pastable, with or without
spaces in the middle.

There are international standards for telephone numbers but every
web developer seems to think they know best.

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Mar 2012 13:22:08 +0900

> facilitate data interchange.

bind's zone format is not a standard, and many implementations are not
compatible with it.  get over it.

randy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 16:03:40 +1100

> compatible with it.  get over it.

Actually it is STD 13.  Get over it.

---

From: Martin Rex <[email-masked]>
Date: Wed, 7 Mar 2012 06:39:48 +0100 (MET)

Mark Andrews wrote:
> "John Levine" writes:

If this is about permitted RCODEs here

  http://tools.ietf.org/html/rfc1035#section-4.1.1

then an RCODE of 4 in the response looks like a perfectly valid response
for a DNS Server to a query, authoritative or not is irrelevant, and
if any client chokes on such an answer, it is likely the client that
is broken.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 17:04:30 +1100

In message <[email-masked]>, Martin Rex writes
> if any client chokes on such an answer, it is likely the client that

No, its about what should be generated.  NOTIMP != NOERROR no data.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 7 Mar 2012 08:13:06 +0100

On 7 mar 2012, at 03:49, John R. Levine wrote:

> Sigh.  Now we're back to "people who don't do it my way are wrong", so I guess we're done.

I disagree.

"People who don't accept the standardized zone format are wrong" is Mark's statement.

What you say is "as people do not support the standardized zone format as input, what do we do".

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 18:54:14 +1100

In message <[email-masked]>, =?iso-8859-1?Q?Pa
> What you say is "as people do not support the standardized zone format as inp

The point of RFC 3597 was to provide a STANDARD text representation
that could handle any DNS record format.  It isn't pretty but as
long as you accept it and emit it you are future proof.  Its a
lowest common format.

	    A 1.2.3.4 == TYPE1 \# 4 01020304

Most provisioning systems really don't care about most of the data
they are throwing about.  It may as well be a opaque blob.

Pretty is for the next revision of the provisioning software.  Look
at what data you have in raw format and use that to decide what you
need to handle in a prettier manner in the next revision.  You don't
even need to to change the database tables.  It's just front end
presentation that needs to be changed.

Mark

---

From: [email-masked]
Date: Wed, 07 Mar 2012 00:42:47 -0800 (PST)

> procrastinating endlessly.

You're still not separating the two cases. Again, an *optional* plugin to check
syntax of a record but not produce any sort of tokenized result is fine, a
plugin that's *mandatory* to deploy is going to be almost as much of an
impediment to deployment as requiring an upgrade. Code is code, and people
don't install new code willy-nilly.

> The issue is to upgrade once rather than on each new RR type.

Exactly. That's why mandatory plugins are a bad idea.

> or at the remote site, since their effects are comparable.

They most certainly are not. A bug in my client only affects me, a bug
in the server can easily kill the entire zone. And even if separation
techniques are employed, if the plugin fails the best you're going to be
able to do is server out a domain with missing entries.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 Mar 2012 13:56:55 +0100

On 07/Mar/12 09:42, [email-masked] wrote:
> You're still not separating the two cases.

I think I did, however badly.  Let me try by example, assuming my
server doesn't recognize SPF.  As it's unrecognized, I have to write
it as such, e.g.

  TYPE99 \# 12 0B 763D73706631 20 2D613131

> Again, an *optional* plugin to check syntax of a record but not
> produce any sort of tokenized result is fine,

Now the plugin can check the syntax and spot the error.  I may correct
it or not.  If I don't, I'll just serve bad data.  In any case, my
zone source still contains the line above.  Thus the plugin is optional.

> a plugin that's *mandatory* to deploy is going to be almost as much
> of an impediment to deployment as requiring an upgrade. Code is
> code, and people don't install new code willy-nilly.

Possibly, I can also run, say:

  echo 'SPF "v=spf1 -a11"' | plugin --dump-hex --silent

and have it dump the TYPE99 line above (without signalling the error,
since I said --silent).  Then I copy its output and paste it into the
zone source.

Finally, I can enable automatic invocation of the plugin.  That way, I
can write the SPF record directly in the zone source and have my
DNS-fictional server do the copy and paste on the fly for me.

I wouldn't call such thing "mandatory".

> in the server can easily kill the entire zone.

Ooops, yes, that's right.

---

From: "John R. Levine" <[email-masked]>
Date: 7 Mar 2012 10:14:01 -0500

Gee, by sheer random walk this has wandered back to the original topic, 
that provisioning software is the major bar to deploying new RRs.

> they are throwing about.  It may as well be a opaque blob.

I couldn't disagree more.  Other than my own homebrew system, all the 
provisioning systems I know support a handful of specific RR types and 
make it somewhere between painful and impossible to install anything else.

Godaddy's is a good and very large example of this.  They have a "wizard" 
to create an SPF record, but it turns out to be a TXT record.  If you want 
a real type 99 SPF record, you're out of luck.

Assuming you're not talking about editing zone files with vi, can you give 
some specific examples of what you're talking about?

Regards,

---

From: [email-masked]
Date: Wed, 07 Mar 2012 11:46:39 -0800 (PST)

>   TYPE99 \# 12 0B 763D73706631 20 2D613131

OK, now I'm completely confused. What does lack of SPF record support in your
server input format have to to with syntax checking of the *content* of the SPF
record? I can write the record as text or in hex or base64 or whatever format I
want; the issue is looking *inside* the data and either (a) just checking it's
syntax versus (b) checking it and turning it into some kind of tokenized stuff
the DNS server actually serves out.

> > code, and people don't install new code willy-nilly.

Any plugin that's necessary to transform a nontrivial input format into a
tokenized result is effectively mandatory. Sure, you can substitute a
preprocessing script that does the transform and spits out hex or whatever, but
no matter how you do it there's an essential translation component involved in
provisioning those records. You may be able to avoid having that component 
cause the entire server fail, but it's still in the critical path for
setting up those records.

> since I said --silent).  Then I copy its output and paste it into the

Let's please stop talking about what you can do manually. This isn't about
people whose main provisioning tool is emacs or bind, and who operate their own
servers with full autonomy and report to nobody. This audience doesn't have
issues with any of this stuff.

> I wouldn't call such thing "mandatory".

Again, it depends on whether or not it's in the critical provisioning
path. A syntax checker isn't, a parser and tokenizer is.

				Ned

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Mar 2012 08:49:22 +1100

In message <[email-masked]>, "John R. Levine" wr
> some specific examples of what you're talking about?

Most provisioning systems dump the records into a database and have
some other process extract them from the database and build the
input to the nameserver.  Those database records are also what the
customer updates when they next come back.

One of the problems with provisioning systems is they are mostly
based on a pre RFC 3597 view of the world where you *needed* to
know the type specific presentation format to enter the data.  In
a post RFC 3597 world it is possible to enter any record you want
with a common format.  You can dump that record straight into the
nameserver, nsupdate or any other RFC 3597 aware tool and it will
handle it.

GoDaddy, for example, could handle HIP, SSHFP and IPSECKEY with the
same input dialog if they wanted to by accepting the UNKNOWN record
format.  They could also handle the next type that is invented with
that same dialog box.

Stop asking for type XXXX support and ask for UNKNOWN record support
from your provider.  UNKNOWN record support will handle type XXXX
and anything new that will come along.

By supporting UNKNOWN record format, providers get to know which
types are actually being used by their customers and can then hire
developers to add support for the types that are actually being
used.

Tools to convert between UNKNOWN and type specific representations
will appear.  They are trivial to write.  This is the sort of thing
a 1st year CS student should be able to write as a learning exercise.
I would give the one type to convert for the exercise but that the
level of skill needed.

Take SPF as a example.  If providers had supported UNKNOWN format
then the SPF generation tools would have done UNKNOWN + SPF type
specific rather than TXT + SPF.

Mark

---

From: "John R. Levine" <[email-masked]>
Date: 7 Mar 2012 17:21:40 -0500

>>> they are throwing about.  It may as well be a opaque blob.  ...

> Most provisioning systems ...

Hi.  Could you give some concrete examples of DNS provisioning systems 
that let you enter arbitrary RRs?  I've never seen one in the wild, other 
than the one I wrote for myself.

Yes, I know that hypothetically they could do all sorts of stuff.  But 
they don't.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Mar 2012 17:39:05 -0500

> specific rather than TXT + SPF.

My father used to have a saying: "If Johnny hadn't died, they wouldn't
have buried him."  Counterfactuals in engineering are just not that
interesting.

But anyway, providers (I am employed by one, FWIW) are not going to
blindly support UNKNOWN on the input side.  That's just an invitation
to behaviour we don't understand and therefore cannot price
correctly.  More importantly, any plan that involves UNKNOWN types
also automatically comes with unknown support costs.  We will be
forced to provide customer support for types we don't even know exist,
and that will necessarily lead to unhappy customers.

A plan something like the one John Levine has proposed is the only
viable one, in my view.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Mar 2012 09:40:29 +1100

In message <[email-masked]>, "John R. Levine" wr
> Yes, I know that hypothetically they could do all sorts of stuff.  But 

I well know they don't because they are still stuck in 1980's think
mode.  It's how do we get then out of 1980's think mode and get
them to use some of the tools that were provided to them nearly a
decade ago now.

How do we apply the clue bat to the CTO and the CEO of these
provisioning providers to get them to come out of the dark ages?

ICANN might be able to do some something.  Lots of their accredited
registrar are also in the provisioning business.

Mark

---

From: "John R. Levine" <[email-masked]>
Date: 7 Mar 2012 17:48:02 -0500

> mode.  ...

Regards,

---

From: Hector <[email-masked]>
Date: Wed, 07 Mar 2012 17:55:59 -0500

+1

+1

> will appear.  They are trivial to write.  

and most likely its specifics to tied to backend I/O storage methods. 
Not everything is a droppable text file and not everyone is going to 
be using EDLIN, QEDIT, NotePad or some *nix flavor text editor.

Bind hass command line (CLI) tool to automatic the process of addng 
unnamed types, I am trying to find out if Windows DNS 5.0 DNSCMDS 
does, and so far it doesn't.  But Microsoft .NET Provisioning  API 
does support the creation of unnamed resource records.  But from what 
I am reading so far, it seems to have been abandon starting with 
VS2010.  I posted a question in the MSDN Directory Services and 
Network Infrastructure Servers support forums and so far, NADA.

Personally, I thought this was resolved with DNS 5.0 which finally did 
add direct support for the previous wish list "unknown type" SRV and 
other records required for AD (Active Directory) and DNSSEC.

But if the reality is such that the Default Window Server brand (not 
desktop brands) with its already optional installation DNS server 
option, does not come with an out of the box RFC3597 support by now, 
even if undocumented or via a registry option, well, its beating a 
dead horse now. I am all ready to support going with TXT only for SPF.

> specific rather than TXT + SPF.

+1.

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Mar 2012 00:04:16 +0100 (MET)

Mark Andrews wrote:
> Martin Rex writes:

Maybe you believe that NOTIMP should be limited to unsupported OPCODES only?
But that is definitely not what the spec says.

Generating RCODE 4 (NOTIMP) seems _perfectly_ permissible for a DNS server
when responding to a query for an QCLASS or QTYPE that the server
does not implement.

                4               Not Implemented - The name server does
                                not support the requested kind of query.

1034&1035 are both at document maturity level "Full Standard",
1034 says:

  3.7.1. Standard queries

  A standard query specifies a target domain name (QNAME), query type

  (QTYPE), and query class (QCLASS) and asks for RRs which match.  This
  type of query makes up such a vast majority of DNS queries that we use
  the term "query" to mean standard query unless otherwise specified.  The
  QTYPE and QCLASS fields are each 16 bits long, and are a superset of
  defined types and classes.

1035 says:

  RCODE         Response code - this 4 bit field is set as part of
                responses.  The values have the following
                interpretation:

                0               No error condition

                1               Format error - The name server was
                                unable to interpret the query.

                2               Server failure - The name server was
                                unable to process this query due to a
                                problem with the name server.

                3               Name Error - Meaningful only for
                                responses from an authoritative name
                                server, this code signifies that the
                                domain name referenced in the query does
                                not exist.

                4               Not Implemented - The name server does
                                not support the requested kind of query.

                5               Refused - The name server refuses to
                                perform the specified operation for
                                policy reasons.  For example, a name
                                server may not wish to provide the
                                information to the particular requester,
                                or a name server may not wish to perform
                                a particular operation (e.g., zone
                                transfer) for particular data.

                6-15            Reserved for future use.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Mar 2012 10:06:39 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> correctly.

Charge by records, bytes and queries.  Nameservers don't care beyond that.

> More importantly, any plan that involves UNKNOWN types
> also automatically comes with unknown support costs.

These are "as is" services.  You can add them and remove them.  We don't
provide additional support beyond that.

> We will be

You have unhappy customers now because they can't add record types
they would like to use. 

As for support its possible to support for unknown type what more
can be expected of you beyond "does what is served match what is in
the database" and the pre-dnssec type code roll version of dig shows
that would be possible.

If you are worried about "this type may need special processing"
then provide a simple way for the customer to ask for the type code
to be added and base level support is "unknown record format"
advanced support is "type specific record format".

Mark

bsdi:marka 09:48 {104} % dig -t 46 dv.isc.org

; <<>> DiG 8.3 <<>> -t dv.isc.org 
;; res options: init recurs defnam dnsrch no-tld-query edns0
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1819
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 6
;; QUERY SECTION:
;;	dv.isc.org, type = TYPE46, class = IN

;; ANSWER SECTION:
dv.isc.org.		1H IN TYPE46	\# 94 (	; unknown RR type
	00 06 05 03 00 00 0e 10 4f a1 d8 a5 4f 52 b0 95 ; ........O...OR..
	38 64 02 64 76 03 69 73 63 03 6f 72 67 00 62 7b ; 8d.dv.isc.org.b{
	3d c8 d0 31 85 0a 71 c3 cf 43 69 e4 9c f9 05 34 ; =..1..q..Ci....4
	31 6f d3 8f a3 c4 12 f0 0d 00 61 6f be 35 0b 9e ; 1o........ao.5..
	1c 85 5a 6a 6d e8 15 87 f6 d4 30 ee b4 57 35 e4 ; ..Zjm.....0..W5.
	7c 54 46 ac be 65 b5 48 c2 9f fe 4a 0a 26 )	; |TF..e.H...J.&
dv.isc.org.		1D IN TYPE46	\# 94 (	; unknown RR type
	00 02 05 03 00 01 51 80 4f 8b 89 c2 4f 3c 63 3e ; ......Q.O...O<c>
	38 64 02 64 76 03 69 73 63 03 6f 72 67 00 92 a7 ; 8d.dv.isc.org...
	13 64 9d 31 85 aa 31 28 99 a0 7c af 56 a1 7b 0c ; .d.1..1(..|.V.{.
	8f 99 4d bc c0 a2 38 b0 92 0f ed fc 77 fc f5 f8 ; ..M...8.....w...
	bb ff 38 8e f0 e2 a6 08 65 8a 3b 98 4b ee e1 ea ; ..8.....e.;.K...
	5a e8 9f 71 4d 41 10 ba f2 84 58 a8 5e 14 )	; Z..qMA....X.^.
dv.isc.org.		1D IN TYPE46	\# 94 (	; unknown RR type
	00 0f 05 03 00 01 51 80 4f 8b 89 c2 4f 3c 63 3e ; ......Q.O...O<c>
	38 64 02 64 76 03 69 73 63 03 6f 72 67 00 23 71 ; 8d.dv.isc.org.#q
	d1 ff e6 08 6d a6 6c 4e 94 92 c7 83 e5 21 23 f7 ; ....m.lN.....!#.
	37 58 51 b5 0f f6 a2 d6 68 6b 83 8e 73 fb 46 b0 ; 7XQ.....hk..s.F.
	e5 c3 93 7b 5f 4f 79 9f ee 14 9e 7f 4e 8a e2 65 ; ...{_Oy.....N..e
	55 e4 99 d8 14 64 43 4a b6 9e ac 90 1c ee )	; U....dCJ......
dv.isc.org.		1D IN TYPE46	\# 94 (	; unknown RR type
	00 2f 05 03 00 01 51 80 4f 96 dc 75 4f 47 bd 1c ; ./....Q.O..uOG..
	38 64 02 64 76 03 69 73 63 03 6f 72 67 00 7a b5 ; 8d.dv.isc.org.z.
	3b 7f 55 0d 46 ca 29 29 9d 3c 93 74 fd b5 96 35 ; ;.U.F.)).<.t...5
	76 d4 65 18 fe 8a c2 17 42 e2 0a ba 38 9f ea 96 ; v.e.....B...8...
	5f 84 cc f0 6e df a2 da 83 c9 40 13 da e6 8c 3a ; _...n.....@....:
	66 3c 7f 4e 92 6b d5 cc e0 5f 8a f5 49 be )	; f<.N.k..._..I.
dv.isc.org.		1D IN TYPE46	\# 158 (	; unknown RR type
	00 30 05 03 00 01 51 80 4f 8b 9e 5a 4f 3c 79 a8 ; .0....Q.O..ZO<y.
	28 30 02 64 76 03 69 73 63 03 6f 72 67 00 24 51 ; (0.dv.isc.org.$Q
	3c 2c 11 00 3f 77 aa ea 5f 94 f7 fc f6 9a 97 af ; <,..?w.._.......
	58 29 ef 76 3d a7 4b ab ea 90 f4 15 ac 22 7c 27 ; X).v=.K......"|'
	b2 cc e6 8b 1e 6b f9 b0 ba c8 7c 49 60 ed a8 4d ; .....k....|I`..M
	89 1d c6 c4 f0 e9 a5 16 5f 4e ad 59 17 5d cf ce ; ........_N.Y.]..
	79 a3 8a 81 8b 06 30 12 c4 27 8d 87 7a 0a 7f d5 ; y.....0..'..z...
	65 2e 1e 63 35 98 6c 38 dc 0a e0 75 40 1d 0b 75 ; e..c5.l8...u@..u
	51 b6 cb 6d a7 b8 08 6f 46 f7 2a bf c5 7b 3c 56 ; Q..m...oF.*..{<V
	5b 84 17 fd a4 43 22 dd b0 99 db c2 9f 33 )	; [....C"......3
dv.isc.org.		1D IN TYPE46	\# 94 (	; unknown RR type
	00 30 05 03 00 01 51 80 4f 8b 9e 5a 4f 3c 79 a8 ; .0....Q.O..ZO<y.
	38 64 02 64 76 03 69 73 63 03 6f 72 67 00 20 8e ; 8d.dv.isc.org. .
	e1 b2 e5 5c e9 ec b8 96 d8 06 ae c1 b6 91 19 6c ; ...\...........l
	6e f2 01 98 92 e5 4a af 9a f4 cf 5c 2d bc b9 5b ; n.....J....\-..[
	c0 19 7f f6 35 ee 16 fd 0b 52 ff ac d8 aa 96 6f ; ....5....R.....o
	4f 26 0d c4 6d eb c2 ee 4d 89 39 86 8b 1e )	; O&..m...M.9...

;; AUTHORITY SECTION:
dv.isc.org.		1D IN NS	bsdi1.dv.isc.org.
dv.isc.org.		1D IN NS	drugs.dv.isc.org.

;; ADDITIONAL SECTION:
bsdi1.dv.isc.org.	1D IN A		192.168.191.233
drugs.dv.isc.org.	1H IN A		192.168.191.240
drugs.dv.isc.org.	1H IN A		192.168.191.223
drugs.dv.isc.org.	1H IN AAAA	2001:470:1f00:820:ea06:88ff:fef3:4f9c
drugs.dv.isc.org.	1H IN AAAA	2001:470:1f00:820:6233:4bff:fe01:7585
; EDNS: version: 0, udp=4096, flags=0000

;; Total query time: 46 msec
;; FROM: bsdi.dv.isc.org to SERVER: 127.0.0.1
;; WHEN: Thu Mar  8 09:48:51 2012
;; MSG SIZE  sent: 39  rcvd: 883

bsdi:marka 09:48 {105} %

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Mar 2012 10:27:33 +1100

In message <[email-masked]>, Martin Rex writes
> But that is definitely not what the spec says.

Yet someone else that can't count beyond 1035.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Mar 2012 00:44:09 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Andrews
> Sent: Wednesday, March 07, 2012 3:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: provisioning software, was DNS RRTYPEs, the difficulty with
> 

Weren't you the one that said "Actually it is STD 13.  Get over it." earlier in this thread?

I looked at least at the titles of all the documents that update 1035, and none of them appear to be related to the above.  So where should we be looking?

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Mar 2012 13:10:24 +1100

In message <[email-masked]
> Weren't you the one that said "Actually it is STD 13.  Get over it." earlier 

Randy claimed that presentation formats were not standardised.  They
are.  Randy and others claimed that the presentation formats were
owned by BIND and they are not.

I never claimed that STD 13 was the be all and end all w.r.t. DNS.

STD 13 didn't follow the normal process required to make a STD.
There are lots of corrections to STD 13 in the RFC series.

> I looked at least at the titles of all the documents that update 1035, and no
> ne of them appear to be related to the above.  So where should we be looking?
> 
> -MSK

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Mar 2012 04:19:53 +0100 (MET)

> STD 13 didn't follow the normal process required to make a STD.

That does not matter here.  By assigning the "full standard" document
maturity label to rfc1034/rfc1035 

> There are lots of corrections to STD 13 in the RFC series.

That is a misunderstanding of the standards process.  The only corrections
to rfc1034/rfc1035 that exist are those that have been filed as errata
and confirmed (accessible with the Errata URL here):
    http://tools.ietf.org/html/rfc1034
    http://tools.ietf.org/html/rfc1035

But even the posted erratas are "soft" and not visible here:

    http://tools.ietf.org/html/std13

The only document that could be reasonably expected to be "considered"
be a new implementation is rfc2181 (plus maybe rfc4343), although
you have to keep in mind that neither of this is mentioned by STD13.

Btw. the updates metadata on rfc1035 looks like a big mess to me.
Expecting *anyone* to read all of the documents and merge them
in their heads while implementing is completely unrealistic.

The normal implementation approach is to use the base specification
plus a "clarifications" document if one exists, implement the mandatory
parts of that, and ship the result as a first step.  As a second step,
depending on requirements and funding/resouces, selected optional features
from the base spec and from other optional protocol extensions may get added.

> 
> > I looked at least at the titles of all the documents that update 1035,
> > and none of them appear to be related to the above.  So where should
> > we be looking?

To answer the question "does my client have to expect and cope gracefully
with an RCODE 4 response", only 1034/1035 and the filed erratas are relevant.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Mar 2012 14:02:15 +0000

Murray S. Kucherawy <[email-masked]> wrote:

> and none of them appear to be related to the above.  So where should we
> be looking?

The only thing I have found that implies NOTIMP doesn't apply to queries
for unknown RR types is in RFC 4074, "Common Misbehavior Against DNS
Queries for IPv6 Addresses":

4.3.  Return Other Erroneous Codes

   Other authoritative servers return a response with erroneous response
   codes other than RCODE 3 ("Name Error").  One such RCODE is 4 ("Not
   Implemented"), indicating that the servers do not support the
   requested type of query.

But I guess that NOTIMP *would* be an appropriate response if the request
is for an unknown QTYPE between 128 and 255.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Mainly northeasterly 4 or 5, occasionally 6 in southeast Fitzroy.
Moderate, becoming rough or very rough except in southeast Trafalgar. Fair.
Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Mar 2012 14:06:16 +0000

> in their heads while implementing is completely unrealistic.

http://blog.nominet.org.uk/tech/2010/05/24/436/ - DNS RFC dependency graphs

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey, Fair Isle: West or southwest 6 to gale 8, occasionally
severe gale 9. High or very high. Rain or squally showers. Moderate or good,
occasionally poor.

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Mar 2012 19:45:16 +0100 (MET)

> Queries for IPv6 Addresses":

Thanks for mentioning rfc 4074.  The stuff in that document matches
the thoroughly broken behaviour of the IPv6 DNS resolver client of
Windows 2003 that I had encountered just recently.

IMO, rfc4074 exhibits a significant amount of cluelessness about DNS,
the "Full Standard" document maturity level, and the realities of
backwards compatibilities for an incredibly huge installed base.

The answer to the question "what can I infer from a failed AAAA lookup"
must be deduced from STD 13 **ALONE**, and it amounts to "very close to
nothing at all".

Now this puts the slow adoption of IPv6 into perspective if it takes
the IPv6 crowds >10 years to figure that one out, 

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Mar 2012 20:57:13 +0100 (MET)

> must be deduced from STD 13 **ALONE**, and it amounts to "very close to

In case this isn't clear:  this applies to DNS responses with one of
the failure RCODEs (1,2,3,4,5) defined in rfc1035 _unless_ the response
is accompanied by some protocol extension that can be used to **reliably**
distinguish 1034/1035 DNS responders from those conforming to a later,
optional DNS protocol extension.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 10:21:46 +1100

In message <[email-masked]>, Martin Rex writes
> backwards compatibilities for an incredibly huge installed base.

So not answering a query because the type is 28 matches RFC 1034
behaviour?  DNS is a query/response protocol.

So returning NXDOMAIN because the query type is 28 when you have
type 1 in the database matches RFC 1034 behaviour?

Returning A record content in software written *after* type code
28 was defined matched RFC 103[45] behaviour?  The same servers
shove A rdata into TXT rdata.  Everything is a A record.

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2012 00:59:51 +0100 (MET)

> shove A rdata into TXT rdata.  Everything is a A record.

We started this with the NOTIMP, which is certainly a permissible
response for an AAAA query per rfc1035.

What I briefly saw the win2003 DNS client doing in a wireshark trace
(which I forgot to save before I had to reboot after windows disabled
all networking) was visualized as a mixture of "no name" and "server fail"
for 23 consecutive AAAA lookups until ~18 seconds later the first A lookup
was finally sent.
I assume the two locally configured DNS Server were caching(-only) servers,
not authoritative ones (at least our current DNS Zones do not contain
NS records for any of the two).

Besides what you can deduce from the spec itself, you will also have
to take into account how that incredibly huge installed base was
created.  A number of software vendors perform only black-box testing
and limited interop testing, so it will not be unusual that your
AAAA queries may be the first queries of that kind that a DNS responder
might be seeing. 

So if the behaviour (how to exactly respond to queries for unknown
QTYPEs) is neither explicitly specified, nor likely have been part of
the usual/common interop tests performed by the vendor,
what you're left with might be "ureflected&untested guessing"
on part of the implementors to fill those gaps.

Bottom line, the receiver must be VERY conservative with assumptions
about what exactly can be infered from error responses for situations
that are fairly vague in the spec and potentially untested in the
installed base.  That is called "robustness principle".

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2012 02:07:38 +0100 (MET)

> on part of the implementors to fill those gaps.

What you typically have is a certain amount of code processing a query,
and some 3-4 conditions under which this code fails, and where the
implementor will have to decide which RCODE to return.  The choices
available in rfc1035 are:

                0               No error condition

The choice between RCODEs 1, 2 and 4 for failed AAAA queries
might be fairly random, the description for 3 is slightly confusing
in whether a DNS server might use this RCODE "creatively" by
returning it without AA.

For an implementor that is being told "do not use use RCODE 4 for
unknown QTYPES", not sending any response at all to an unsupported
AAAA query seems like a reasonable choice.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2012 02:08:29 +0100 (MET)

Sorry,

s/some 3-4 conditions/some 3-4 dozen conditions/

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 12:15:33 +1100

In message <[email-masked]>, Martin Rex writes
> AAAA queries may be the first queries of that kind that a DNS responder

The incredibly huge base that returned NOERROR to type 28 queries
when AAAA was defined.  Almost all of the offending boxes were
designed after AAAA was defined.

Lots of them get responses to RFC 1035 types wrong.  If you don't
implement the type then you can't load the zone if it contains the
type, partial zone loads are not permitted as per RFC 1035.  If you
have loaded the zone then the type doesn't exist, so it doesn't
matter that you don't implement it, you therefore can't match the
type as per RFC 1034 so the answer is NOERROR or NXDOMAIN depending
apon whether the name exists in the zone or not.

> installed base.  That is called "robustness principle".

Which is why there are lots of SERVFAILs as you can't infer anything
from NOTIMP.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 13:03:55 +1100

In message <[email-masked]>, Martin Rex writes
> AAAA query seems like a reasonable choice.

They are much more likely to have been told "you should be sending
NOERROR or NXDOMAIN not NOTIMP" rather than just "you should not
be sending NOTIMP".

There are nameservers that don't respond to EDNS queries for type
A, class IN.  FORMERR, NOTIMP, REFUSED all trigger a retry with
plain DNS.  Silence is much harder to work out what to do with and
it takes muuuuuuuuuch loooooooooooonger.  As silence can be caused
by lots of things not just EDNS so you can't infer anything if you
succeed with plain DNS.  Success after FORMERR, NOTIMP or REFUSED,
for an otherwise identical query, is a reasonable indication that
EDNS is not supported.

Mark

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2012 03:23:10 +0100 (MET)

> designed after AAAA was defined.

When AAAA was defined is marginally relevant.  Since IPv6 was designed
as a completely seperate universe, it was flying below the radar
for most software apps developers for >10 years.  I was first bothered
about IPv6 in 2004.

Had there been versions of BIND exhibiting such behaviour?

I know that during its development, BIND sometimes adopted annoying
unnecessary backwards-incompatible changes that caused folks to
not upgrade.  IIRC, suddenly refusing to load zone with hostnames
containing underscores was one BIND change I remember from my early
days as DNS admin, that caused me to ignore BIND software updates
for several years (waiting for the "offending" hosts to die of age).

> type, partial zone loads are not permitted as per RFC 1035.

"not permitted" would require a "must not", but
I only see a "should not" here:
http://tools.ietf.org/html/rfc1035#section-5.2

>
> If you have loaded the zone then the type doesn't exist, so it doesn't

>From these discussions, your explanations and my latest reading of
1034/1035 I believe I have a hunch what might have happened (to our
internal DNS) when my w2k3 IPv6 stack freaked out...

It might be related to the particular fashion in which I originally
set up the private DNS universe as an intern in 1993.  And while I
joined development in 1995 and the tools I had written to to generate
the DNS zone files got replaced ~1999 with a commercial solution,
the structure of the private DNS universe seems to be still the
way I originally set it up.

Thank you for your patience and elaborate responses.

> Which is why there are lots of SERVFAILs as you can't infer anything

Servfail is supposed to be a transient error.

What should a _new_ recursive non-authoritative server send as response
back to the stub resolver when it encounters a NOTIMP response from the
authoritative server for an AAAA query?

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 13:56:23 +1100

In message <[email-masked]>, Martin Rex writes
> Had there been versions of BIND exhibiting such behaviour?

No.  Unknown types were always NOERROR/NXDOMAIN.
 
> for several years (waiting for the "offending" hosts to die of age).

Which was controllable behaviour.
 
> http://tools.ietf.org/html/rfc1035#section-5.2

RFC 1035 pre-dates the formalisation of MUST NOT/SHOULD NOT etc.

5.2. Use of master files to define zones

When a master file is used to load a zone, the operation should be
suppressed if any errors are encountered in the master file.  The
rationale for this is that a single error can have widespread
consequences.  For example, suppose that the RRs defining a delegation
have syntax errors; then the server will return authoritative name
errors for all names in the subzone (except in the case where the
subzone is also present on the server).

How anyone could rationalize serving a zone with missing data after
reading that I don't know.  I do know that doing so does cause
operational problems and fixing named to stop serving the zone on
load errors was was one of the ealier things I did.

> authoritative server for an AAAA query?

Well the server should try the next server for the zone.  If all of them
return NOTIMP, SERVFAIL/NOTIMP.

---

From: Hector <[email-masked]>
Date: Thu, 08 Mar 2012 22:40:36 -0500

> return NOTIMP, SERVFAIL/NOTIMP.

+1, this seems logical.

What is perhaps ultimately important to a developer is its application 
translation of DNS query results, including the application tracking 
for the redundancy of failures.  *Rhetorically,* does a NOIMP enable 
an automated trigger to disable a specific DOMAIN query?  Should a 
protocol translate SERVFAIL as an application temporary or permanent 
failure?  Can a temp status change to permanent due to redundancy?, etc.

--
HLS

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2012 05:22:27 +0100 (MET)

> load errors was was one of the ealier things I did.

A zone file loaded by a DNS server is not necessarily an authoritative
zone file! And for a non-authoritative zone, a partial zone might
be considerably better than no data at all.

In 1993 we had a worldwide private network with modate-size links
to remote locations and the links would occasionally fail for a
few hours.  So I setup *all* DNS servers (primary&secondaries,
delegated primaries&secondaries and caching-only) to obtain all
zones via XFER in a tree structure.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 17:04:03 +1100

In message <[email-masked]>, Martin Rex writes
> be considerably better than no data at all.

You were still authoritative for it, just not a official server.
The act of loading from a zone file makes you authoritative.  Your
content may have been slightly older if it had been updated on the
master but it was still complete for the version of the zone you
had.  You were also within the expected tolerences for changes to
be made visible to everyone.  Those are specified in the SOA record.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Mar 2012 10:57:37 +0100

On Wed, Mar 07, 2012 at 05:21:40PM -0500,
 John R. Levine <[email-masked]> wrote 
 a message of 22 lines which said:

> Could you give some concrete examples of DNS provisioning systems
> that let you enter arbitrary RRs?  I've never seen one in the wild,
> other than the one I wrote for myself.

My registrar and DNS hoster, Gandi <http://www.gandi.net/> allows it,
in a mode called "Expert mode". As its name suggest, it is not easy to
use (you have to translate the record in RFC1035-section5 format
yourself).

There is of course a "User mode" with the usual closed list of known
types, and easy entry of values.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Mar 2012 11:01:52 +0100

On Thu, Mar 08, 2012 at 01:10:24PM +1100,
 Mark Andrews <[email-masked]> wrote 

> owned by BIND and they are not.

A better description of the situation would be "there is a standard
format, standardized in section 5 of RFC 1035 and in many other RFC
for new RR types" and "its standard description is quite poor, with
many unspecified things, so, in practice, a zone file accepted by a
compliant implementation may not always work with another". Today, the
IESG would never accept the sloppy language of RFC 1035.

Also, some programs added non-standard extensions to this format (such
as BIND's $TTL).

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 22:57:36 +1100

> Also, some programs added non-standard extensions to this format (such

$TTL is defined in RFC 2181.

$GENERATE is a BIND extension and is documented as such.

Mark