[sunset4] New draft: draft-hazeyama-sunset4-dns-a-filter-00

[Hiroaki Hazeyama]

Hi all,

we posted a new draft

http://tools.ietf.org/html/draft-hazeyama-sunset4-dns-a-filter-00

according to the comments on ietf 86 orland,
this memo describes only the technical proposal part of DNS A record
filtering on draft-hiromi-sunset4-termination-ipv4-00.

would be interesting to hear your feedback.

----
Hiroaki Hazeyama

[Ted Lemon]

Post by Hiroaki Hazeyama
according to the comments on ietf 86 orland,
this memo describes only the technical proposal part of DNS A record
filtering on draft-hiromi-sunset4-termination-ipv4-00.

An IPv6-only node by definition doesn't have IPv4, so an A record would go unused, and therefore causes no harm. A dual-stack node with broken IPv4 would fail, so an A record would cause harm in this case. However, the way you've chosen to mitigate the harm looks like it would break DNSSEC validation; I see no mention of this in the document. I think a solution to a broken network that breaks DNSSEC validation is the wrong way to go.

Is it possible to implement this in a way that doesn't break DNSSEC validation?

[Hiroaki Hazeyama]

Thank you ted for your comment.

I will add the consideration about the DNSSEC in the next version.

Our current solution will break the DNSSEC validation because the
current DNS64/NAT64 does not have the affinity with DNSSEC validation.


Unfortunatelly, I have no idea how to keep the DNSSEC validation
on the DNS64/NAT64 environment at the moment. Also, I'd like to know the
possible way or implementation to keep DNSSEC validation in DNS64/NAT64
environment. If you know some ideas or ways, please let me know.

Regards,

----
hazeyama

Post by Ted Lemon

Post by Hiroaki Hazeyama
according to the comments on ietf 86 orland,
this memo describes only the technical proposal part of DNS A record
filtering on draft-hiromi-sunset4-termination-ipv4-00.

An IPv6-only node by definition doesn't have IPv4, so an A record would go unused, and therefore causes no harm. A dual-stack node with broken IPv4 would fail, so an A record would cause harm in this case. However, the way you've chosen to mitigate the harm looks like it would break DNSSEC validation; I see no mention of this in the document. I think a solution to a broken network that breaks DNSSEC validation is the wrong way to go.
Is it possible to implement this in a way that doesn't break DNSSEC validation?
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

[Ted Lemon]

Post by Hiroaki Hazeyama
Unfortunatelly, I have no idea how to keep the DNSSEC validation
on the DNS64/NAT64 environment at the moment. Also, I'd like to know the possible way or implementation to keep DNSSEC validation in DNS64/NAT64 environment. If you know some ideas or ways, please let me know.

The way you do DNSSEC validation with DNS64 is to have a trusted path between the stub resolver and the DNS64 resolver. The DNS64 resolver does the validation on the original answer, and then returns a synthesized answer (if needed) with the AD bit set to indicate that the data has been authenticated. If you want to do validation locally, you have to do the DNS64 synthesis locally as well. This is described in section 6.2 of RFC 6147.

Have you considered the implications of section 6.1 of RFC6147 on your proposal? I think it's a problem.

[Hiroaki Hazeyama]

Ted,

Post by Ted Lemon

Post by Hiroaki Hazeyama
Unfortunatelly, I have no idea how to keep the DNSSEC validation
on the DNS64/NAT64 environment at the moment. Also, I'd like to know the possible way or implementation to keep DNSSEC validation in DNS64/NAT64 environment. If you know some ideas or ways, please let me know.

The way you do DNSSEC validation with DNS64 is to have a trusted path between the stub resolver and the DNS64 resolver. The DNS64 resolver does the validation on the original answer, and then returns a synthesized answer (if needed) with the AD bit set to indicate that the data has been authenticated. If you want to do validation locally, you have to do the DNS64 synthesis locally as well. This is described in section 6.2 of RFC 6147.

I'm not a specialist of DNSSEC, and I had a bit wrong information about
DNSSEC.
Anyway, thank you to inform the proper information.

Post by Ted Lemon
Have you considered the implications of section 6.1 of RFC6147 on your proposal? I think it's a problem.

I think we met such problem in section 6.1 of RFC6147 in a past wide camp.

Some DNS returned A record response to the AAAA record query from our
DNS64, then the DNS64 cannot fallback to perform the sythesis.

Is this the same problem that you worry about ?

----
hazeyama

[Ted Lemon]

Some DNS returned A record response to the AAAA record query from our DNS64, then the DNS64 cannot fallback to perform the sythesis.

No, this is somewhat expected behavior in certain implementations. DNS64 should be filtering out the AAAA records, but unfortunately RFC 6147 didn't anticipate this problem.

Is this the same problem that you worry about ?

The problem I was referring to is the problem where your DNS resolver downstream of the DNS64 resolver gets A records as glue, and then returns them as answers to queries from stub resolvers.

On the whole, I would really like to encourage you to re-think this architecture as a simple update to RFC 6147 to address the rogue A record problem there, instead of the rather complicated architecture that you've described. It may be that I don't understand the motivation for the more complicated problem, but to me it looks like the DNS A record filter proxy is unnecessary—you just need to specify that the DNS64 resolver does A record filtering.