Am 15.09.2017 um 09:37 schrieb Harshith Mulky: > Hello Experts, > > I had a query on advertising the payload size on client in DNS Responses > over UDP/TCP > > > This is as much I have understood from RFC 6891, that a > requester(client) can address his capabilities to restrict the UDP > Payload size to a limit between 512 to 4096 bytes based on his > limitation when supporting EDNS Procedures. > > Is it the same case with TCP? > > Can we(client) advertize our capabilities over TCP to limit the payload > size in Responses?
why would you want do do that? TCP don't suffer from the problem of a faked sourcip and the repsonse going back to the attacke victim! what do you imagine to happen when your response data is larger? in case of UDP the fallback is simply TCP and then you want to cripple that fallback? [Harshith] But I do not understand why would OPT section required in a TCP Query. As i see from my Traces, Even TCP Queries carry a OPT section with the advertized sizes the client supports! Why would this be necessary? I do not want to cripple the fallback, but if a query is intending to do so from a resolver, how Do we stop that? Thanks ________________________________ From: bind-users <[email protected]> on behalf of [email protected] <[email protected]> Sent: Friday, September 15, 2017 5:30 PM To: [email protected] Subject: bind-users Digest, Vol 2734, Issue 2 Send bind-users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: What is wrong with my second $ORIGIN (Harshith Mulky) 2. Re: Is there a need for clients to advertize the capabilities for DNS Responses over TCP (Reindl Harald) ---------------------------------------------------------------------- Message: 1 Date: Fri, 15 Sep 2017 01:16:08 -0700 (MST) From: Harshith Mulky <[email protected]> To: [email protected] Subject: Re: What is wrong with my second $ORIGIN Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii Than you All. Did not notice I had missed a trailing '.' Will make sure I do not miss these things the next time I test -- Sent from: http://bind-users-forum.2342410.n4.nabble.com/ ------------------------------ Message: 2 Date: Fri, 15 Sep 2017 12:30:23 +0200 From: Reindl Harald <[email protected]> To: [email protected] Subject: Re: Is there a need for clients to advertize the capabilities for DNS Responses over TCP Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252; format=flowed Am 15.09.2017 um 09:37 schrieb Harshith Mulky: > Hello Experts, > > I had a query on advertising the payload size on client in DNS Responses > over UDP/TCP > > > This is as much I have understood from RFC 6891, that a > requester(client) can address his capabilities to restrict the UDP > Payload size to a limit between 512 to 4096 bytes based on his > limitation when supporting EDNS Procedures. > > Is it the same case with TCP? > > Can we(client) advertize our capabilities over TCP to limit the payload > size in Responses? why would you want do do that? TCP don't suffer from the problem of a faked sourcip and the repsonse going back to the attacke victim! what do you imagine to happen when your response data is larger? in case of UDP the fallback is simply TCP and then you want to cripple that fallback? ------------------------------ Subject: Digest Footer _______________________________________________ bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users ------------------------------ End of bind-users Digest, Vol 2734, Issue 2 *******************************************
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
