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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf