wkumari / draft-vandergaast-edns-client-subnet Goto Github PK

Currently the document says:
"In the cache, any resource record in the answer section will be tied to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX-LENGTH fields, as detailed below. Note that the additional and authority sections from a DNS response message are specifically excluded here. Any information cached from these sections MUST NOT be tied to a network. This means that edns-client-subnet option cannot be used to tell some clients that a name exists and others that the name does not exist (NXDOMAIN)."

Is this "right"? If I tell a client at 192.0.2.0 that the A for example.com is 10.10.10.10, can I then (legitimately!) tell another client that example.com doesn't exist? What if there is SERVFAIL; should that invalidate all of the cached entries?

If a Forwarder handles a query where its client requested a specific SOURCE PREFIX-LENGTH, but policy determines that the Recursive Resolver it contacts will not be able to use the ADDRESS provided to it in an ECS option, the Forwarder must send an option with a zero FAMILY and no ADDRESS, and only SOURCE PREFIX-LENGTH set (and SCOPE PREFIX-LENGTH can essentially be any thing, since the Recursive Resolver will use its own value).

The problem arises in that the Recursive Resolver can't send FAMILY and ADDRESS information back down to its client without running afoul of the current Security section that demands the FAMILY and initial SOURCE PREFIX-LENGTH bit of ADDRESS in the response must match those provided in the query.

"Caching the Response" says, "Note that the additional and authority sections from a DNS response message are specifically excluded here. Any records from these sections MUST NOT be tied to a network." This conflicts a bit with draft-kumari-dnsop-multiple-responses, which wants to put data in the additional section that an authoritative nameserver that does ECS would probably want to tailor.

Since how a resolver will handle this is an important consideration for the auth server, there should be a way to communicate this from the resolver, but its hard to see how that can be done with the structure of the option as it stands. At the moment it pretty much doesn't affect Akamai's implementation, at least, because when we provided addresses in Additional they are for the NSs in Auth and we resolver-map them anyway.

Anyway, one possible way to handle this protocol conflict would be to to break the FAMILY field down. Since FAMILY is expressly limited to IPv4 and IPv6, and we'd have to take protocol action anyway to define things for another FAMILY, it technically needs only two bits. However, to give it some measure of flexible future-proofing it could be kept as long as even 12 or 13 bits will still allowing 3-4 bits (values 0-7 or 0-15) for versioning. Even 7 is probably way more versions than would ever realistically happen.

Even if the multiple-responses draft never advances, maybe versioning ECS would be a good idea to have ready anyway. And it could help with the whole problem of servers that just echo back EDNS0 options that they don't understand, too, because a bit could be stolen that has to be toggled.

But maybe breaking the FAMILY field down is just as much a problem as keeping FAMILY 16 bits and adding a new field to deal with versioning. I haven't thought it through enough as for how roll-out would go.

1. Several more examples would be useful as well. (I did send one to the
   authors off list.)

[ Will incorporate later ]

Using REFUSED to signal lack of support for forwarding an address specified in an incoming ECS option is problematic for a couple of reasons. It is ambiguous as to what aspect of the request was refused; since REFUSED is now commonly used to indicate a lame delegation, it adds another RTT now to distinguish a retryable-REFUSED from an end-of-the-line-REFUSED.

Also, one resolver vendor is opposed to the REFUSED in that it adds an RTT for something that it can just be getting an answer for. That is, if a client sending the option gets REFUSED, they should be retrying without the address information so that server will use their socket address. But the server could just go ahead and use that socket address when handling the original query. (Except, of course, for the problem I raised in Issue #4, about being able to reply with the address that was used.)

The first issue about indicating why it was refused could possibly be addressed by using an EDNS0 extended rcode, but I don't know how dnsop will feel about using an rcode for an option-specific message. This could also be addressed through versioning with the first octet of the option data (that is, what is currently the first octet of FAMILY). With versioning we could even address the issue of being able to service the query instead of refusing it.

" The specific logic that an Authoritative Nameserver uses to choose a
tailored response is not in the scope of this document. Implementers
are encouraged, however, to consider carefully their selection of
SCOPE PREFIX-LENGTH for the response in the event that the best
tailored response cannot be determined. "

It'd probably be good to give some examples for "consider carefully".