> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
