Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix interpretation of TTL as UINT32 with most significant bit unset #116

Merged
merged 1 commit into from Nov 5, 2018

Conversation

clue
Copy link
Member

@clue clue commented Nov 4, 2018

TTL is actually a UINT32 with most significant bit unset for BC reasons as per https://tools.ietf.org/html/rfc2181#section-8. This will not affect "normal" operation as the most significant bit should not be set by compliant implementations and we will now interpret this accordingly.

Refs #81
Refs #114

@clue clue added the bug label Nov 4, 2018
@clue clue added this to the v0.4.16 milestone Nov 4, 2018
@clue clue requested review from jsor and WyriHaximus November 4, 2018 12:58
@kelunik
Copy link

kelunik commented Nov 4, 2018

It's probably best to limit the TTL to a much lower value, such as one day, to mitigate the effect of a successful cache poisoning attack.

@clue
Copy link
Member Author

clue commented Nov 4, 2018

@kelunik I think you're raising a valid point when it comes to the caching layer (see #81). However, this PR is concerned with the networking layer. It's my understanding that this layer should therefor implement the DNS protocol specs as suggested in this PR.

@kelunik
Copy link

kelunik commented Nov 4, 2018

@kelunik Indeed, the policy for that shouldn't live in the parser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants