bind-users Digest, Vol 2734, Issue 2

[Harshith Mulky]

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 <bind-users-bounces at lists.isc.org> on behalf of bind-users-request at lists.isc.org <bind-users-request at lists.isc.org>
Sent: Friday, September 15, 2017 5:30 PM
To: bind-users at lists.isc.org
Subject: bind-users Digest, Vol 2734, Issue 2

Send bind-users mailing list submissions to
        bind-users at lists.isc.org

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
        bind-users-request at lists.isc.org

You can reach the person managing the list at
        bind-users-owner at lists.isc.org

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 <harshith.mulky at outlook.com>
To: bind-users at lists.isc.org
Subject: Re: What is wrong with my second $ORIGIN
Message-ID: <1505463368415-0.post at n4.nabble.com>
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 <h.reindl at thelounge.net>
To: bind-users at lists.isc.org
Subject: Re: Is there a need for clients to advertize the capabilities
        for DNS Responses over TCP
Message-ID: <ac3458f0-305d-fc4f-868b-bd5ffed1f41b at thelounge.net>
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
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

------------------------------

End of bind-users Digest, Vol 2734, Issue 2
*******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170917/cb1c020f/attachment-0001.html>