On 2012-10-01 4:00 PM, John Kristoff wrote: >> ... >> >> We could encode the encrypt the correct destination in the CNAME, for >> A and AAAA this is trivial. If you come back to resolve >> encoded-12.32.43.43.attackeddomain.com, you get 12.32.43.43 etc. For >> extra resilience encrypt it. >> >> I did not think this through too deeply, but what do people think?
as before, i think this could be done for a recursive talking to a stub, but that an authority server should only speak zone truth. since the stub/recursive relationship can be kept spoof-free using ACL's and network perimeters, what we primarily need is solutions in the recursive/authority relationship. and i would not be comfortable seeing synthetic CNAME's added to those transactions. moreover: > Why would this, or other similar proposals, be more preferable than > just sending back truncated packets to signal for TCP? > > This latter approach has been widely used in network gear over the > years with a fair amount of success, and now thanks to Paul and Vern's > work, seems to be a promising feature in the application itself. noting that other network equipment has been doing this, i want to make sure everyone knows the distinction of DNS RRL's approach: packet attenuation. we only insert TC=1 "slip frames" periodically, not on a 1:1 basis with potentially fake queries. slip frames are the same size as queries, so there is no bit-level amplification. and the packet level replication is attenuated. this makes a DNS RRL server "less attractive" than a directed attack, which is literally the best we can hope to accomplish here -- the attacks will go on but our authority servers don't have to be involved. paul _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
