On 9 Dec 2015, at 21:25, Hosnieh Rafiee wrote: > I would like to suggest the following format (this is the rough version and > it is not exact but only giving you an idea that what is the purpose) for a > new resource record to store the reference information of bounding of > authentication and authorization where authentication can be based on public > keys or certificates. > This means each reference no represents an actual policy template in other > security system or other services. This means if a certificates bound to more > than one references, then more than one of this section is added to RDATA > section of the DNS query. This also should be updatable by the DDNS protocol. > BTW, I skipped the header and other parts of RR and this part is only the > RDATA section. > > ----------------------- > |flag| reference no | > ----------------------- > | some human readable | > | text | > ----------------------- > > The processes are also simple, when a node query the certificates, DNS server > also includes this RR if it exists on the DNS server so that when the querier > retrieves this information, it can query other services for the given value > to authorize the other host on the network.
A few things: 1. Do not use TXT RR. We have already too much use of TXT, and you should define a new RRType 2. There are multiple reasons why you should not use TXT record or even the structure of the TXT RR, most notably the length of the "some human readable text" portion. I suggest you have, just like in the URI RRType, the length of the "some human readable text" be set by the length of the RR as a whole minus the flag, reference no, header etc. That way the length can be longer than what you otherwise can (in a TXT for example). You also do not end up having trouble defining how to handle multiple strings in the RR, like you have if you try to stuff things into a TXT. 3. Think about (as you did in a later message) the owner as well as the RData. The right prefix might be key to the usage pattern. Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
