I think we should look a bit on the flow of data. If I simplify we have a
flow like this:
Looking at data flows is usually a good idea.
Input -P-> DNS server -D-> DNS stub -Q-> Output
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.)
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.
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"
RRTypes is not an issue.
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.
And when we talk about parsing, we talk about what the mapping between
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf