Re: provisioning software, was DNS RRTYPEs, the difficulty with

In message <77075C8C-04ED-48A2-B501-B2296BCFC8C6(_at_)frobbit(_dot_)se>, 
=?iso-8859-1?Q?Pa
trik_F=E4ltstr=F6m?= writes:
> I think we should look a bit on the flow of data. If I simplify we have a flo
> w 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 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.
>
> 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 provis
> ioning and DNS packet format is.
>
> Are we aligned so far?
>
>    Patrik
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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf