Support the OPT pseudo-record

[exarkun]

RFC 2671 defines a new record type, OPT (value 41). This record doesn't carry information about a domain name. Instead, it carries extended information about the format of the request or response message.

We should be able to decode these into a structured object and serialize them back into a message.

See EDNS0 for some notes on the big picture.

[exarkun]

(In [34367]) Branching to 'opt-record-5668'

[exarkun]

(In [34368]) Apply just the parts of the #5454 patch which add the OPT record type

refs #5668

[exarkun]

Next thing to do, I think, is figure out why OPTHeader exists, and why RRHeader is changed to subclass it.

[BobNovas]

Jean-Paul - In the 5454 patch, OPTHeader exists because Record_OPT uses or overloads some of the fields of what would be RRHeader. So OPTHeader is just the header fields of a Record_OPT and so OPTHeader is a subset of RRHeader in terms of fields (and OPTHeader is also a subclass of RRHeader).

OPTHeader._headerFactory decodes just enough of a stream to decide if it should create an OPTHeader or an RRHeader and then either creates an OPTHeader or rewinds the stream and creates an RRHeader and returns one or the other. So, Message.parseRecords calls OPTHeader._headerFactory and gets the right Header (OPTHeader or RRHeader, which is a subclass of OPT), and then decodes the rest of the record from the type of the record, which is in OPTHeader, hence also in RRHeader.

Bad idea? Sorry.

[exarkun]

Thanks for the explanation, it helps a lot. On a closer reading of the EDNS RFC, now I wonder if it wouldn't be better to just have OPTHeader and forget about Record_OPT. Not sure yet, just the direction my thoughts are going right now.

[rwall]

(In [38420]) Branching to 'opt-record-5668-2'

[rwall]

Ready for review in log:branches/opt-record-5668-2

• This isn't finished but I'd like some feedback on what I've done and how much further to go in this ticket.
• I've been concentrating on OPTHeader
• So far I've implemented all the fixed fields of the OPT RR described here:  http://tools.ietf.org/html/rfc6891#section-6.1.2
• I need to decide whether to bother supporting the EDNS options tuples
• There don't seem to be (m)any real world uses for it yet - only proposals ( http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-11)
• I've left BobNovas original Record_OPT class in place for now, but it could become the container and parser for the Option tuples if we choose to support them.
• I've made some initial modifications to dns.Message to allow decoding OPT RRs but this part could be moved to a separate ticket where we introduce a client API for issuing EDNS queries.

Build Results:

•  http://buildbot.twistedmatrix.com/boxes-supported?branch=/branches/opt-record-5668-2

-RichardW.